Diskussion:Java (Programmiersprache)/Archiv/2

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Java (Programmiersprache)/Archiv/2#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Java_(Programmiersprache)/Archiv/2#Thema_1

Einfach?

Kritisieren würde ich z. B. die in sich völlig verknotete Standardbibliothek. Zum Beispiel ist java.nio ein fürchterliches Paket, dass überhaupt nicht vernünftig integriert ist. Warum sind nicht blockierende Sockets nicht vernünftig integriert wie in anderen Sprachen auch? Daher stimmt IMHO auch die Behauptung nicht, dass Java einfach wäre, denn die Sprache hängt untrennbar mit der Standardbibliothek zusammen. Diese hat inzwischen auch etliche Altlasten, die jeweils eine besondere Berücksichtigung erfordern (z. B. Enumeration vs. Iterable oder Vector vs. ArrayList). Ein anderes Beispiel ist die Verwaltung von Datumsangaben. Um ein einfaches Datum zu verwalten benötigt man fünf Klassen (Calendar, GregorianCalendar, Date, DafeFormat, SimpleDateFormat). Vielleicht wäre das ein Vorteil, wenn auch andere Kalendersystem untersützt werden würden. Das ist aber nicht der Fall. Dazu ist die Standartbibliothek außerdem hochgradig inkonsistent. Warum ermittelt man die Anzahl der Elemente einer Liste mit der Methode size(), bei einer Zeichenkette mit der Methode length() und bei einem Array mit dem Attribut length? Das ist kompliziert und außderdem völliger Unsinn. -- 93.197.175.183 21:30, 6. Mai 2012 (CEST)

Deine Kritikpunkte an der Klassenbibliothek sind gerechtfertigt. Im Artikel steht aber nirgendwo, dass die Java Klassenbibliothek einfach wäre (was sie mMn im Vergleich zu den wenigen andern überhaupt verfügbaren Klassenbibliotheken sogar ist). Im Artikel steht "Der Entwurf der Programmiersprache Java strebte hauptsächlich fünf Ziele an ... einfache Programmiersprache". Es geht also gar nicht um die Klassenbibliothek, sondern um die Sprache und auch nicht um den Ist-Zustand sondern um das damalige Ziel (das mMn eindeutig erreicht wurde und bisher auch nicht wirklich übertroffen wurde - aber das ist meine persönliche Meinung). --Sebastian.Dietrich ✉ 23:55, 6. Mai 2012 (CEST)

+1

1. Java ist „einfach“ im Vergleich zur damaligen Alternative: C++
   • Ich hatte nach einigen Jahren C++ die Verwendung von Java in neuen Projekten als Erleichterung wahrgenommen. Die Pointer-Arithmetik und Referenzierung und De-Referenzierung dem Menschen aufzubürden ist grausam. Auf Anwendungsebene braucht niemand die Speicheradressen; sowas ist allenfalls in höchsteffizienten Elementarfunktionen im Assembler-Stil erforderlich. Es hatte zu Myriaden von Bugs in C++ geführt; ansonsten brauche ich das Objekt und dessen Eigenschaften und will mich nicht mit dem Pointer auf Pointer auf selbstgemachte Allokierung und De-Allokierung beschäftigen müssen.
2. Klassenbibliotheken sind nicht gleich Standardbibliothek sind nicht „untrennbar“ mit der Sprache verbunden: Zur Sprache gehört sicher java.lang – aber nicht die Modellierung von menschengemachten Kalendersystemen und ein Angebot an Containerformaten oder HTML-Unterstützung.
3. Die angebotenen Klassenbibliotheken sind – ein Angebot. Sie ersparen einem Programmierarbeit, aber wenn sie jemandem nicht gefallen, dann muss man sie nicht verwenden.
   • Zur Entstehungszeit in den frühen 1990ern gab es noch nicht die weltweiten Internet-vernetzten Communities; die Ur-Klassen sind firmen-intern spezifiziert worden. OpenSource war nicht die Zielrichtung, die Linux-Erfahrung hatte man noch nicht gemacht.
   • Würde man sich heute an eine Spezifikation für ein offenes Produkt machen, würde man Gemeinden wie Mozilla oder Linux in eine vorangehende ausgiebige Definition einbeziehen und durch Schwarmintelligenz hoffentlich zu einer stringenteren Definition kommen – was aber auch nicht gesichert ist; das Kategoriensystem der deWP hatte sich auf diese Weise entwickelt.
   • Die benannten „Altlasten“ müssen aus Kompatibilitätsgründen weiterhin unterstützt werden. Es liegt an dir, konzeptionelle Entscheidungen zu treffen, welche dieser Container du einsetzen möchtest und welche du ablehnst.
   • Es gibt im Netz -zig Bibliotheken-Sites, die ihre eigenen Problemlösungen auch zu allgemeinen Fragen anbieten. Die kannst du gern verwenden, musst dir dann aber über die Verfügbarkeit und Weiterverteilung Gedanken machen.
4. Zu den Beispielen im Einzelnen:
   • java.nio – Warum sollen „nicht blockierende Sockets nicht vernünftig integriert“ sein? Was würdest du damit meinen? Die in C begonnene Trennung von Sprachkonzept auf der einen Seite und anwendungsbezogenen Funktionen wie I/O und hier speziell die Modellierung eines abstrakten Dateisystems und Netzwerkverhalten wirst du wohl nicht in Frage stellen?
   • Container:
     • Vector ist synchronized, ArrayList nicht. Beide sind ansonsten gleichwertige Implementierungen vonAbstractList.
     • Array und Vector sind zwei grundverschiedene Konzepte; random access oder modifiable. Dass hier völlig unterschiedliche Methoden zur Feststellung der Element-Anzahl benutzt werden, hat mich noch nie gestört. Alle collections verwenden .size() – .getSize() wäre noch hübscher. Bei einem Array mag es halt .length() oder feiner .getLength() heißen. Eine Eigenschaft .length sehe ich in diesem Bereich gerade nicht. Bei einem String muss ich sowieso erstmal darüber nachdenken, ob diese length in bytes oder chars gesucht wird; das ist viel schwieriger.
   • Datum:
     • Verwunderlich ist es erstmal nicht, dass es zwei Klassen gibt – das Date für die Information selbst und sauber getrennt DateFormat. Letzteres auch benutzerdefinierbar zu erweitern.
     • Und dann gibt es bei dieser doofen Menschheit etliche Kalendersysteme. Das ist die Modellierung eines RL-Systems und kein Sprachbestandteil. Im Web kursieren auch hebräische, chinesische und Maya-Klassen. GregorianCalendar ist die einzige mit der Java-Installation selbst verbreitete Klasse. Also braucht man für die Verwaltung eines Zeitpunkts Date mindestens zwei weitere Klassen, um sich an alle Rahmenbedingungen anpassen zu können.

Schönen Tag --PerfektesChaos 10:18, 7. Mai 2012 (CEST)

Kritik

Gibt es denn überhaupt keine Nachteile oder irgendeine Kritik im zusammenhang mit Java? Irgendwelche Kontroversen? Warum würde man manchmal eine andere Sprache wählen? (nicht signierter Beitrag von 87.153.132.154 (Diskussion) 08:17, 9. Feb. 2012 (CET))

Du hast recht - es gibt viel (begründete und unbegründete) Kritik/Kontroversen rund um Java. Diese wären in einem Kritik Abschnitt in Java (Technik) mMn besser aufgehoben, da sie nur selten die Programmiersprache selbst, sondern meist die gesamte Technik betreffen. mMn gibt es aber nur 2 Situationen, wo Java deutlich andern Umgebungen unterlegen ist: 1) bei hardwarenaher Programmierung (--> C oder Assembler) und 2) bei quick&dirty release-early Web-Programmierung. --Sebastian.Dietrich ✉ 09:17, 9. Feb. 2012 (CET)

Nein, es gibt definitiv Kritik an der Programmiersprache Java. In anderen Sprachversionen findet sich solche auch. Wie man sieht, besteht bei dieser Kritik kein allgemeiner Konsens, aber sie existiert. Gerade bei denen, die sich gut mit Java auskennen und da viel Erfahrung haben.--Karl Brodowsky 22:00, 9. Feb. 2012 (CET)

Natürlich gibts Kritik - z.B. "kann keine Closures", "ist stark typisiert", "hat keine Properties a la C#", ... - aber für all die Punkte gibts Pros und Contras. Mir fällt auf die Schnelle nichts ein wo es halbwegs einen Konsens gibt, dass es in Java schlecht wäre. Ich fände es aber nicht gut in einem Kritik Abschnitt zu schreiben "Kann keine Closures. Fänden viele wichtig, andere fändens schlecht. Kommt vermutlich (Gott sei Dank / leider) mit Java 8". Auch mit Referenzen für Pro und Contra käme nur raus, dass sich die IT einfach nicht einig darüber ist, was gut und was schlecht ist. --Sebastian.Dietrich ✉ 23:01, 9. Feb. 2012 (CET)

Nun, ich stimme der IP zu, es fehlt in diesem (und auch den assozierten Java-Artikeln) die Rezeption bzw. die kritische Auseinandersetzung mit Motivation, Zielen und Evaluation der Java-Technologie. Und viele diskutierte Fragen zu Konzepten und Ergebnissen von Java gehen über "subjektive Geschmacksfragen & Details" (wie von Sebastian.Dietrich angedeutet) weit hinaus. Ob z.B. das oft propagierte, fundamentale Versprechen "write once, run everywhere" tatsächlich von Java erreicht wurde wird immer wieder von einigen kritisch diskutiert, ebenso das Thema Performance/Effizienz (Frage ob microbenchmarks von alogrithmen wirklich die Real-World performance abbilden, vor allem da sie im gegensatz zu gehäuften Berichten über mässige Leistungsfähigkeit und User-experience von existierenden Applikationen stehen). Zu der Sprache: die wird von einigen als zu "verbose", einschränkend und ineffizient (pro Codezeile) beschrieben um schon einfache Dinge auszudrücken. Nachdem vor allem der akademische Betrieb sehr aufgeschlossen gegenüber Java war (häufig erste Sprache die Studenten lernen), gibt es jedoch auch einzelne die davon wieder abkehren zB die Carnegie-Mellon University wirft JaVA/OOP aus dem Lehrplan. Professor Robert Harper März 2011: This semester Dan Licata and I are co-teaching a new course on functional programming for first-year prospective CS majors... Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic. Eine bekannte Java-Kritik aus dem englischsprachen Raum, Steve Yegges Glosse über die Unnatürlichkeit damit die Welt zu modellieren: Execution in the Kingdom of Nouns gruss Shaddim (Diskussion) 16:37, 27. Mai 2012 (CEST)

hmm, weiteres heissdiskutiertes Themen: das erzwungene nicht-explizite Memorymanagment in Java. Einerseits lässt dies Programmierer glauben ressourcen-managment (auch über memory hinaus) wird von der run-time-engine auf magische weise perfekt erledigt. Dies ist jedoch nicht so, erstens ist sie kein Allheilmittel (http://blog.dynatrace.com/2011/04/20/the-top-java-memory-problems-part-1/ formen der memoryleaks mit garbage collection), zweitens hat sie einen hohen Preis, im mittel ca. 50% höheren memoryverbrauch und einen erhöhten nicht-determinismus beim laufzeitverhalten & der speicherallokierung. Weitere enWP artikel die material für einen Rezeptions/Kritikabschnitt bieten: en:Comparison_of_Java_and_C++ en:Criticism of Java (bei diesen Artiekln lohnt es sich auch die Entwicklunshistorie zu betrachten.) gruss Shaddim (Diskussion) 17:03, 27. Mai 2012 (CEST)

Wechselwirkung mit anderen Programmiersprachen

• Dass C++ und die Vermeidung dortiger Nachteile Java beeinflusst hat, ist allgemein bekanntes Elementarwissen. Gleichfalls die Orientierung an Smalltalk als prominentem Vorreiter.
• Ebenfalls zur verbesserten Allgemeinbildung gehört, dass Microsoft etwas eigenes statt Java haben wollte; auch plattformunabhängig und vor allem ohne das Referenzierungs-Dereferenzierungs-Gefummel in C++, das kein Anwendungsprogrammierer brauchen kann. Natürlich stand das seit einem Jahrzehnt erfolgreiche Java Pate für C#.
• Nur marginal scheint mir hingegen die spätere Rückwirkung von C# auf Java zu sein. Hier müsste man mal auflisten, worin diese konkret bestehen soll.

@Sunk: Nur wenn mal elementare und offenkundige Zusammenhänge nicht einzeln mit einem Beleg versehen sind, gibt dir das noch lange nicht das Recht, solche Informationen komplett aus Artikeln herauszulöschen. Genauso machst du bitte auch deine anderen Löschaktionen wieder rückgängig. Danke.

--PerfektesChaos 13:58, 27. Jun. 2012 (CEST)

Es ist komplizierter. Schau mal: Gemäß dem Dokument, das du angegeben hast, gibt es keine Abstammung von Smalltalk. Ferner tauchen Objective-C und C# nicht auf. Und das ist nur das Gröbste in Kürze. Es gibt noch ganz andere Einwände. Es ist alles andere als elementar und offenkundig. Im Gegenteil - in der Tabelle steckt so richtig der Wurm drin. Ich werde die Einträge wieder entfernen. Und du lässt sie bitte draußen. --Sunks (Diskussion) 17:04, 27. Jun. 2012 (CEST)

Nein das wird zuerst ausdiskuttiert und erst danach gelöscht. Gilt für all deine Änderungen an 17 Programmiersprachenartikel. --Sebastian.Dietrich ✉ 17:23, 27. Jun. 2012 (CEST)

Die Einflüsse von Smalltalk, C++ auf Java sind Allgemeinwissen, detto auch der wiederum von C# auf Java (autoboxing, annotations, in Zukunft vermutlich closures). Siehe z.B. http://www.artima.com/weblogs/viewpost.jsp?thread=6543 "Java was an attempt to combine the best features of C++ and Smalltalk .... C# is an attempt to combine the best features of C++, Visual Basic and Java ....". --Sebastian.Dietrich ✉ 17:40, 27. Jun. 2012 (CEST)

<Einrück>Warum liest du dir nicht einfach mal das von Benutzer:PerfektesChaos angegebene Dokument durch? Demnach bleibt Smalltalk außen vor. Offensichtlich gibt es unterschiedliche Ansichten darüber. Inwiefern wurde denn deiner Meinung Java von Smalltalk beeinflusst? --Sunks (Diskussion) 17:02, 28. Jun. 2012 (CEST)

<Einrück>Warum soll ich mir einen anderen Beleg durchlesen, wenn in meinem Beleg drinnensteht "... and Smalltalk". Jeder Java Entwickler weiss, dass die Klassenbibliothek, insbesondere das Collections Framework von Smalltalk beeinflusst wurde. --Sebastian.Dietrich ✉ 17:52, 28. Jun. 2012 (CEST)

a) Warum soll ich mir einen anderen Beleg durchlesen, wenn in meinem Beleg drinnensteht "... and Smalltalk" - Wenn verschiedene Belege zu unterschiedlichen Ergebnissen kommen, ist das ganz schlecht. Denn das bedeutet, dass die Beleglage wackelt. Du kannst dir nicht einfach das rauspicken, was deiner Meinung entspricht.

b) Dann ist also gar nicht die Sprache Java von Smalltalk beeinflusst. Sondern die Klassenbibliothek. Auch in den anderen von dir angegebenen Quellen (s.u.) habe ich keinen Hinweis darauf gefunden, was genau denn von Smalltalk beeinflusst wurde. (Allerdings konnte ich "Beyond Java", S. 152 nicht lesen, s.u.)

c) Da stellt sich natürlich die Frage, inwiefern Objective-C Java beeinflusst hat. Gemäß dem Dokument von PerfektesChaos gar nicht. --Sunks (Diskussion) 06:24, 29. Jun. 2012 (CEST)

So isses. – @Sunks:

1. Es besteht keine Verpflichtung, in einer Infobox jedes einzelne Element mit einem <ref> zu versehen.
2. Du hast kein Recht, pauschal alles als angeblich falsch zu löschen, nur weil an einer Einzelinformation kein <ref> dranhängt.
3. Du hast dich auch nicht als großer Lösch-Zampano aufzuspielen, von A–Z durch alle Programmiersprachen zu marschieren und die Artikel zu kastrieren.
4. Wenn in einem Einzelfall mal eine Verbindung fraglich erscheint, dann hast du die Finger vom Artikel zu lassen und dies zunächst auf der Diskussionsseite anzuzweifeln.
   • Während die Vorbilder von Java unzweifelhaft SmallTalk und C++ sind, und zweifelsfrei C# von Java inspiriert wurde, ist die spätere Rückwirkung von C# auf Java eher dünn. Ich habe das oben thematisiert; man müsste präzise analysieren, ob diese Aussage haltbar ist, und würde ggf. dieses eine Element entfernen. – Du löscht aber pauschal und ohne Diskussion komplette Blöcke aus den Infoboxen.
5. So hast du die Verbindung von COBOL nach ABAP und PL/I mal so eben rausgeschnitten. Das ist hanebüchener Unsinn; völlig egal, ob da jetzt eine Extra-<ref> in der Infobox war oder nicht.
   • ABAP ist nichts weiter als „COBOL für SAP“. Zur damaligen Zeit bestand der komplette Core der SAP-Software aus Cobol, und die hatten sich das schlicht für ihre Zwecke weiterentwickelt und ausgebaut. Genauso geht PL/I zweifelsfrei und ganz bewusst u.a. auf Cobol zurück; so viele Vorbilder an Hochsprachen gab es Anfang der 1960er einfach nicht.
6. Ich habe jetzt keine Lust nachzugucken, was im Artikel steht oder was du beim Buchstaben A schon gelöscht hattest; aber es gibt eine historische Verbindung von Algol nach Pascal.

Wenn du im Einzelfall eine einzelne historische Verbindung in Frage stellen möchtest, darfst du das jederzeit auf der zugehörigen Diskussionsseite tun. Aber lass dich nicht noch einmal bei der Verstümmelung von Artikeln erwischen. --PerfektesChaos 17:58, 27. Jun. 2012 (CEST)

In der Wikipedia besteht Belegpflicht, und wenn ich die einfordere, müssen Quellen angegeben werden. Aus der von dir angegebenen Quelle geht der Zusammenhang mit Smalltalk, Objective-C und C# nicht hervor. Worin besteht deiner Meinung nach der Einfluss von Smalltalk auf Java? --Sunks (Diskussion) 17:02, 28. Jun. 2012 (CEST)

Nein - in der Wikipedia besteht keine Belegpflicht für Allgemeinwissen. Wo ist z.B. belegt, dass Java eine Programmiersprache ist? Wenn Angelika Langer (siehe Ref oben) schreibt, dass Java von Smalltalk & C++ beeinflusst wurde, dann solltest nichtmal du nach einem Beleg fragen.

Hier extra für dich: Beyond Java, Seite 152, Java for Cobol Programmers, Seite 6, Using Java 2, Seite 218, ... --Sebastian.Dietrich ✉ 17:52, 28. Jun. 2012 (CEST)

Das ist kein Allgemeinwissen, sondern Spezialwissen. Wie sonst kann es sein, dass, wie PerfektesChaos schreibt, auch schon "mal eine Verbindung fraglich erscheint". Wenn alles so klar und eindeutig wäre, könnte nichts "fraglich erscheinen".

Ich konnte "Beyond Java", S. 152 nicht lesen. Statt dessen kommt die Meldung "[...]unavailable for viewing". Kannst du bitte zitieren, was da drin steht? --Sunks (Diskussion) 06:24, 29. Jun. 2012 (CEST)

Ich kann den Link lesen, dort steht (nach einem Smalltalk Codestück): "You can see the influence of the elegance of Smalltalk in Java, and other languages, too. Java's garbage collection, design patterns, and collections all share Smalltalk's influence."

Inzwischen reichts aber schön langsam - ich nenne dir 3 Bücher die vom Einfluss von Smalltalk auf Java berichten - du behauptest, dass du dort nicht erkennen kannst was genau beeinflusst worden ist. Was willst denn noch? Für mich ist die Diskussion beendet - der Einfluss ist allgemein bekannt, in 1000en Belegen nachlesbar. Das bleibt also drinnen. --Sebastian.Dietrich ✉ 13:29, 29. Jun. 2012 (CEST)

@Sunks:

• Du argumentierst wie ein Verwaltungsjurist; nicht wie jemand, der sonderlich Ahnung von Software hätte.
• Du bist unbeschadet des Vorhandenseins oder Fehlens von Einzelbelegen nicht befugt, dich durch das Alphabet zu arbeiten und im Minutentakt blockweise Informationen aus Artikeln zu löschen.
• Einige Zitate ausWikipedia:Belege:
  • Entbehrlich sind Belege, wenn etabliertes Wissen wiedergegeben wird und auf der Hand liegt, wo man nachlesen kann. – In diversen der von dir vorgenommenen pauschalen Löschungen der gesamten Infobox-Abschnitte war jeweils in den beeinflussten oder beeinflussenden Programmiersprachen oder gar im Artikel selbst auf Anhieb der Zusammenhang dargestellt.
  • In strittigen Fällen können unbelegte Inhalte von jedem Bearbeiter jederzeit unter Hinweis auf diese Belegpflicht entfernt werden. – An den fraglichen Fällen ist im Regelfall überhaupt nichts strittig; erst recht ist die Komplett-Entfernung sämtlicher aufgeführter Vorbilder und Abkömmlinge völliger Schwachsinn. Die wenigsten Programmiersprachen sind dem Entwickler durch göttliche Eingebung aus dem Nichts zugeflossen; es gab regelmäßig Vorläufer, an denen man sich orientierte, mit denen man aber nicht (mehr) zufrieden war, und die unter Eliminierung unerwünschter Eigenschaften bei Erweiterung um neue Features zu einer neuen Programmiersprache umgebildet wurden.
• Du hättest demnach bei allen von dir von A–D…Z serienweise kastrierten Artikeln zunächst darzulegen, mit welcher guten Begründung du den historischen Zusammenhang zwischen Sprache X und Sprache Y für strittig und anfechtbar hältst, und wie es denn dann schließlich dazu käme, dass die Sprache Y ohne irgendwelche Vorbilder und Einflüsse plötzlich vom Himmel gefallen sei.
  • Dass es hier und da im Einzelfall nur einen schwachen Zusammenhang geben mag, kann durchaus vorkommen; ich selbst habe oben dargelegt, dass die Rückwirkung C#→Java mir dünn erscheinen würde. Ich bin aber lange genug mit der Materie beshäftigt, dass ich sehr genau weiß, dass die anderen Einflüsse wie C++→Java und Java→C# definitiv bestehen und an jeder Ecke nachgelesen werden können. Wer wirklich Ahnung von der Materie hat, guckt einfach mal auf die Jahreszahlen, in die Sprachdefinition und auf den Quellcode. Dann klärt sich ganz fix, was strittig ist und was nicht.

--PerfektesChaos 18:30, 28. Jun. 2012 (CEST)

Du räumst ja selber ein, dass es Zweifelsfälle gibt. Ansonsten siehe meine Antworten an Sebastian.Dietrich. --Sunks (Diskussion) 06:24, 29. Jun. 2012 (CEST)

Entstehungsjahr von JAVA?

Auch ich fände den obigen Bezug zu Android ergänzenswert. Genauso aber vermisse ich eine Antwort auf die Frage, wann JAVA zum ersten Mal "auf den Markt" kam bzw. von SUN vorgestellt wurde ? --Guenni60 20:00, 16. Jan. 2012 (CET)

Steht ohnedies in der Infobox: 1995. Kann ich auch bestätigen --Sebastian.Dietrich ✉ 22:52, 5. Sep. 2012 (CEST)

Erschienen: 1991 vs 1995

Hallo, warum steht auf der englischen Seite 1991 und auf der deutschen Seite 1995 als Erscheinungsjahr? (nicht signierter Beitrag von 88.69.233.207 (Diskussion) 00:40, 6. Okt. 2012 (CEST))

In der englischen Seite steht an 5 Stellen als Erscheinungsjahr 1995. An einer Stelle steht "James Gosling, Mike Sheridan, and Patrick Naughton initiated the Java language project in June 1991." - also nicht das Erscheinungsjahr sondern der Beginn der Entwicklungen. --Sebastian.Dietrich ✉ 11:48, 6. Okt. 2012 (CEST)

IP sah die „1991“ an zwei Stellen: Infobox bis heute nacht – genau da, wo bei uns 1995 steht. Die letzten fünf Wochen stand dort 1991, was wohl am 24. August eingeschleppt worden war. Liebe Grüße --PerfektesChaos 13:02, 6. Okt. 2012 (CEST)

Plattformunabhängigkeit Java

Java kann zumindest auf stationären Computern nicht mehr als plattformunabhängig bezeichnet werden. Hintergrund: Auf 32-Bit-Betriebssystemen wird Java 32-Bit eingesetzt. Auf 64-Bit-Betriebssystemen wird Java 64-Bit eingesetzt. Die kann man zwar vertauscht installieren, aber sämtliche auf Java angewiesene Programme und Entwicklungsprogramme spielen dann da nicht mehr mit. Wenn Java so plattformunabhängig wäre, wie manche behaupten, dann müsste Java 32-Bit auch auf Windows 7 64-Bit laufen und andersrum. Nix mit plattformunabhängig, das war mal so. --77.12.70.80 11:07, 13. Nov. 2012 (CET)

Java hat nix mit 32Bit und 64Bit zu tun. Java selbst ist plattformunabhängig, die auf der Plattform installierte JVM muss aber natürlich schon die richtige sein. Die meisten der von dir angesprochenen Java Entwicklungsprogramme (wie z.B. der Compiler) sind selbst nichteinmal in Java geschrieben. P.S. Ich habe auf meinem 64bit Windows Rechner übrigens sowohl die 32 als auch die 64bit Java Version & ebenso die 32 und 64bit Eclipse Version laufen. Umgekehrt (d.h. 64bit auf einem 32bit Betriebssystem würde natürlich nicht gehen) --Sebastian.Dietrich ✉ 12:37, 13. Nov. 2012 (CET)

Ja, sorry, wenn ich es im Abschnitt Java (Programmiersprache) reingepackt habe. Ich ging von der Java-Laufzeitumgebung aus, wo die VM ja nun mal mit dazugehört, so wie die Räder zum Auto (sonst macht ein Auto kein Sinn). Und wie Sie ja eben schon selber meinten, ist Java VM nicht gleich Java VM: "Java selbst ist plattformunabhängig, die auf der Plattform installierte JVM muss aber natürlich schon die richtige sein." << Und das klingt eben widersprüchlich, wenn von Java (die JRE) gesprochen wird. Denn hier steht nur das Wort "Java".--77.186.27.238 18:27, 25. Feb. 2013 (CET)

Naja aber dann könntest ja auch sagen, dass Office 2010 nicht mehr auf Windows 7 läuft weilst auf einem 32 bit Windows 7 kein 64 bit Office zum Laufen bringst. In Plattformunabhängigkeit ist genau beschrieben was damit gemeint ist - z.B. gehört die JVM zur Plattform. Darum ists ja auch vom Artikel aus verlinkt --Sebastian.Dietrich ✉ 21:43, 25. Feb. 2013 (CET)

Performance

Es gibt genügend Quellen die behaupten, dass Java langsamer ist, aber auch dass Java schneller ist als C++. Ebenso gibt es genügend Quellen die behaupten, dass Java wegen der GC schneller ist als C++. Hier jetzt auf Grund eines einzigen Microbenchmarks zu behaupten, dass "die Garbage Collection einen signifikanten Laufzeitleistungs- und Speicheroverhead erzeugen kann" ist POV. Ausserdem steht in der Quelle diesbezüglich nix drinnen (nur das Java Performance schwer zu analysieren war und die Effekte der GC kompliziert waren und schwer zu tunen). --Sebastian.Dietrich ✉ 22:35, 18. Nov. 2012 (CET)

Zu dem kommentar zu dem revert-revert, der erste revert ohne diskussion geschah durch dich. 2. schaut man sich Quelle genauer an sagen die messergebnisse dort genau dies aus, GC hat negative Effekte auf die PErformance (siehe auch Tabelle Fig.8) von Seite 8: Garbage Collection Looking at profiles, Java shows a large GC component, but good code performance [...] Since GC has other negative performance side-effects, one ould estimate that without the GC anomaly, Java would be about roughly 30% faster than Scala. [...] Conclusion: We find that in regards to performance, C++ wins out by a large margin. 3. du sagst selsbt es gibt Quellen für beide Interpretationen. Deswegen müssen beide Seiten beleuchtet werden im Text, nur eine Quelle nennen ist POV. Falls keine besseren Argumente (oder eine passender Formulierung) vorgelegt werden, werde ich für eine auswogene Betrachtung die Quelle und den Text wieder reinnehmen. gruss Shaddim (Diskussion) 01:09, 19. Nov. 2012 (CET) PS: eine Gegenüberstellung zweier Positionen wie auch durch dich hier eingebracht

Hab kein Problem mit Darstellung beider Seiten. Mich stört nur, wenn die GC explizit als Grund für "Java ist manchmal doch nicht so schnell" dargestellt wird, weil das ist zumindest umstritten (die beiden Referenzen behaupten z.B. das Gegenteil) Wir können aber gerne den Absatz folgendermaßen ändern: --Sebastian.Dietrich ✉

Java ist insbesondere auf Grund der dynamischen Optimierungen der Virtual Machine eine der effizientesten Programmiersprachen und erreicht oder übertrifft in einigen Kontexten die Leistungsfähigkeit von C++- oder C#-Programmen[7][8], in anderen wiederum nicht[Referenz].

Hallo, sorry für die verspätete Reaktion ich war Verhindert. Für eine Kompromissformulierung bin ich offen, das "effiziensteste" ist mir aber noch zu ungerichtet und unbelegt, wie wäre es mit dieser weitergehnden Einordnung:

Java hat aufgrund der weitergehenden Optimierungsmöglichkeit zur Laufzeit in der Virtuellen Maschine das Potential eine bessere Laufzeitperformance als auf auf die Kompilezeit begrenzten Sprachen (C++, etc) zu erreichen. Dem entgegen steht der potentielle Overhead durch die Runtime Engine als auch die Komplexität dieser dynamischen Optimierungsaufgabe so das zwar in einigen Kontexten die Leistungsfähigkeit von C++- oder C#-Programmen[7][8] übertroffen wird, in eingien anderen wiederum nicht [Referenz]. Shaddim (Diskussion) 16:22, 24. Nov. 2012 (CET)

Finde ich inhaltlich super, aber etwas zu kompliziert und lange formuliert. Wie wärs mit:

Java hat aufgrund der Optimierungsmöglichkeit zur Laufzeit das Potential, eine bessere Performance als auf Kompilezeitoptimierungen begrenzte Sprachen (C++, etc) zu erreichen. Dem entgegen steht der Overhead durch die Runtime Engine, so das in einigen Kontexten die Leistungsfähigkeit von beispielsweise C++- Programmen[7][8] übertroffen wird, in anderen aber nicht erreicht wird [Referenz]. --Sebastian.Dietrich ✉ 19:06, 24. Nov. 2012 (CET)

Gute sprachliche Glättung. noch 2 kleinigkeiten:

Java hat aufgrund der Optimierungsmöglichkeit zur Laufzeit das Potential, eine bessere Performance als auf Kompilezeitoptimierungen begrenzte Sprachen (C++, etc) zu erreichen. Dem entgegen steht der Overhead durch die Runtime Engine, so das die Leistungsfähigkeit von beispielsweise C++- Programmen[7][8] in einigen Kontexten übertroffen, in anderen aber nicht erreicht wird [Hundt]. Shaddim (Diskussion) 22:17, 25. Nov. 2012 (CET)

Passt - rein damit --Sebastian.Dietrich ✉ 22:31, 25. Nov. 2012 (CET)

Die 2. Quelle ist überhaupt nur für Geld einsehbar, und die 1. ist meiner Meinung nach viel zu veraltet. Die reden da über Version 1.x, und wie der Artikel selber verkündet, ist die aktuelle Version 7.x. Was kann man aus so alten Quellen, also noch groß schließen? --141.53.222.227 18:09, 15. Feb. 2013 (CET)

Naja, wenn schon in der Version 1.x (stimmt nicht ganz, der Artikel ist von 2003) Java teils schneller war als C++, dann stimmt das für die jetzige 7.0er Version allemal. In Java tut sich mit jeder Version einiges in Punkto Performance - seit 2003 (Java 1.4) sind Java Programme vermutlich im Schnitt um 20 bis 50% schneller geworden. Ich hab z.B. bei einem extrem rechenlastigen Programm von mir alleine durch den Umstieg von Java 6 auf Java 7 10% bis 30% bessere Performance gemessen. --Sebastian.Dietrich ✉ 21:54, 25. Feb. 2013 (CET)

Schnelligkeit von C++ oder Java

Zur Schnelligkeit von Java gegenüber C++ ist zu sagen, dass Java nun mal ein Runtime-Modul hat; und dessen Zwischenschritt ist nun mal langsamer als der direkte Aufruf durch das compilierte C++-Programm. Den Unterschied dürfte man nur bei geschwindigkeits-sensiblen 3-D-Spielen merken. Letztere werden zumindest bei den speed-abhängigen Routinen sowieso direkt in Assembler programmiert. (Assembler kann meist besser speed-maessig angepasst werden als der noch so optimierte Comipler). Also: Java langsamer als C++ - JA, aber merkt das auch der Anwender ? : meistens NEIN. 31.19.64.47 16:50, 1. Apr. 2013 (CEST)

Das Java langsam wäre ist ein altes Vorurteil. Die Begründung "Runtime muss einfach langsam sein" ist keine Begründung, sondern ein weiteres Vorurteil. Tatsache ist: Java ist NICHT langsamer als C++ (in vielen Fällen ein wenig oder deutlich schneller, in vielen anderen Fällen ein wenig oder deutlich langsamer). Dazu gibt es jede Menge Artikel und Benchmarks, die das auch belegen - 2 davon im Artikel referenziert.

Das liegt z.B. daran, dass zur Laufzeit Informationen bekannt sind, die zur Compilezeit nicht bekannt sind. Darum kann zur Laufzeitsystem wesentlich mehr optimiert werden, als zur Compilezeit. Siehe z.B. Just-in-time-Kompilierung#Optimierungsmöglichkeiten, Dynamische Optimierung. Keinen Code auszuführen ist immer schneller als unnötigen Code auszuführen. --Sebastian.Dietrich ✉ 18:53, 1. Apr. 2013 (CEST)

Tut mir leid die Argumente deines Links sind nicht sehr überzeugend. All das kann man mit Assembler-Optimierung viel besser. Gerade die Schleifenoptimierung (Loop unrolling) (Einsparen des Rücksprungs durch Mehrfachhintereinandersetzung des Rumpf-Befehls) ist ein mehr 20 Jahre alter Hut - vgl. Amiga-Programmierung. Und das ist ja noch lachhaft. Interessant wird erst die Generierung von sin()-Funktion durch bloßes auslesen von Tabellen usw. Du magst ja recht haben aber kompilieren und gleichzeitig ausführen soll schneller sein als beides gleichzeitig ? Was machst Du wenn der Compiler eine Simulationsstufe vorschaltet und Deine Runtime-Routine simuliert und so die Code-Optimierung vornimmt ?

Nee das klingt so sehr nach SUN-Werbeneusprech. 37.5.134.8 14:22, 3. Apr. 2013 (CEST)

de.wikipedia.org/wiki/Programmoptimierung#Programmoptimierung_.28ausf.C3.BChrlich.29

de.wikipedia.org/wiki/Amortisierte_Laufzeitanalyse 37.5.134.8 14:28, 3. Apr. 2013 (CEST)

"Ziel ist es dabei, die Ausführungsgeschwindigkeit gegenüber einem Interpreter zu steigern." Das ist Deine Quelle. (http://de.wikipedia.org/wiki/Just-in-time-Kompilierung) 37.5.134.8 14:33, 3. Apr. 2013 (CEST)

Macht diese Argumentation nur in meinem Kopf keinen Sinn?

Es gibt keinen klaren "Sieger", je nachdem ob das Programm nun ahead-of- oder just-in-time kompiliert wird. Hauptsache, es wird kompiliert. Dazu gibt es gerade bei Java einen langen Diskurs und unzählige Benchmarks. -- Plankton314 (Diskussion) 14:41, 3. Apr. 2013 (CEST)

Wenig ausagekräftige Benchmarks :

www.itmagazine.ch/Artikel/42722/AMD-_Wenig_aussagekraeftige_Benchmark-Schaetzungen.html

http://allaboutsamsung.de/2013/01/ist-das-die-leistung-des-galaxy-s-iv-gt-i9500-taucht-bei-antutu-auf/

"So schön der Benchmark auch ist, er ist wenig aussagekräftig in Bezug auf das System. "

QUELLE: http://www.macnotes.de/2009/07/27/den-apfel-vermessen-benchmarks-mit-os-x/

Deinen Benchmark-Fetischismus glauben vielleicht Computer-Bild-Leser.

Außerdem wenn zwei Formel1-Wagen hintereiander fahren sind sie trotzdem nicht schneller als ein einzelner nur weil sie ab und zu eine Abkürzung über den Rübenacker machen - auch wenn nicht sie im Schlamm stecken bleiben.

Oder wie hast Du Deine 3D-Transformation code-optimiert ? Nichts läuft schneller als Assembler.

37.5.134.107 19:54, 3. Apr. 2013 (CEST)

Hier noch mal was von Heises c`t :

Kann ich Android-Handys nur in Java programmieren?

"Jein. Die Basis einer jeden Android-App ist Java. Der daraus entstehende Zwischencode wird auf dem Android-Handy in der Java-Laufzeitumgebung „Dalvik“ ausgeführt, was naturgemäß nicht sonderlich effizient ist. Besser geht es mit dem Native Development Kit (NDK). Damit lassen sich zum Beispiel zeitkritische Routinen in C programmieren – eingeschränkt auch in C++ – und über das Java Native Interface (JNI) von Java aus aufrufen."

Quelle : http://www.heise.de/ct/hotline/FAQ-Eigene-Android-Apps-1155583.html

Das dürfte ja wohl reichen um Lobbyisten-Neusprech zu widerlegen 37.5.134.107 20:30, 3. Apr. 2013 (CEST)

Ach ja, Benchmarks haben keine Aussagekraft... Ob es wohl möglich ist eine Aussage noch mehr aus dem Kontext zu reißen und falsch zu verstehen?

Und nichts läuft schneller als Assembler? Keine Ahnung, auf welcher Ebene ich auf diese Behauptung antworten soll. Vielleicht so: NICHTS LÄUFT SCHNELLER ALS MASCHINENCODE EIN FORMEL-1-WAGEN.

Naja, viel Spaß noch. -- Plankton314 (Diskussion) 20:43, 3. Apr. 2013 (CEST)

Lies bitte nochmal Just-in-time-Kompilierung#Optimierungsmöglichkeiten (und diesmal mehr als nur den ersten Absatz) und erklär mir, wie du mit Assembler oder C++ Closed World Annahmen treffen möchtest. Die einfache Annahme ist natürlich das ein Formel 1 Wagen schneller fährt als ein 2CV - wenn der Formel 1 Fahrer aber schon bei Beginn der Fahrt seinen Weg vorgeschrieben bekommen hat, der 2CV Fahrer aber dynamisch auf Verkehrsstaus und Umleitungen reagieren kann und bei Bedarf Abkürzer nehmen kann, dann ist der 2CV oft schneller am Ziel als der Formel 1 Fahrer. Rede mal mit wem, der sich mit HotSpot wirklich gut auskennt - dann werden dir die Ohren schlappern bei den vielen dynamischen Optimierungen die dort eingebaut sind. --Sebastian.Dietrich ✉ 22:34, 3. Apr. 2013 (CEST)

Da fragt man sich doch wieso es noch kein Java-Betriebssystem auf INTEL-Prozessoren das armselige Microsoft Windows aus gestochen hat (nicht mal das minoritäre LINUX) und mit einem nebulösen "Hot Spot" (?) (Lobbyisten Neusprech (?)) extrem schnelle 3D-Spiele gegenüber Assembler Programmierung ausstechen will. Ich denke Du hast keine Ahnung von Assenmbler-Programmierung !!!. Und diese lachhaften optimierungs Trick (siehe skalar-Prozessoren und RISC) kannte ich schon vor 20 Jahren. Nenn Doch mal seriöse und unabhängige Benchmarks mit 50 Megabyte großen Programmen - ohne Sun/Orakel Manipulationen. Und Benchmark-Tricks kenne ich schon von der c't im Zusammenhang mit Mikroprozessoren. (und das schon 1995 im zusammenhang mit Pipelines und Skalar-Prozessoren - Ein 1995 alter Compiler-Hut) Übrigens Autobahnstaus auf der Landstraße zu umgehen bringt meisten nichts, die sind nämlich meistens genauso verstopft. Also erzähl mir nichts. Ansonsten habe ich keine Lust mit sophistischen Lobbyisten auseinanderzusetzen. PUNKT.31.19.64.94 22:43, 4. Apr. 2013 (CEST)

Offensichtlich hast du keine Ahnung von Softwareentwicklung - ich schon. Habe Assembler, C, C++ etc jahrelang entwickelt - ich weiss wovon ich spreche. Du hingegen scheinst weder zu wissen was HotSpot ist, noch wie ein Betriebssystem funktioniert. Du schiesst wild um dich und kommst uns mit Ad personam Argumenten und Null-Argumenten wie "geht nicht", "kann gar nicht sein", "glaub ich nicht" "warum hat dann noch niemand". Lies dich mal in die Thematik ein, dann wirst du folgendes erkennen: Ja es gibt 3D-Spiele in Java - ja sie sind teils schneller als ihre C/C++ Varianten - nein 3D Spiele werden meist nicht in Assembler geschrieben - nein es liegt nicht an der Performance von Java dass es in Java nur wenige 3D Spiele gibt - nein es gibt keinen einzigen Benchmark für 50MB große Programme der zeigt dass Java dort langsamer wäre - ja beinahe alle großen Programme werden heutzutage in Java geschrieben - nein nicht wegen der Performance sondern wegen der Produktivität - ja mit Java werden einige Geschwindigkeitsrekorde gebrochen.

Jeden weiteren WP:PA werde ich ab sofort löschen. Diskussion ist hiermit beendet. --Sebastian.Dietrich ✉ 09:22, 5. Apr. 2013 (CEST)

JavaScript

Sebastian.Dietrich hat meine Änderung bezüglich Klassen in JavaScript wieder gelöscht. Daher eine kurze Erläuterung. Wenn man genau nach den Worten der ECMA Script Spezifikation geht, gibt es keine Klassen in JavaScript. Faktisch kann ein Programmierer, der mit Java/C++/PHP o. ä. Sprachen vertraut ist, die Sprachkonstrukte in JavaScript so verwenden, wie er es aus diesen Sprachen von der Arbeit mit Klassen gewohnt ist. In JavaScript kann man: Klassen mit Attributen und Methoden definieren (mittels Konstruktordefinition), Konstruktoren definieren, instanzunabhängige Attribute und Methoden definieren (mittels Klassenname.Eigenschaft = ...), Eigenschaften einer Klasse an beliebiger Stelle im Code ändern (u. a. mittels der prototype Eigenschaft), Vererbung anlegen. Ob es in JavaScript Klassen gibt, ist also eher eine philosphische Frage. --Waao (Diskussion) 14:15, 14. Apr. 2013 (CEST)

Bitte kläre die Frage unter Diskussion:JavaScript. --Sebastian.Dietrich ✉ 22:46, 14. Apr. 2013 (CEST)

Einzelnachweis 4

Einzelnachweis 4 steht hinter "Auch in Autos, HiFi-Anlagen und anderen elektronischen Geräten wird Java verwendet.", doch der Nachweistext besagt nur "Installationsbildschirm unter Microsoft Windows" - das ist doch nicht zusammengehörig? --77.184.184.158 13:17, 2. Jun. 2013 (CEST)

Hab den Einzelnachweis 4 gelöscht - der war tatsächlich sinnlos. Dass Java in Autos, HiFi-Anlagen etc. verwendet wird ist natürlich eine Tatsache (kaum ein Blue-Ray Player hat _kein_ Java)... --Sebastian.Dietrich ✉ 20:13, 2. Jun. 2013 (CEST)

Sprachsyntax und Metaprogrammierung

Aus dem Artikel: "Der im Vergleich zu C++ stark reduzierte Sprachumfang ist gleichzeitig auch häufiger Bestandteil von Kritik an Java, da dies u.a. Metaprogrammierung unmöglich macht."

Umgekehrt wird C++ wegen seiner viel zu verworrenen Syntax und seinen viel zu vielfältigen Sprachelementen kritisiert. Eine solche Kritik an Java wäre mir neu.

Und, dass Metaprogrammierung in Java unmöglich sei, das ist ja wohl eher ein Aprilscherz. Ich werde den Nebensatz jetzt mal ausnahmsweise selbst entfernen, was nicht heißt, dass wir bei Bedarf nicht noch einmal darüber reden können. --77.47.67.51 20:16, 25. Sep. 2013 (CEST)

Ich hab jetzt den ganzen Satz rausgenommen. Wenns wo eine belegbare Kritik deswegen gibt kann er gerne rein - belegbare Kritik am überbordenen Sprachumfang von C++ gibt es auf jeden Fall. D.h. wenn dann wird es sowohl kritisiert als auch gelobt. --Sebastian.Dietrich ✉ 20:31, 25. Sep. 2013 (CEST)

Danke dir :-) Das würde ich dann aber eher im Abschnitt zu den Unterschieden zu C++ einbringen. Denn gerade die relativ streng standardisierte Syntax ist Konzept der Sprache. Bemerkenswert finde ich es jedoch auch.... --77.47.67.51 22:36, 25. Sep. 2013 (CEST)

Lieber doch kein Java installieren?

Ich sehe noch keinen Abschnitt im Artikel bzgl. der immer wiederkehrenden Expertenratschläge, lieber kein Java zu installieren, da dadurch häufig Schadprogramme wie Trojaner eingeschleust werden können. Beispiele für Berichte dazu:

• http://www.spiegel.de/netzwelt/web/neue-java-sicherheitsluecke-entdeckt-a-853531.html
• https://www.bsi-fuer-buerger.de/ContentBSIFB/WissenswertesHilfreiches/Service/Aktuell/Meldungen/Sicherheitsluecke-in-Java-Version_29082012.html

Bitte an entsprechender Stelle ergänzen. --Kebap (Diskussion) 00:02, 18. Sep. 2013 (CEST)

Thema gefunden im Artikel Java_(Technik)#Kritik. --Kebap (Diskussion) 00:04, 18. Sep. 2013 (CEST)

Genau das habe ich eben im Artikel gesucht (und ebenfalls vermißt), nachdem ich im zweiten Satz dieses Textes darauf gestoßen bin: pcwelt.de: Die unglaublichsten Sicherheitslücken der Internet-Geschichte --Zopp (Diskussion) 15:18, 10. Dez. 2013 (CET)

Ich würde es selbst hinzufügen, habe aber keine Ahnung wo. --Kebap (Diskussion) 13:57, 8. Jan. 2014 (CET)

Die Sicherheitswarnung bezieht sich auf die Java-Laufzeitumgebung und ist deshalb im Artikel Java (Technik) erwähnt. In diesem Artikel hier geht es aber um die Programmiersprache als solche. --j ?! 15:15, 8. Jan. 2014 (CET)

Naja, das scheint mir etwas haarspalterisch. Wie benutzt man die Programmiersprache ohne Laufzeitumgebung? Für den Laien macht es Sinn, bei Wikipedia unter Java nachzugucken. Java (Technik) wird er vermutlich nicht finden. Während auf der Technik-Seite also sicher ausführliche Informationen gesammelt werden sollten, kann ein kurzer Hinweis zum Thema auf dieser Seite hier (ggf. inkl. Verweis nach dort) doch nicht schaden? Es komplett weg zu lassen, finde ich schon etwas bedenklich.

Um die Sache noch weiter zu verkomplizieren, gibt es tatsächlich noch den Artikel Java-Laufzeitumgebung, der aber nicht identisch ist mit Java (Technik), die inzwischen auch Java-Technologie heißt. Java selbst verweist auf all diese Unterseiten, und Java-Technologie steht als erster Eintrag dort. Vielleicht ist es also doch auffindbar, wenn hier auch zwei Beispiele geäußert wurden, in denen es nicht gefunden wurde. Uff. --Kebap (Diskussion) 15:53, 8. Jan. 2014 (CET)

Ich denke nicht, dass man bei einer Programmiersprache die Sicherheitsfehler der Laufzeitumgebung erwähnen sollte. Wenn dem so wäre, dann müssten bei C/C++ die Sicherheitsfehler bzw. das Fehlen von Sicherheitsvorkehrungen von Windows, Unix etc. erwähnt werden, bei JavaScript die der Webbrowser etc. --Sebastian.Dietrich ✉ 21:10, 8. Jan. 2014 (CET)

Native Compiler

Beispiele für native Java Compiler sind Excelsior JET sowie GNU Compiler for Java (GCJ) wie MinGW, Cygwin oder JavaNativeCompiler (JNC). . im Artikel für den Cygwin findet sich kein Hinweis darauf, dass dort ein Compiler drin steckt. Und bei MiniGW findet sich die Aussage Die Programmiersprache Java wird seit der MinGW-Version 4.5.0 auf Grund von ungelösten Problemen nicht mehr unterstützt. - sollte da nicht ein wenig aktualisiert werden? Chiron McAnndra (Diskussion) 00:59, 19. Mai 2012 (CEST)

Java beeinflußte C#

Java hat C# beeinflußt? Steht so in der Infobox. C# ist 6 Jahre später erschienen.--84.190.158.38 11:45, 3. Dez. 2014 (CET)

Ja, und? Umgekehrt wäre es verwunderlicher.

C beeinflusste C++, C++ beeinflusste Java, C++ und Java beeinflussten C#. Alle bauten auf Konzepten der Vorgänger auf; übernahmen, was sie brauchen konnten, ließen weg, was sie störte, und fügten Neues hinzu. So what?

VG --PerfektesChaos 12:44, 3. Dez. 2014 (CET)

Da Java ja aktiv weiterentwickelt wird, können es durchaus auch C#-Einflüsse in Java schaffen (z.B. bei den Lambda-Ausdrücken in Java 8 und ihrer Syntax), aber insgesamt hat Java C# natürlich wesentlich stärker beeinflusst als andersherum. --YMS (Diskussion) 16:54, 3. Dez. 2014 (CET)

Einfügung aus Java (Spezifikationen)

Diesen Abschnitt würde ich lieber unter Java (Technik) sehen wollen. Wenn man so will, sind Applets oder normal ausführbare Programme und Apps eine Art von spezieller „Laufzeitumgebung“. Die Programmiersprache als solche weiß nichts davon, dass es ein Applet ist; es wird nur zufällig irgendeine Interface-Bedingung erfüllt.

Nebenbei bräuchte es dort eigentlich keine Unterabschnitte; Sternchen-Aufzählung würde reichen.

Liebe Grüße --14:53, 11. Jul. 2012 (CEST)

Java 9

Habt Ihr schon gesehen: Java 9 kommt im Herbst 2016 (Quelle: Informatik Aktuell). Mag das vielleicht schon jemand einarbeiten? Ich würde es auch machen, bin aber nicht sicher, wieweit da auf Details eingegangen werden soll. --95.116.209.137 16:54, 8. Mai 2015 (CEST).

Wenn dann in Java-Technologie. Ich hab gerade ein Training zu Java8 vorbereitet & auch einige Slides zu Java9 vorbereitet. Ein paar Dinge zu Java9 sind inzwischen schon fix (mMn für Entwickler nicht wirklich was großartiges dabei, aber ein paar wichtige Dinge im Hintergrund), d.h. macht aus meiner Sicht Sinn das einzuarbeiten (ist keine Glaskugelei mehr, da im aktuellen Java9 Build enthalten), aber Feature-Complete ist erst 10.12.2015 --Sebastian.Dietrich ✉ 23:56, 8. Mai 2015 (CEST)

Es sollte nichts in den Artikel, was noch nicht per "Feature-Freeze" o.ä. sicher in Java9 sein wird.

So mancher Hersteller hat schon so manches 'fest eingebaut' (in ein Vorab-/Zwischen-Build), und im Endprodukt war's dann doch nicht drin...

Offizielles Feature-Freeze (Oracle: "Das, das und das IST drin."), dann Artikel.

--arilou (Diskussion) 14:36, 12. Mai 2015 (CEST)

Sonderfall Google Android

Im Artikel wird JavaME und Android gleichwertig erwähnt, was so aber nicht ganz richtig ist; JavaME ist eine "richtige" Java-Implementierung, also Programmiersprache + Bytecode + VM, während auf Android irgendetwas läuft was von Google je nach Situation als Java oder als nicht-Java bezeichnet wird. Für Android schreibt man Java-Sourcecode (allerdings ohne vollständige Standard-Bibliothek), der auch zu Java-Bytecode kompiliert wird, danach aber zu Googles eigenem Dex Bytecode konvertiert wird, der wiederum in einer speziellen Google-VM läuft (Dalvik) oder kompiliert wird (ART). Google zahlt deswegen keine Lizenzen an Oracle "Weil es ja kein richtiges Java ist", begründet Dalvik damit, dass der Google-Bytecode besser wäre (Was fraglich ist, da Dalvik jetzt eingestampft wird), den Entwicklern gegenüber wird aber von Java gesprochen. Oracle klagt ja deswegen auch gegen Google. Oder kurz gesagt: Oracle meint, dass Google nur ein paar technische Details geändert hat um keine Lizenzgebühren zu zahlen und soll entweder zahlen oder es nicht Java nennen, Google meint, dass sie es aus technischen Gründen anders gemacht haben und es trotzdem Java nennen dürfen, ohne zu zahlen. Insgesamt ist das ziemlich kontrovers und ich weiß nicht, wie man das neutral im Artikel unterbringen kann. Vorschläge? RedNifre (Diskussion) 12:37, 10. Mai 2015 (CEST)

Naja - hier ist ja der Artikel zur Programmiersprache. Und die hat ja mal primär nix mit der Laufzeitumgebung oder dem Bytecode in den sie compiliert wird zu tun. Die Kontroverse wäre mMn richtigerweise in Dalvik Virtual Machine aufgehoben (dort gibts bereits dazu einen Absatz). Es geht ja soweit ich es verstanden habe nicht darum, dass man bei Android in Java programmiert, sondern dass Oracle behauptet, dass Google bei Dalvik die JVM "gestohlen" und leicht verändert hätten. --Sebastian.Dietrich ✉ 23:38, 10. Mai 2015 (CEST)

Wenn jemand ein 'Java' anbietet/verwendet, das nicht den Standards entspricht (in der Sprache/den verfügbaren Standard-Klassenlibs), dann sollte das imho zumindest (auch hier) kurz erwähnt werden:

Das für die Android-App-Entwicklung seitens Google angebotene „Java“ entspricht weitgehend der hier beschriebenen Sprache, weicht aber in einigen Bereichen davon ab und bietet auch nicht alle oder abweichende (Standard-)Klassenbibliotheken.

1 Satz, das genügt ja schon. --arilou (Diskussion) 14:45, 12. Mai 2015 (CEST)

Hab kein Problem mit dem einen Satz - aber die Sprache ist meines Wissens nach 1:1 dieselbe (halt eine alte Version) & nur die Klassenbibliothek (deutlich) anders. Wenn die Sprache nicht 1:1 dasselbe ist, dann sollte hier mMn sogar deutlich mehr als nur ein Satz kommen. --Sebastian.Dietrich ✉ 22:21, 12. Mai 2015 (CEST)

Hab' den Satz jetzt unter 'Apps' eingefügt (leicht abgeändert).

"Die Sprache" umfasst imo die Klassenbibliotheks-APIs mit - ohne hat Java nicht wirklich einen Sinn.
Für die Klassenbiblitheks-APIs hat Sun einige "Pakete" definiert: EE, SE, ME. Google hält sich nicht (100%) an selbige, und nennt es trotzdem 'Java'.

--arilou (Diskussion) 14:08, 13. Mai 2015 (CEST)

Passt. @Sprache ists denke ich anders. Die Java Language Spec beschreibt nur die Sprache und nicht die Klassenbibliothek - so wie dieser Artikel nur die Sprache und nicht die Klassenbibliothek beschreibt (bzw. sollte). Alles zusammen (d.h. Sprache, Klassenbibliothek, Runtime, Tools) wird in Java-Technologie beschrieben und umfasst das, was man normalerweise unter "Java" versteht. D.h. ich hab den Satz jetzt (deutlich) auf "Appss für das Android Betriebssystem von Google werden in der hier beschriebenen Sprache Java programmiert, basieren aber auf einer abweichenden Klassenbibliothek." abgewandelt. --Sebastian.Dietrich ✉ 20:13, 13. Mai 2015 (CEST)

Lizenz nicht GNU?

Hallo, eventuell Verstehe ich was Falsch. Die Box beschreibt das Java von Oracle mit der GNU Public License vertrieben wird. Die kann ich aber nicht herunter laden. Mir ist heute aufgefallen das nur mit einer ORacle Binary License die Software herunter zu laden ist. Desweiteren hört die Seite openJDK mit version 7 auf. openJDK war die Open Source Linie von Oracle. Und ich erinnere mich Dunkel das dies früher einmal vereinheitlicht wurde. Was es auch imemr ist, irgendwas ist hier nicht verständlich. Kann jemand das mal gegen checken? --Legine (Diskussion) 15:01 26.06.2015

In der Tat, das, was man früher bei SUN und heute bei Oracle als "Java" (Binaries) herunterladen kann, ist nicht frei. Diese Binaries können richtig teuer werden, wenn man sie beispielsweise auf einem Server oder in Maschinen installiert, da nur die Nutzung auf einem "persönlichen Rechner" kostenlos ist (siehe Lizenzbedingungen in den Downloads). Ich denke, dass dieser Sachverhalt sowohl im englischen als auch deutschen Beitrag zu Java fehlt und aufgenommen werden sollte. --Stefan Weil (Diskussion) 15:44, 12. Nov. 2015 (CET)

Informationen zu bestimmten JVMs und ähnlichem gehören aber nicht in hiesigen Sprache-Artikel, sondern in den Artikel Java-Laufzeitumgebung. --arilou (Diskussion) 08:55, 10. Mär. 2016 (CET)

Abschnitt "Java Plug-Ins" entfernen

Der Abschnitt ist nicht nur unleserlich sowie unverständlich, sondern zum Großteil schlicht falsch.

Plugins laufen nicht in der Konsole, sie werden nicht in einen "Ordner innerhalb des Servers" verschoben und die Konsole ist ebenso wenig für deren Einlesen verantwortlich. Das Beispiel ist sehr speziell auf Minecraft-Server und die Bukkit-API bezogen und ist in diesem Artikel meiner Ansicht nach fehl am Platz. Zudem verstößt die Namensgebung der Methode gegen alle (mir bekannten) Coding conventions.

Die Person, die diesen Absatz geschrieben hat, scheint gar nicht zu wissen, wovon sie spricht. --Postolus (Diskussion) 03:41, 10. Mär. 2016 (CET)

Habs entfernt. --Gestrandete 55-cm-Geschirrspülmaschine (Diskussion) 07:22, 10. Mär. 2016 (CET)

Checked Exceptions

Es fehlt der Hinweis, dass Java die einzige relevante Programmiersprache ist, die das Konzept der checked Exceptions unterstützt. Zahlreiche Diskussionen in anderen Sprachen aber auch in einschlägiger Fachliteratur (vgl. "Clean Code", Robert. C. Martin p:106) erklären das Konzept jedoch als gescheitert. Ich würde es gern in den Artikel einarbeiten bin mir nur unschlüssig, in welchen Abschnitt. Vergleich mit anderen Sprachen, oder als eigenes Feature? --Ch0peng (Diskussion) 23:40, 14. Mär. 2017 (CET)

Das Thema wird unter Ausnahmebehandlung#Checked Exceptions bereits behandelt. Daher denke ich, dass ein Hinweis daraufhin genügen würde - nur sehe ich jetzt dass das bereits der Fall ist. Daher würde ich im Artikel nichts mehr machen. --Gr1 (Diskussion) 08:05, 16. Mär. 2017 (CET)

JavaScript + "klassenlos"

"JavaScript ist eine dynamisch typisierte, objektbasierte, aber klassenlose Skriptsprache"... Naja, seit ES 2015 nicht mehr. Sollte man das in den Artikel einfügen? jens1o (Diskussion) 16:18, 8. Okt. 2017 (CEST)

Ersetz' doch das "aber klassenlose" durch "bis 2015 klassenlose" - nur ein kleiner Edit... --arilou (Diskussion) 15:32, 19. Okt. 2017 (CEST)