Was haltet ihr von "kompiliertem" Java?
-
Moin!
Was würdet ihr von einem kostelosen Compilier halten, der Java zu .Exe-dateien compilieren kann, den es für Linux und Windows gibt, der kostenlos ist.
Die einzige Einschränkung ist, dass er derzeit kein AWT oder SWING hat, es wird aber hart daran gearbeitet.
Außerdem sind manche packages noch nicht dabei oder noch nicht ganz vollständig, ein team ganz ausgebrühter hat es aber schon zusammenbekommen, ein kompiliertes Eclipse laufen zu lassen:
http://www.klomp.org/mark/gij_eclipse/jaxup.pngKLing verlockend, äh?
Mfg Linxuhippy
-
du redest vom gcj?
-
1. Das ist nicht wirklich was neues. Guck mal hier: http://www.geocities.com/marcoschmidt.geo/jcomp.html#native
2. Das ist IMHO nicht wirklich interessant. Wo sollen die Vorteile liegen?
-
Wenn das Kompilat relativ klein ist dann würde es wohl für den einen oder anderen etwas Sinnvolles sein
-
Moin!
ja
Mfg Linxuhippy
-
2. schneller
-
Original erstellt von <1.>:
2. schnellerDas kann man so allgemeingültig nicht sagen. Guck dir z.B. mal den Volano-Report an: http://www.volano.com/report/
Was die Performance betrifft, ist da die IBM JVM die schnellste JVM. Das Programm ist da schneller, als mit TowerJ oder mit Excelsior JET. ...bei dem 2. Test sieht es dann wieder ganz anders aus.
...ich sehe zumindest keinen deutlichen Geschwindigkeitsvorteil bei native-Compilern. Kennst du irgendeinen Test, der so einen Geschwindigkeitsvorteil deutlich zeigt?
-
BTW : Weiß jemand, ob das mit dem GCJ eigentlich irgendwann nochmal etwas ernsthaftes wird?! Mir kommt es so vor, als ob der schon sehr lange etwa 50% fertig ist und einfach nicht weiter kommt (bezieht sich auf den Status der Standardbibliothek).
Da ist ja sogar Mono für C# schon deutlich weiter! Die stehen immerhin bei 78%, allerdings auch schon sehr lange.
-
Ein Java Compiler ist eh nicht sehr sinnvoll. Die Spezifikation von Java verbietet ja schon fast Geschwindigkeit.
:p
-
Original erstellt von Mr. N:
Ein Java Compiler ist eh nicht sehr sinnvoll. Die Spezifikation von Java verbietet ja schon fast Geschwindigkeit. :pBitte erklären!
:p
-
Original erstellt von Gregor:
Bitte erklären! :pPunkt 1: ÜBERALL virtuelle Funktionen
Punkt 2: gesicherte Arrays
Punkt 2b: die ganzen Sicherheitssachen (die 10000 Checks)das fällt mir spontan ein
-
Servus!
Das einzige was dem GCJ derzeit fehlt ist AWT, ich arbeite mit einem anderen Freund an SWING.
Für AWT gibt es schon eine weitgehende Implementierung, nur ist diese derzeit ein wenig instabil.@Fortschritt:
Alleine die Geschwindigkeitsvortschritte von 3.0.4 auf 3.2 sind enorm! Beim Scimark überrundet er die Sun-JVM um über 30%.@Design: Ja glaubst du denn, eine VM muss die checks nicht machen. Bereichsprüfung ist aber bei kompilierten Sprachen wirklich nix neues, und virtuelle Funktionen kann man schon zur compiletime falls möglich devirtualisieren, damit muss sich die VM zur Laufzeit auseinandersetzten, und entscheiden was schneller ist: Genau devirtualisierung oder doch lieber einfach drüberfahren.
Ein Compilier hat das nicht!@Sinn: Ich sehe den größten sinn einfach darin, dass der Nutzer keine 50Mb-große VM installieren muss. Ich arbeite in einem Softwarehaus, das schmerzlich erfahren muste, wie schlecht Java von Windows-Usern angenommen wird, nur weil diese eine VM benötigen.
Mfg Clemens
-
swing kann der gcj doch auch nicht.
-
Original erstellt von <Naja....>:
**
@Fortschritt:
Alleine die Geschwindigkeitsvortschritte von 3.0.4 auf 3.2 sind enorm! Beim Scimark überrundet er die Sun-JVM um über 30%.
**Naja! Zugegeben: Die Sun-JVM ist auch nicht die schnellste virtuelle Maschine. Die 30%, von denen du da berichtest, schafft die IBM JVM wohl auch locker. Zumindest, wenn man sich mal einige vergleichbare Werte aus den folgenden Benchmark-Ergebnisses raussucht: http://math.nist.gov/cgi-bin/ScimarkSummary?complete
...ich bin aber trotzdem sehr gespannt, was aus dem GCJ wird.
