[JAVA] Wieso finden viele Leute Java einen "Murks"?

[Michel.Eichelberger]

<vermut> du bist nicht verantwortlich für den produktiven Betrieb einer Server-Farm ;)

Kommt noch, aber in demfall danke für die Wanrung :)

Jah, sorry, aber du weisst gar nicht, was ich diesbezüglich (Flames) schon alles erlebt habe... n halbes Trauma :D
Zur Anzahl Sprachen in der JRE sei dir diese Seite ans Herz gelegt: http://www.is-research.de/info/vmlanguages/

Naja, du vergleichst die Anzahl der Sprachen die tatsächlich genutzt werden mit denen die für Testzwecke entwickelt wurden. Klar, bei .NET werden auch nicht alle Sprachen richtig genutzt. Brainfuck.NET ist genauso eine esoterische Programmiersprache wie Brainfuck selbst :)

Ich hab nichts gegen die Sprache Java, ich bin auch kein Fanboy von .NET wenn du vielleicht das Gefühl hast, aber es ist eine Tatsache, dass .NET auch wenn es als Konzeoptionskopie von Java gilt gut durchdacht ist. Im Gegensatz zu Windows ist .NET und Visual Studio ein Produkt, welches wirklich auch funktioniert (im normalfall) :P

 

[zilti]

Nein, das hab ich nicht das Gefühl, und ich habe bis jetzt auch nur gute Erfahrungen mit .NET als Laufzeitumgebung gemacht (auch wenn sich dies hauptsächlich auf Paint.NET beschränkt, welches ich einst kurze Zeit gebrauchte). J# wurde übrigens eingestellt und war - meines Wissens - nur dazu gedacht, Java-Entwickler zum Umstieg auf .NET zu bewegen, indem man ihnen eine ansatzweise gleiche Sprache bot (ich habs mal getestet - die Unterschiede sind beträchtlich). Über den (Miss-)Erfolg der Aktion weiss ich allerdings nichs.

 

[Michel.Eichelberger]

Jup, J# wurde mit dem Aufkommen von .NET 3.5 und VS2008 eingestellt. Was ansich nicht so schlimm ist. C# ist in dieser Hinsicht der Syntax von Java ja ziemlich ähnlich.

.NET bzw. C# bietet gegenüber Java jedoch schon einige Vorteile, welche auf den ersten Blick nicht wirklich wie ein Vorteil erscheinen.

WPF ist ein Konzept, welches interessant ist und wie erwähnt ist auch die Möglichkeit mit XNA für die XBOX360 Spiele programmieren zu können doch recht attraktiv für viele Programmierer.

.NET entwickelt sich immer mehr, für die einen sinnvoll für die anderen nicht. Es kommt schlussendlich wiederum auf die User drauf an.

Ich selbst arbeite immernoch mit Windows Forms, weil ich für meine Projekte die WPF nicht brauche, wenn auch interessant, aber für die Praxis nicht notwendig.

Silverlight ist ebenfalls eine interessante Sache, jedoch wird auch diese Technologie zur Zeit kaum gebraucht.

 

[nimloth713]

Antwort?

Um zurück auf die eigentliche Frage zu kommen: Viele Leute sind schlicht und einfach schlecht informiert und plappern anderen - ebenfalls schlecht informierten nach. (-:

Zu den häufigsten Gerüchten eine Sicht von mir:

- Performance: Oftmals wird Java als langsam bezeichnet aus diversen Gründen. Natürlich, Java wird zuerst interpretiert, dies bedeutet das die eigentlich Anweisung übersetzt wird in eine Anweisung für den Computer. Dieser Zwischenschritt braucht natürlich Zeit. Nur, die Heutigen JVMs sind dermassen optimiert - sie compilieren nämlich gewissen Code nach einer gewissen Zeit in nativen Code - da es einem durchschnittlichen C++ Programmierer nicht gelingt, eine schnelleres pendant zu einem Java Programm zu schreiben. Wohl gemerkt, diese Aussage gilt für durchschnittliche Programme. Es gibt für das auch belege, google hilft hier weiter.

- Natürlich werden jetzt einige Einwenden: "Ja, aber das GUI, das ist total langsam". Das war teilweise richtig, wurde aber von Version zu Version drastisch verbessert. Zudem liegt es aber oftmals auch daran, dass die meisten Programmierer zu unsorgfältig sind arbeiten. Ein gutes Beispiel für ein relativ gutes Java Programm ist natürlich LimeWire. (-:

Allgemein Aussage die nichts mit der Technologie zu tun hat: Im Grunde genommen sind java und .NET gar nicht so anders. Das eine hat in einem Bereich einen Vorteil, dass andere in einem anderen Bereich. Was aus meiner Sicht wichtiger ist, sind die Fragen:

- Plattform übergreifend? Java erfüllt hier - wenn man es richtig macht! Ja, bei .NET gibt es Mono aber, was ist dort der Status? Und, wird es ein Mono für Mac geben? Der Mac nimmt langsam Marktanteile in Anspruch, kann also nicht ohne weiteres "vergessen" werden.

- Die Zukunft der Plattform selbst: Java ist nun OpenSource - jeder kann daran entwickeln. Natürlich hat SUN hier den Lead, und es gibt doch gewisse Spielregeln, aber im Grunde genommen kann ich eine Korrektur vornehmen wenn ich das müsste. Natürlich gibt es hier ganz klare Gründe die dagegen sprechen, nur ist das grundsätzlich möglich.

So, jetzt habe ich auch noch meinen Senf dazu gegeben! (-: Ich selbst muss sagen: Ich bin mit Java recht zufrieden. Ich entwickle ein Desktop CMS in Java und bis anhin hat sich das als wunderbar erwiesen. Obwohl, zugegebener massen, ist es auch nicht lauffähig auf allen Plattformen - aber in voller Absicht momentan. Ich hoffe ich kann das in naher Zukunft ändern. (-:

Viele Grüsse und schönen Abend

 

[kofi2k]

Soweit so gut, ich erlaube mir dennoch kleine Korrekturen, zu .NET kann ich wenig sagen, da ich das noch nicht benutzt habe.

- Performance: Oftmals wird Java als langsam bezeichnet aus diversen Gründen. Natürlich, Java wird zuerst interpretiert, dies bedeutet das die eigentlich Anweisung übersetzt wird in eine Anweisung für den Computer.

Ja und Nein: Mit Java kann man benutzen...

• JIT Compiler: Just in Time Comp. = interpretiert Sourcen,wohl auch deswegen langsamer.
• Bytecode Compiler: Schneller, ist aber noch platfformunabhäng
• Maschinencode Compiler: Am schnellsten, da nicht noch Bytecode interpretiert werden muss, aber nicht mehr Plattformunabhängig binaries.

C# und Java sind werden einander immer ähnlicher. C# hat zuerst bei Java abgekukt, nun kommen immer mehr C# Sachen nach Java.

An einigen Unis wird wohl deswegen Java gemacht, weil es eine verbreitete Programmiersprache ist, die auf allen Plattformen verfügbar ist und etwa durch automatische Garbage Collection und der riesigen Standard-Library um einfacher als C++ ist. - Will aber nicht heissen, dass es überall so toll ist.

So das waren meine 2 cents.

 

[zilti]

Der JIT ist Standard. Er interpretiert den Code eben nicht, sondern kompiliert die gerade benötigten Codeabschnitte beim ersten Gebrauch zu Maschinencode. Wird also ein Code mehrfach ausgeführt, ist er ab der 2. Ausführung fast so schnell wie z.B. C++. Der kompilierte Code wird nach Programmende wieder aus dem RAM gelöscht.

 

[Michel.Eichelberger]

Der kompilierte Code wird nach Programmende wieder aus dem RAM gelöscht.

Weiss nicht ob das bei Java anders ist, aber bei .NET bleiben die kompilierten Teile im Cache (wie bei einer normalen Anwendung) und werden erst gelöscht, nachdem sie überschrieben werden.

Das heisst, wenn ich ein .NET Programm ausführe und dann beende, dann startet dies schneller beim nächsten Start.

Die Speicherverwaltung bezieht sich hierbei nur auf den Arbeitsspeicher, nicht jedoch auf den Cache.

 

[pagefault]

Sun ist lernfähig

Einen Teil meiner Kritik am Java Updater darf ich jetzt zurück nehmen: Seit JRE 6u10 unterstützt Sun die "richtige" Aktualisierung der JRE!
Das aktuelle Sicherheits-Update von JRE 6u10 auf JRE 6u11 hat tatsächlich einwandfrei geklappt und nur die aktuelle JRE 6u11 auf dem System zurückgelassen. Bravo Sun - diese grossartige Idee hättet ihr schon vor Jahren haben können ...

 

[nimloth713]

• JIT Compiler: Just in Time Comp. = interpretiert Sourcen,wohl auch deswegen langsamer.
• Bytecode Compiler: Schneller, ist aber noch platfformunabhäng
• Maschinencode Compiler: Am schnellsten, da nicht noch Bytecode interpretiert werden muss, aber nicht mehr Plattformunabhängig binaries.

Also: Der Java-Code wird als erstes Interpretiert - interpretiert, weder compiliert noch sonst was. Dann, nach einer gewissen Zeit, wird der Code compiliert - in maschinenabhängigen Code. Zugleich optimiert der JIT, oder auch Hot-Spot Compiler, das ganze noch - weiss allerdings nicht, ob die Optimierungen nur in den compilierten Code oder aber auch den ByteCode betrifft. Letzteres hätte wohl den grösseren Nutzen und wäre wohl einfacher um zu setzen. Aber das ist dann doch spekulation meiner seits.

Soviel ich weiss ist das bei .NET etwas anders: Dort werden die Assemblies doch vorcompiliert und anschliessend nur noch ausgeführt, es werden keine weiteren Optimierungen mehr vorgenommen - ist das richtig?

Kann man eigentlich in .NET auch die Strategy des Garbage Collectors wählen? In Java kann man zum Beispiel einen "parallel Collector" wählen - besonders für multi-code, mehr Prozessor praktisch.

C# und Java sind werden einander immer ähnlicher. C# hat zuerst bei Java abgekukt, nun kommen immer mehr C# Sachen nach Java.

Joa, das hat was. Allerdings macht für mich C# im Moment den Eindruck als biete es möglichst viele Features ohne dabei wirklichen mehrwert zu generieren. Ein Sprachfeature ist natürlich immer gefährlich, weil es nicht jeder gleich gut beherrscht, was im Team je nach dem zum Problem werden kann.

Hey, vielleicht können wir ja noch das Thema "type safety" ansprechen - dann kommt noch die Gruppe mit den dynamischen typisierten Sprachen dazu! *grins* (-;

An einigen Unis wird wohl deswegen Java gemacht, weil es eine verbreitete Programmiersprache ist, die auf allen Plattformen verfügbar ist und etwa durch automatische Garbage Collection und der riesigen Standard-Library um einfacher als C++ ist. - Will aber nicht heissen, dass es überall so toll ist.

C++ hat sehr wohl seinen Platz in der Welt - native Sprachen wird es immer geben und wohl auch immer geben müssen. Für das tägliche Business ist aber wohl eine Sprache resp. Platform wie Java oder .NET gescheiter.

Viele Grüsse zu später Stunde

 

[kofi2k]

Man lernt immer wieder etwas dazu
Bisher habe ich vorwiegend mit "javac" als Compiler gearbeitet, welcher nachweislich Bytecode .class Dateien produziert.

Also: Der Java-Code wird als erstes Interpretiert - interpretiert, weder compiliert noch sonst was. Dann, nach einer gewissen Zeit, wird der Code compiliert - in maschinenabhängigen Code. [...]

Nun, ich bin da noch nicht so weit, aber eigentlich meinte ich das Bytecode auch Bytecode bleibt und nicht einfach so mal zu nativem wird. Oder passiert das in Business Anwendungen? Ein Link zum nachlesen wäre toll.

C++ hat sehr wohl seinen Platz in der Welt - native Sprachen wird es immer geben und wohl auch immer geben müssen. Für das tägliche Business ist aber wohl eine Sprache resp. Platform wie Java oder .NET gescheiter.

Das will ich keinesfalls abstreiten, ich habe nach einem Grund gesucht, warum im Moment Java so präsent an den Unis ist.

 

[nimloth713]

Man lernt immer wieder etwas dazu
Bisher habe ich vorwiegend mit "javac" als Compiler gearbeitet, welcher nachweislich Bytecode .class Dateien produziert.
[...]
Nun, ich bin da noch nicht so weit, aber eigentlich meinte ich das Bytecode auch Bytecode bleibt und nicht einfach so mal zu nativem wird. Oder passiert das in Business Anwendungen? Ein Link zum nachlesen wäre toll.

Der Javac produziert natürlich ByteCode und dieser wird auch am Anfang interpretiert. Wenn aber gewisse Methoden sich als "Hot-Sot" erweisen, werden diese optimiert - und auch von dem JIT in nativen Code compiliert. Das ist eben der Sinn der Sache: Die JVM weiss auf welcher Architektur sie läuft und kann entsprechend auch optimieren.

Diese Infos findest du praktisch überall im Netz, aber ich würde mal mit dem Performance White-Paper anfangen - weiss allerdings nicht ob das da dring steht - sollte eigentlich. Werde dir am Abend versuchen einen "besseren" Link zu finden.
http://java.sun.com/performance/reference/whitepapers/6_performance.html

Man lernt immer wieder etwas dazu
Das will ich keinesfalls abstreiten, ich habe nach einem Grund gesucht, warum im Moment Java so präsent an den Unis ist.

Hier habe ich oft gelesen, dass die Einfachheit der Sprache geschätzt wird - ob das der einzige oder der einzig wahre Grund ist weiss ich allerdings nicht.

Viele Grüsse