java 6 Mustang wird heute released :) @ tutorials.de: Tutorials, Forum & Hilfe

**Thomas Darimont** · 11.12.06 12:51

Hallo!

Im laufe des Tages wird sun die neueste Java Version 6 mit dem Codenamen Mustang endgültig freigeben

http://java.sun.com/javase/6/

http://entwickler.com/itr/news/pseco...nodeid,82.html

Gruß Tom

Anime-Otaku · 20.12.06 12:42

Da wollen wir doch gleich, um die Änderungen/Neuerungen reden:
Auszug aus openbook "java ist auch eine Insel 6":
"Es gibt Symbole in der Tray, Splash-Screens, eine standardisierte Web-Service-API – inklusive kleiner HTTP-Server –, ein JavaScript Interpreter erlaubt das Starten von JavaScript-Programmen, die Console ermöglicht mit Passwort-eingabe, und weiteres. Zudem ist in das JDK 6 ist eine komplette Datenbank, JavaDB (basierend auf Apache Derby), integriert."

Was ist von dem einzelnen zu halten?
Wie voll/groß soll es noch werden? Klar ist es schön alles aus einem Paket zu bekommen, die Frage ist, ist es nicht irgendwann zu viel/unübersichtlich? Oder sollte man nicht ein paar Sachen aufspalten?

Das sind so meine Überlegungen zu dem Thema.

matdacat · 20.12.06 14:20

Hier mal meine Meinung zu den genannten Erneuerungen:

Tray: Naja, nicht mehr als eye candy. Hübsch.
Splash-Screens: Wer in der Lage ist, ein Programm zu schreiben, das auch wirklich einen Splash-Screen verdient, konnte auch ohne diese Erneuerung einen solchen basteln.
WS-API: Eine Vereinheitlichung ist eine gute Idee.
Scripting: Ganz ist mir der Sinn von eingebundenen Scriptsprachen noch nicht klar.
Console mit Passworteingabe: Nicht wirklich erwähnenswert.
JavaDB: Find ich sehr gut! Muss ja nicht immer eine vollständige Client-Server-DB sein.

Eure Kommentare?

Anime-Otaku · 20.12.06 14:47

1. teilweise nicht nutzbar unter Linux
2. gut für Firmenentwicklung die eben ein Splash Screen wollen
3. Vereinheitlichung schön und gut, aber wie passt das zu den verschiedenen WSs?
4. finde ich unnötig, wir sind ja keine Skriptsprache und stiftet nur Verwirrung (auch hier im Forum...zu Javascript oder zu Java?)
5. schliese ich mich an
6. finde ich nicht gut, schließlich gäbe es auch HSQL (oder SQLite), welches auch ähnlich ist. Da sollte die Entscheidung eher offen gelassen werden.

BabyMitSchnully · 20.12.06 15:36

Genau so sehe ich das auch. Irgendwie geht doch der ganze Grundgedanke der Platformunabhängigkeit flöten oder nicht?!

**Thomas Darimont** · 20.12.06 23:33

Hallo

Mit Java 6 gibts natürlich viel mehr als die 6 Punkte die hier aufgelistet sind (meine (random) Favs:
- Einfaches Attachen von JMX basierten Management Tools (JConsole, MC4J, etc.) zur Laufzeit ohne
vorher -Dcom.sun.management.jmxremote übergeben zu müssen)
- MXBeans
- Instrumentation -> (Erneute) Manipulation von geladenen Klassen zur Laufzeit

- neues JDBC API
- Eingebauter HttpServer:

Code java:

/**
 * 
 */
package de.tutorials;
 
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.PrintWriter;
import java.net.InetSocketAddress;
import java.util.concurrent.TimeUnit;
 
import com.sun.net.httpserver.HttpExchange;
import com.sun.net.httpserver.HttpHandler;
import com.sun.net.httpserver.HttpServer;
 
/**
 * @author Tom
 * 
 */
public class HttpServerExample {
 
    /**
     * @param args
     */
    public static void main(String[] args) throws Exception {
        HttpServer httpServer = HttpServer.create(new InetSocketAddress(8080),
                0);
        httpServer.createContext("/tutorials", new HttpHandler() {
            public void handle(HttpExchange httpExchange) throws IOException {
                System.out.println(httpExchange);
                httpExchange.getResponseHeaders().add("Content-type", "text/html");
                
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                
                PrintWriter printWriter = new PrintWriter(baos);
                printWriter.println("<html><b>Hallo Welt</b></html>");
                printWriter.close();
                
                httpExchange.sendResponseHeaders( 200, baos.toByteArray().length );
                
                httpExchange.getResponseBody().write(baos.toByteArray());
                httpExchange.getResponseBody().close();
 
            }
        });
        httpServer.start();
        TimeUnit.SECONDS.sleep(Integer.MAX_VALUE);
    }
 
}

++++ Performance : http://java.sun.com/performance/refe...rformance.html (kommt bald

Verbesserungen bei Support für Filtern und Sortieren von JTables out of the box... uvm.

zu den genannten Punkten:
1) Tray ist nicht nur "Eye Candy" sondern ein wichtiger Baustan um gut ins Window-System integrierbare Anwendungen zu bauen. (Btw. Tray suppot gabs auch schon früher... Cross-Platfrom (Soweit die Window-Systeme das unterstützen) mit https://jdic.dev.java.net/ und SWT Tray/TrayItem)

2)Splash Screens ... native Unterstützung für Splashscreens ist ne feine Sache da der Splashscreen schon angezeigt wird bevor die Anwendugn geladen wird. Na ja, ist ein Gimmick aber IMHO nicht so wichtig.

3)WS-API damit wird das erstellen von Webservices so einfach (und noch einfacher) wie das erstellen von Webservices unter .Net

Ist ist aber die Frage wie flexibel das WS API ist und ob damit andere WebService Frameworks wie AXIS, XFire, Hessian, Burlab etc. mit der Zeit aussterben werden, ich denke nicht...

4) Mit der Unterstützung für Script Sprachen innerhalb einer JVM erhält man die wunderbare Möglichkeit
bestimmten Code dynamisch austauschbar zu machen.
Als Beispiel denke man da an sich ständig verändernde Preisberechnungsschemata, Validierungsregeln,
Workflow-Definitionen etc...) die Möglichkeiten sind fast unbegrenzt

Eine gängige Anwendung ist ein in die Anwendung integrierter Interpreter mit dem man zur Laufzeit eigene Skripte definieren und ausführen kann,
die dann Teile der Anwendung steuern, so ne Art VBA für Java

Außerdem stehen neben Jython, Groovy und JRuby auch zahlreiche weitere Sprachen zur Verfügung die sich alle recht einfach integrieren lassen.

5) Na ja, Console API... macht die Sache für Anfänger um einiges leichter, aber das gabs auch schon unter Java 5 mit dem java.util.Scanner

6) Na ja, direkt ne Derby DB mit Java zu Bundlen ist so ne Sache,... zum einen wird dadurch die Sache für Anfänger um einiges leichter, da sie direkt mit einer Fix und Fertig konfigurierten DB erste JDBC experimente machen können.
Zum anderen wird dadurch aber die größe des JDK's / JRE's ein wenig aufgebläht... ich kann mich noch an Zeiten erinnern als das komplette JRE knapp 9 MB groß war... mit Java 6 sinds 92 MB ...

Genau so sehe ich das auch. Irgendwie geht doch der ganze Grundgedanke der Platformunabhängigkeit flöten oder nicht?!

Der Java Kern ist ja auch Platformunabhängig. Manche Features lassen sich für einige Platformen eben einfacher implementieren als für andere. Die wirklich Platformabhängigen Geschichten betreffen zumeist irgendwelche Elemente der UI da die Implementierungen / Konzepte sich hier teilweise erheblich unterscheiden... außerdem gibt es in der Java Community relativ schnell Lösungen um auf bestimmten Platformen fehlenden Features nachzubauen oder zur Not zu emulieren.

Was ist von dem einzelnen zu halten?
Wie voll/groß soll es noch werden? Klar ist es schön alles aus einem Paket zu bekommen, die Frage ist, ist es nicht irgendwann zu viel/unübersichtlich? Oder sollte man nicht ein paar Sachen aufspalten?

Ich halte Java jetzt schon für unübersichtlich... für jemanden der jetzt neu Anfängt ists wirklich sehr schwer sich einen Überblick zu verschaffen...

Gruß Tom

flashray · 25.12.06 00:12

Hallo Tom,

Zitat von Thomas Darimont

Zum anderen wird dadurch aber die größe des JDK's / JRE's ein wenig aufgebläht... ich kann mich noch an Zeiten erinnern als das komplette JRE knapp 9 MB groß war... mit Java 6 sinds 92 MB ...

da ist dir glaube ich ein Fehler unterlaufen

!
9MB -> 92MB

Das JRE 6 ist nur
Win -> 12MB
Linux -> 17MB
groß.

Das JDK 6 beträgt
Win -> 53MB
Linux -> 57MB

Vg Erdal

**Thomas Darimont** · 25.12.06 00:28

Hallo!

ich kann mich noch an Zeiten erinnern als das komplette JRE knapp 9 MB groß war... mit Java 6 sinds 92 MB ...

... FRÜHER war das ganze JDK (beinhaltet das JRE) knapp 9 MB groß ... (1.1.8...)
HEUTE sinds mit Java 6 (wenn man das JRE installiert bei mir out-of-the-box) 92 MB. Seit Java 5 gibts aber noch den classes.jsa Class-Cache der bei mir auch noch mit 13 MB in der Rechnung auftaucht.

Die alten Java Versionen findet man übrigens hier:
http://java.sun.com/products/archive/

Gruß Tom

flashray · 25.12.06 00:32

Aso, du meintest die größe nach der Installation. Dann kommt das natürlich hin!

Vg Erdal

tut orials.de	tut verbinden	tut dir helfen	tut kooperieren
©2000-2012 tutorials.de Alle Rechte vorbehalten	tut informieren » Impressum » Nutzungsregeln » Netiquette » Team » Redaktion	» Tutorials » Videotutorials » Showroom » Events & Contests » Chat » RSS-Feed » Blogs	» der-webdesigner.net » DesignerInAction » Design Nation » Directorforum » Flashhilfe » PHP-Resource » PHPwelt » PSD-Tutorials

Themen-Optionen

Anzeige

Ähnliche Themen

Einfache Webservices unter Java 6 Mustang

[Mustang] Heap Analyse unter Java 6

[Mustang] Liste der API Aenderungen in Java 6

Java 6 Mustang & ein Blick hinter die Kulissen

SplashScreen API in Java 6 (Mustang)

E-Mail:

Abonnieren Abbestellen