Diskussion:Java (Programmiersprache)/Archiv/1

message: Hab mich mal kundig gemacht:
*Die Grösse der ints ist wirklich kein Problem, aber die Byteorder. Angeblich, denn das kann ich irgendiwe nicht nachvollziehe (nur x86 Kisten). Die Byteorder ist zumindest in der VM Spec nicht festgelegt.
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html#31446
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#19511
*Das mit der "reinen" Objektorientierung hat sich denke ich eh schon erledigt, es heisst ja nur noch Objektorientierung. Und das passt auf jeden Fall.
*Die Compiler anderer Sprachen müssen sich nicht an die Java Spec, sondern an die VM Spec halten.
*Wegen der Applets: Ich denke, dass Applets im Mainstream Markt nur noch für Homebanking verwendet werden. Und eventuell als Mail Editor (Lotus Notes). Für die meisten anderen Anwendungen wird meist Flash verwendet (Spiele,...) Sonst sind Applets eher Lösungen, die komplementär sind zu einer anderen Lösung (Wie der Maileditor) oder als ASP. Das soll nicht heissen, dass man mit Applets nicht eine gute Lösung bauen kann (sitze im Moment grade selbst an einer). Aber ich denke Applets sind stark überbewertet, sprich sie bekommen einen grösseren Anteil an Dokumentation als sie einen Marktanteil haben.
*Einen kurzen Abriss zur Geschichte von JAVA fände ich noch gut. Mal sehen, ob ich da was finde.
*Was hälst Du davon, die Arbeit an dem Artikel ein wenig aufzuteilen? Damit wir nicht die Arbeit unnötig doppelt machen? Ich versuch als nächstes was über die Geschichte von Java rauszufinden. Vielleicht schreibe ich auch noch was über die Entwicklung (also nach 1.0).
OliD 13:16, 20. Mai 2003 (CEST)
replies: text: Ok,ok,Du hast ja recht. Aber ich hätte wetten können, dass da was war...
*Die Compiler anderer Sprachen müssen sich nicht an die Java Spec, sondern an die VM Spec halten ist korrekt ;-)
*Wegen den Applets: sobald wir "nur das Gefühl haben" oder "der Meinung sind", sollten wir das meiner Meinung nach im Wikipedia-Artikel vermeiden
*Eine Geschichte von Java ist eine gute Idee. Guido Krüger hat in seinem Werk auf www.javabuch.de einen guten geschichtlichen Abriss über Java verfasst, ist aber leider Copyright! Vielleicht können wir ihn überreden, bei Wikipedia mitzumachen ;-)
*Dein Vorschlag, die Arbeit aufzuteilen finde ich ebenfalls fair
jonelo 16:47, 20. Mai 2003 (CEST)
thread_title:  kundig gemacht 

message: Ich denke, es geht ganz gut voran. Hier noch meine Punkte:
*Wir sollten "Programmiersprache Java" nach "Java (Programmiersprache) moven, und damit den Strukturen der anderen Seiten folgen (natürlich mit Redirect von "Programmiersprache Java")
*Wenn die Java Geschichte zu viel wird, was hältst Du von einem neuen Artikel namens "Java (Geschichte)"
**Meine Stimme könnt ihr schonmal zählen... die Geschichte ist irgendwie abschreckend und wirkt, verglichen mit den Artikeln anderer Programmiersprachen, irgendwie auch fehl am Platz. Im Endeffekt interessiert jemanden, der irgendwo das Schlagwort "Java" gehört hat und jetzt endlich wissen will, was es damit auf sich hat, die Entstehungsgeschichte wohl nicht (von einer kurzen zeitlichen Einordnung mal abgesehen). Sollte ich einfach mal einen Versuch der Aufteilung und einer neuen Einleitung machen? --Asarion 22:18, 26. Jul 2004 (CEST)
thread_title:  moven 

message: Der Artikel hat mittlerweile viel zu viele Links. Siehe auch die Weblinks Dokumentation. Es gilt die Richtline "Nicht mehr als fünf externe Links zu einem Thema! Wikipedia ist keine Linksammlung, sondern eine Enzyklopädie". Kann sich mal jemand, der bereits einiges an dem Artikel gearbeitet hat, darum kümmern dass die Linkzahl deutlich runter geht? Sonst werde ich das wohl in einigen Tagen mal übernehmen. Möchte da aber ungern einfach reinpfuschen. Patrice 01:35, 4. Mär 2004 (CET)
replies: text: Okay, danke für die Arbeit die mit den Entwicklungsumgebungen bereits erledfigt wurde. Habe die Links auf Bücher in ein separates Kapitel ausgelagert inklusive besseren Autor, ISBN, etc. Angaben. Die eigentlichen Links habe ich mal radikal gekürzt. Patrice 12:54, 6. Mär 2004 (CET)
thread_title:  Links 

message: Vor kurzem sind hier im Artikel einige Schlüsselworte aus anderen Programmiersprachen reingerutscht, die nicht aus Java sind.
Als TestCase habe ich folgenden Quelltexte verwendet, weil die Java Language Specification bisher noch nicht in einer für Java 5.0 aktualisierten Version vorliegt:
    public class Keywords {
        public static void main(final String... args) {
            int byvalue;
            int cast;
            int const;
            int future;
            int generic;
            int goto;
            int inner;
            int operator;
            int outer;
            int rest;
            int var;
        }
    }
Meine Java-Version:
> javac -version
javac 1.5.0-rc
Der Compiler von SUN (J2SE 5.0 RC) beschwert sich lediglich über const und goto (Optionen: -source 1.5 -Xlint:all).
Einige der genannten Schlüsselwörter sollten in uralten Versionen vor der Einführung der inneren Klassen (1.0) eventuell mal verwendet werden, sind aber schon lange nicht mehr reserviert.
Weil es sich bei byvalue, cast, future, generic, inner, operator, outer, rest und var also nachweislich nicht um reservierte Wörter handelt und sie, ganz im Gegensatz zu const, goto, den echten Schlüsselwörtern, Typbezeichnungen und Literalen, durchaus als Symbole erlaubt, sind wieder aus der Liste gelöscht.
--ChristianHujer 13:00, 11. Sep 2004 (CEST)
replies: text: Noch eine Anmerkung: Eine Suche auf java.sun.com nach den vermeintlich reservierten Wörtern liefert 0 Seiten... --ChristianHujer 13:11, 11. Sep 2004 (CEST)
thread_title:  Liste der reservierten Wörter 

message: Was soll eigentlich mit Links auf fehlerhafte Tutorials und Einführungen passieren? Ich habe 15 Sekunden gebraucht, um den ersten Fehler in http://www.highscore.de/ zu finden, außerdem enthält das Tutorial einen Haufen Müll:
* Zahllose Verstöße gegen die SUN Java Code Conventions
* Konstruktion von String-Objekten: java.lang.String Text = new java.lang.String("Hallo, Welt!");
* Logische Fehler (z.B. Ständige Neuinitialisierung eines Arrays mit gleichen Werten in einer paint()-Methode)
* Verwirrende Beschreibung der Zugriffsmodifzierer (package wird falsch als Modifizierer genannt)
und vieles mehr.
* Falschaussagen wie "Interfaces sind ein merkwürdiges Gebilde, das es in anderen objektorientierten Programmiersprachen nicht in dieser Form gibt." (C#, IDL...)
* Schlechter Stil in Code-Beispielen, z.B. fehlender finally-Block für das Freigeben der Resourcen im I/O-Bereich
* Bereits der Java-Code für Datenbankzugriffe ist DBMS-abhängig
* Die Liste der Operatoren ist unvollständig, es fehlt die Short-Circuit-Eigenschaft von && und ||, es fehlen &, | und instanceof sowie zahlreiche der Zuweisungsoperatoren
Ich schlage daher vor, den Link erstmal zu löschen. Man kann ihn ja in ein paar Monaten wieder aufnehmen, wenn diese Java-Einführung besser geworden ist, aber derzeit kann man sie eigentlich nicht guten Gewissens empfehlen, es besteht die Gefahr, dass Einsteiger die ganzen Fehler und den ganzen schlechten Programmierstil, der dort zu finden ist, übernehmen.
Gibt's noch andere Meinungen dazu? Wenn nein, lösche ich denk Link mit der Aufforderung an den Autor, den Link wieder einzubauen, wenn die ganzen Fehler in dieser Java-Einführung behoben sind. --ChristianHujer 12:46, 16. Sep 2004 (CEST)
replies: text: hau wech - solche tutorials gibt's leider wie sand am meer, aber drauf verlinken müssen wir wirklich nicht. -- ∂ 13:47, 16. Sep 2004 (CEST)

text: Ich bin der Meinung, dass nur sehr wenige Tutorials aufgeführt werden sollten; und diese sollten auch qulitativ hochwertig sein. Ansonsten kann ich Deine Kritikpunkte nicht durchgehend verstehen. Auch im Sun-Tutorial sind die Beispiele nicht alle mit einem guten Code-Stil (z.B. finally-Blöcke). --Herr Schroeder 10:22, 20. Sep 2004 (CEST)
thread_title:  Links auf fehlerhafte Tutorials und Einführungen? 

message: Mich nervt das ständige Gewinke von Duke, wenn ich versuche das richtige Thema im Inhaltsverzeichnis zu finden. Kann das nicht jemand durch ein Standbild ersetzen? --Supaari sag'smir! 21:14, 5. Okt 2004 (CEST)
replies: text: me too! -- D. Düsentrieb ⇌ 01:24, 6. Okt 2004 (CEST)
replies: text: Ich glaube der nervt nicht nur, sondern ist auch (wie das Java-Logo) nicht GFDL-kompatibel. Wer kann, darf mich ruhig vom Gegnteil überzeugen. Wenn das nicht klappt, dann beide Bilder rausnehmen und Löschanträge dafür stellen. -- Dishayloo [ +] 02:06, 6. Okt 2004 (CEST)
replies: text: Dishayloo hat Recht, das ist nicht nur eine Verletzung der GFDL, sondern auch eine Verletzung von Sun Trademarks. "This logo [das Java SMI Logo] is reserved for use by Sun Microsystems and approved partners, vendors and press publications only. This graphic should be used if there is no other reference to Sun Microsystems on the project. Once approved, you will be sent a One-Time Use Agreement to sign." - selbst wenn uns Sun eine Erlaubnis erteilen sollte - das Java-Logo kann nicht unter die GFDL fallen. Jonelo 18:55, 6. Okt 2004 (CEST)
thread_title:  Duke nervt! 

message: Bilder werden hier schwierig, die in dem englischen Artikel basieren alle auf 'Fair Use'. Was meint ihr? -- Dishayloo [ +] 21:20, 12. Sep 2004 (CEST)
replies: text: als DAU muss ich zugeben, dass ich die Teile ab "Modulare Ausführung" nur überflogen habe - was mir aber wirklich fehlt, ist der Anwenderbezug - die Geschichte bricht 1995 ab, deshalb tauchen wahrscheinlich auch fragen wie/wann/wo Java eingesetzt wird und welche Vor-/Nachteile dies für die Betroffenen Anwender hat, kaum auf. Die Einleitung ist mE überarbeitungsbedürftig - da sollte das wichtigste hinein und das finde ehrlich gesagt weder, dass der name ursprünglich "Oak" war, noch in welchem zeitraum genau entwickelt wurde, sondern eher sowas wie spezifika der sprache oder halt ihr (doch recht weit verbreitetes...) anwendungsgebiet. -- southpark 22:16, 12. Sep 2004 (CEST)
replies: text: OK, ich habe einige Abschnitte, vor allen Dingen die Versionen, zur Geschichte kopiert. Damit reißt diese schonmal nicht mehr 1995 ab. Die Einleitung muss ich noch einmal gut durchdenken. -- Dishayloo [ +] 08:42, 14. Sep 2004 (CEST)
thread_title:  Diskussion aus dem [[Wikipedia:Review|Review]] 

message: Im Abschnitt C++ wurde gerade wurde ein kurzer Abschnitt hinzugefügt, den ich nur sehr eingeschränkt für korrekt halte. Deshalb hab' ich ihn erstmal entfernt, um ihn hier zu Diskussion zu stellen:
:Das im Vergleich zu C++ fehlende Konzept der Destruktoren bringt es mit sich, dass der Programmierer jegliche verwendeten externen Ressourcen wie zum Beispiel geöffnete Datei selbst verwalten muß. Es ist in Java nicht möglich, automatisches Ressourcen-Management zu implementeieren. Stattdessen müssen alle allocierten Ressourcen explizit "von Hand" wieder freigegeben werden (z.B. durch den Aufruf von Close()-Methoden). Dies verkompliziert das Exception-Handling, und macht es manches Mal nicht leicht, Resource-Leaking gesichert zu vermeiden.
Es ist zwar richtig, dass es in Java keine Destruktoren gibt - aber es gibt die finalize()-Methode, die zur Freigabe von Resourcen verwendet werden kann. Der einzige Unterschied besteht darin, dass finalize() das Objekt "am leben erhalten" kann, indem sie das Objekt wieder anderen zugänglich macht.
Das Problem mit der Resourcenverwaltung entsteht dadurch, dass der Programmierer keine Kontrolle darüber hat, wann die finalize()-Methode aufgerufen wird - das ist Aufgabe der Garbage-Collection. Das Problem besteht also eher im fehlen eines "delete"-Statements. Ausserdem ist es doch so dass man in C++ alle Objekte händisch freigeben muss - ein sehr viel grösseres Problem, als das für Dateien etc. zu tun. So sollte das jedenfalls nicht stehen bleiben. -- D. Düsentrieb ⇌ 15:44, 10. Okt 2004 (CEST)
replies: text: In der Theorie hast Du recht (darum sollte der Absatz rausbleiben), in der Praxis siehts aber etwas anders aus: Offene Systemressourcen sollten möglichst schnell geschlossen werden; der Garbagecollector wird irgendwann mal aktiv, eventuell auch gar nicht. Man sollte daher in der Tat diverse close()-Methoden explizit rufen, bevor man ein Objekt vergisst, und sich nicht auf die finalize()-methode verlassen. Im übrigen ist es ziemlich egal, ob ich eine "objekt.close()" Methode rufe, wenn ich ein Objekt nicht mehr brauche, oder ob ich "delete objekt" schreibe. - Uli 15:56, 10. Okt 2004 (CEST)

text: Ah, jetzt verstehe ich: in diesem Fall ist das eigentliche Probelm das fehlen von automatischen Objekten in Java: der ofstream im Beispiel liegt ja auf dem Stack und geht desshalb "out of scope" wenn die Funktion zurückkehrt. Das geht in Java deshalb nicht, weil man ja nur eine Referenz auf den entsprechenden Stream hat und diese beispielsweise auch als Wert zurückgeben könnte. Ein explizites delete auf Objekte habe ich mir in Java schon oft gewünscht, mit der Semantik dass spätere Zugriffe auf eine gelöschtes Objekt einfach eine RuntimeException werfen. Aber leider gibt's das nicht. Es ist aber ohnehin sinnvoll, resourcen immer explizit freizugeben, auch wegen der Lesbarkeit. Dass das dazu führt, dass man ständig mit finally-statements arbeiten muss, ist natürlich ärgerlich. Wenn mir 'ne gute Lösung für dieses Dilemma einfällt, werde ich reich und berühmt;) 
Ich habe etwas zu dieser Problematik unter Finalisierung verfasst. Kommentare willkommen. Poldi 18:15, 10. Okt 2004 (CEST)

text: Ich finde schon, das in diesem Artikel hier kritisch auf das fehlen von Destruktoren, expliziten deletes und automatischen Objekten hingewiesen werden kann. Eine detaillierte Diskussion dieser Problematik ist aber unter Garbage Collection besser Aufgehoben (danke Poldi!), das Problem beschränkt sich ja nicht auf Java. Auch sollte klar werden, wo genau welche Problem liegt - das ist ja in der Diskussion hier jetzt recht gut beleuchtet worden. -- D. Düsentrieb ⇌ 18:41, 10. Okt 2004 (CEST)
replies: text:  Das gehört zwar nicht ganz zu Java, aber wo wir gerade bei dem Thema Destruktoren sind: Ich finde, die beiden Artikel über Konstruktoren und Destruktoren sollten zu einem gemeinsamen Artikel verschmolzen werden, denn es sind zwei Aspekte von ein und demselben Thema. Poldi 18:51, 11. Okt 2004 (CEST)
thread_title:  Destructor - Abschnitt wieder entfernt 

message: Zitate:
*Javac ist der wohl bekannteste Bytecode-Compiler bzw. Interpreter von der Firma Sun Microsystems. Er ist ein Bestandteil des JDK.
*Jikes ist die schnellere Alternative von IBM. Jikes ist kein Interpreter wie javac sondern ein JIT-Compiler.
Dass die VM Bytecode interpretiert, ist mir ja klar, aber was genau an Javac ist ein Interpreter? Korrigiert mich, wenn ich mich irre: Javac ist ein Compiler, kein Interpreter.
Umgekehrt: ein JIT-Compiler kann doch eigentlich nur Teil einer Laufzeitumgebung (z.B. der VM) sein - bei Jikes konnte ich aber keine Hinweise darauf finden, ganz im Gegenteil: Auf den Jikes-Webseiten wird besonders betont dass es sich lediglich um einen Command-Line-Compiler handelt...
Ich denke, die entsprechenden Aussagen zu den beiden Compilern sollten entfernt werden. Besteht der Unterschied nicht vielmehr darin, dass Javac in Java geschrieben ist und Jikes in C(++)?
--Asarion 11:39, 23. Okt 2004 (CEST)
replies: text: Full ACK - du hast recht. javac ist kein Interpreter (VM), Jikes auch nicht. Javac ist übrigens eine Referenzimplementations, die nicht auf performanz ausgelegt ist (zumindest anfangs war das so). -- D. Düsentrieb ⇌ 12:47, 23. Okt 2004 (CEST)
thread_title:  Javac/Jikes: Interpreter / Just-in-Time-Compiler? 

message: Da dieser Artikel nicht zum exzellenten Artikel gewählt wurde, muss er noch überarbeitet werden. Hierzu hätte ich einige Vorschläge:
Der Artikel ist zur Zeit eine Mischung aus Übersicht und verschiedenen Details. Diese sollten getrennt werden. Beispiel:
* Diesen Artikel zu einem Übersichtsartikel machen. Dabei sollte kurz (wirklich kurz) erklärt werden, was Java ist (nicht nur eine Programmiersprache) und wo es eingesetzt wird.
* Die anderen Teile in neue Artikel auslagern. Dabei würde ich folgende Aufteilung vorschlagen:
*# Programmiersprache (enthält den Abschnitt, in dem die Syntax derzeit steht) – Dieser Abschnitt sollte erweitert werden, damit die komplette Syntax erklärt wird.
*# API – Der Abschnitt APIs kann meiner Meinung so bleiben (Liste mit Links).
*# VM – Ein Artikel zur Java VM inklusive der Differenzen zu anderen VMs.
*# Geschichte – Sollte ein eigene Artikel mit zwei Abscnitten werden:
*#* Entstehungsgeschichte von Java
*#* Versionsgeschichte von Java
*# Java Entwicklung – Dazu gehören sowohl die Compiler als auch die Entwicklungsumgebungen
Wie sehen das die anderen interresierten Wikipedianer?
Solch große Änderungen sollten nicht von einer Person allein gemacht werden und auch nur im Konsens erfolgen.
-- Herr Schroeder 10:33, 8. Dez 2004 (CET)
replies: text: Als Basisartikel könnte man, wie auf der Java Website, mit Java Technologie beginnen. Von dort aus geht es zur Programmiersprache, zum JDK mit APIs und den ganzen Werkzeugen und zur JRE mit der VM. --Messi 18:28, 8. Dez 2004 (CET)
replies: text:  klingt gut! -- D. Dÿsentrieb ⇌ 01:57, 9. Dez 2004 (CET)
thread_title:  Sprung zum exzellenten Artikel 

message: Auch hier wurde die Anzahl der externen Links den Richtlinien angepasst, siehe Wikipedia:Verlinken und Wikipedia:Was Wikipedia nicht ist. Für weitere Fragen stehe ich hier gerne Rede und Antwort. Grüße --ncnever 05:08, 1. Mai 2005 (CEST)
replies: text: Ich finde es nicht nett, dass Du hier nur von aufräumen redest und dann einen neuen Link anlegst. Ich habe in vorübergehend auskommentiert. Kann jemand etwas zu diesem Link  sagen? --Herr Schroeder 11:19, 2. Mai 2005 (CEST)

text: BTW nach welchen Kriterien hast Du die Links eigentlich aussortiert? --Herr Schroeder 11:20, 2. Mai 2005 (CEST)
replies: text: Ich habe nach den Kriterien "Linkliste enfernen" aussortiert. Es kann durchaus sein, dass unter denen die übrig geblieben sind noch einige unnötige sind. Jedenfalls habe ich die Anzahl reduziert und hoffentlich die richtigen gelöscht. Wenn du andere Weblinks für besser als die aktuellen findest - tausch sie aus - Ich kenne das Internet zu "Java" nicht gut und kann auch nicht die besten Links da hinsetzen. Danke! Mfg --ncnever 12:01, 2. Mai 2005 (CEST)
replies: text: Es wird die Wikipedia in der Öffentlichkeit nicht voranbringen, wenn in hochkarätigen IT-Artikeln Leute herumeditieren, die offen zugeben, dass sie keine Ahnung von der Materie haben. -- Hunding 13:38, 2. Mai 2005 (CEST)
replies: text: Danke, fühlst du dich jetzt besser? Um dich mal ein wenig zu dämpfen - ich habe durchaus Ahnung von Java - nur sagte ich, dass ich das Internet diesbezüglich nicht gut kenne. Spar dir deine falschen Kommentare - bleib sachlich. --ncnever 20:13, 2. Mai 2005 (CEST)

text: Bin ganz deiner Meinung. Mach es so. --jpp ?! 17:38, 18. Mai 2006 (CEST)
replies: text: Erledigt. --Squizzz 19:55, 24. Mai 2006 (CEST)
thread_title:  Weblinks 

message: Letzte Fassung mit vollständigen, weiterführenden Weblinks: 30. 4. 05, 2:42 Uhr
:Ich habe mir die Differenzen mal angeschaut und habe nun einige wieder in den Artikel eingefügt. Ansonsten habe ich versucht den Artikel zu wikifizieren, statt überall externe Links zu erstellen. --Herr Schroeder 15:48, 2. Mai 2005 (CEST)
replies: text: Kann man noch eine engere Auswahl treffen? Bist du dir sicher, dass diese Links die besten verfügbaren sind? (bei den Tutorials zb.). Hast du ein Auge auf den Artikel - dass er nicht wieder zur Linkliste_Java mutiert? Ansonsten wird der Artikel schon fast meinen Ansprüchen gerecht. --ncnever 20:07, 2. Mai 2005 (CEST)
replies: text: Nein, das kann ich nicht versichern. Wenn ich es vorgeben würde, so würden noch wesentlich weniger Links hier sein. Da ich jedoch in der Vergangenheit gesehen habe, dass wiedersinnige Links schnell entfernt werden habe ich keine großen Bedenken mehr daran. --Herr Schroeder 08:29, 3. Mai 2005 (CEST)
thread_title:  Memo: Vollständige Weblinks 

message: Wie schon bei der erfolglosen Wahl zum exzellenten Artikel schlage ich nochmals eine Reorganisation dieses gesamten Bereiches vor.
Als Beispiel habe ich diesen Artikel mal zerlegt und in die Artikel
*Java (Technologie)
*Java Programmiersprache
*Java (Plattform)
aufgesplittet.
Ich bitte darum sich diese Aufteilung anzuschauen. Wenn die Aufteilung hier auf Zuspruch stößt können wir die Artikel in den Wikipedia Namensraum verschieben.
Herr Schroeder 10:57, 1. Jun 2005 (CEST)
replies: text: Sieht gut aus! Wobei „Java Plattform“ jetzt recht dünn ist oder so wirkt. Vielleicht sollte das vorerst noch mit „Java Technologie“ zusammenbleiben. „Java (Programmiersprache)“ könnte auch etwas zu Gunsten von „Java Language Spec“ abspeckt werden. Oder JLS wird gelöscht, weil der Artikel eh nur ein weiterer Detailgrad zwischen „Java (Programmiersprache)“ und der echten JLS ist. -- messi 23:03, 1. Jun 2005 (CEST)
replies: text: Das ist es ja gerade. Ich weiß, dass Java Plattform derzeit ziemlich mager aussieht. Es soll auch mut geben zum Ausbauen. Unter Java Technologie stelle ich mir den gesamten Rahmen vor und unter Java Plattform die Beschreibung der Plattform. Was derzeit als Liste dort steht soll in Zukunft eher als Prosa vorhanden sein, dann wird es schon mehr. --Herr Schroeder 08:59, 2. Jun 2005 (CEST)

text: Ich habe jetzt den Anfang des Artikels Java Plattform erweitert, damit man sieht in welche Richtung das ganze gehen soll. --Herr Schroeder 13:23, 2. Jun 2005 (CEST)

text: Die neue Einordnung sieht sehr sinnvoll und gut aus. Meinen Segen hast du. ;-) --Qbi 16:39, 3. Jun 2005 (CEST)
thread_title:  Reorganisation der Seite 

message: Antifaschist 666 00:46, 17. Okt 2005 (CEST)
thread_title:  Lesenswerte-Diskussion 

message: Im Großen und Ganzen ist der Artikel sehr gelungen, allerdings fehlen meiner Ansicht nach ein paar Sätze zur geschichtlichen Entwicklung, auch wenn ein Link zu Star Seven angegeben ist: Statt nur den Link zu geben könnte man ja schreiben, dass Java sich aus der für Star Seven entwickelten Programmiersprache Oak entwickelt hat oder so.  Zumindest sollte erwähnt werden, dass sich der Name Java von einem altenglischen Wort für Kaffee herleitet (heute ist es nur noch der Name einer Kaffeebohnensorte).  --Felix Krause 15:29, 18. Apr 2006 (CEST)
replies: text: Das ist alles bereits im Artikel Java (Technologie) beschrieben. Damit man es zukünftig auch findet, habe ich den Abschnitt „Weiterentwicklung“ um die Entstehung der Sprache ergänzt und dort einen entsprechenden Link eingebaut. --jpp ?! 21:02, 18. Apr 2006 (CEST)
thread_title:  Geschichtliche Informationen? 

message: Der Satz "Mit Java 1.2 wurden die Java Foundation Classes (JFC) eingeführt, die unter anderem Swing bereitstellen, das zur Erzeugung plattformunabhängiger grafischer Benutzerschnittstellen (GUI) dient und auf AWT basiert." irritiert etwas.
Ich kann zwar nicht mit Sicherheit sagen, ob Sun den Begriff "JFC" erst ab Version 1.2 benutzt hat. Aber der entstehende Eindruck, daß mit 1.2 etwas wesentlich Neues eingeführt wurde, obwohl eigentlich nur die schon immer vorhandene Bibliothek stark angewachsen ist, ist definitiv der falsche. Daß Swing integriert wurde, ist schön und gut, aber mit jeder Version wurden externe Bibliotheken integriert, sei es das DOM-API, XML-Parser, ImageIO oder was auch immer.
In dem Punkt besitzt Java 1.2 keinerlei Alleinstellungsmerkmal. Sollte Sun bei dieser Version den Begriff JFC eingeführt haben, kann man das auch so formulieren. Aber ich glaube, selbst das wäre falsch, weil der Begriff IMHO schon vorher existierte.
:Soweit ich mich entsinne, wurde JFC mit Version 1.2 ein Bestandteil der J2SE, vorher waren sie eine eigenständige Zusatzbibliothek. --jpp ?! 12:23, 14. Jun 2006 (CEST)
thread_title:  JFC 

message: Hallo. Leider habe ich keine Quelle oder ähnliches, die meine Vermutung stützt, aber Java ist doch eigentlich trotz JIT und Hot-Spot immer noch nicht schneller als echter nativer Code...
:Wer behauptet denn sowas? Beziehst du dich auf eine bestimmte Stelle im Artikel? --jpp ?! 09:20, 10. Aug 2006 (CEST)
replies: text: Zur Performance gibt es kaum 'falsche' Aussagen, da diese je nach Anwendungsfall, Architektur und Mondstand stark unterschiedlich sein kann. Siehe beispielsweise , , . Die Ergebnisse können also durchaus variieren. Deshalb ist die Frage nicht so einfach zu beantworten, manchmal mag Hotspot langsamer sein, manchmal schneller. Die hängt aber sicher noch vom Compiler ab und von der Ausgefeiltheit der Hotspot-Engine und wie die aktuellen Prozessoren den jeweiligen Konzepten entgegenkommen (oder umgekehrt). -- Dishayloo + 20:09, 8. Okt 2006 (CEST)
thread_title:  JIT schneller als nativer Code? 

message: Es hat keinen Sinn hier alle Frameworks für Java aufzulisten, da einige Hundert existieren. --Squizzz 15:51, 30. Aug 2006 (CEST)
replies: text: Wenns reicht.. Vielleicht sollte man die wichtigsten fünf listen.. stellt sich nur die Frage, woran man das festmachen und ob man das überhaupt entscheiden kann. --Schmiddtchen 说 12:56, 9. Okt. 2006 (CEST)
replies: text: Vielleicht per Abstimmung? Zum Beispiel so: Wenn sich hier mindestens drei angemeldete Benutzer mit mehr als 200 Bearbeitungen finden, die ein Framework für wichtig halten, dann ist es wohl wichtig. --jpp ?! 15:11, 9. Okt. 2006 (CEST)
replies: text: Man sehe sich die letzten zwei Jahre Java-Magazin an und dann erkennt man doch, was wirklich wichtig ist, oder? --Squizzz 11:23, 10. Okt. 2006 (CEST)
replies: text: War das jetzt ironisch gemeint? Ich denke nicht, dass das Java-Magazin über die Dinge am häufigsten schreibt, die wirklich am häufigsten benutzt werden. Wohl eher über die Produkte, für die am erfolgreichsten geworben wird. Da ist viel Hype im Spiel. Außerdem können auch Frameworks wichtig sein, deren Bedeutung früher groß war und heute nicht mehr (auch wenn mir da jetzt gerade kein Beispiel einfällt). --jpp ?! 13:15, 10. Okt. 2006 (CEST)
replies: text: Das war schon ernst gemeint. Allerdings wäre statt einer Liste ein Abschnitt mit Text noch sinnvoller. Da könnte man auch die Relevanz der Frameworks besser begründen. Vielleicht hab ich ja in Kürze Zeit, doch im Moment muss ich mich noch um zwei andere Artikel kümmern. --Squizzz 13:33, 10. Okt. 2006 (CEST)
replies: text: Ja, auch ich würde Text gegenüber einer Liste bevorzugen. Darin sind wir uns einig. --jpp ?! 16:20, 10. Okt. 2006 (CEST)
thread_title:  Frameworks 

message: Java ist - vor allem auch - eine Insel. Und eine amerikanische Form der unendlichen Variationen (kawe, kawa, ...) zur Bezeichnung von Trink-Kaffee. Ich kenne aber nicht die übliche Form, wie hier so ein Thema dann mit einer Navigationsseite aufgeteilt wird!
ich habe mal ne Frage zur Aussprache: Ist das sicher, dass Java so wie in der Lautschrift dargestellt ist ausgesprochen wird? Wenn ja, wieso so komisch? --- jake ----
Ich kenne mehrere Aussprachen. Neben [ˈdʒɑːvə] kenne ich [ˈdʒɑːvɑː], [ˈʒɑːvɑː] und [ˈjɑːvɑː]. --Herr Schroeder 09:34, 12. Okt 2005 (CEST)
replies: text: Heißt das, dass früher mal im Artikel eine Lautschrift/Aussprache angegeben wurde? Wurde das dann ausdiskutiert und einvernehmlich wieder raus genommen? Eigentlich gehört die ja auf eine (noch zu erstellende) Java-Wictionary-Seite. Die Aussprache hätte mich jetzt nämlich auch interessiert... Nivram 10:39, 25. Jan. 2007 (CET)
thread_title:  Der Name Java 

message: Ich hab da mehrere Probeme mit dem Artikel:
*Java ist nicht rein objektorientiert, int usw. sind keine Objekte.
*Applets werden beschrieben, sind aber heute fast bedeutungslos.
** Applets werden häufig für alles gebraucht das nicht Klicki-Bunti sein muss: IRC im Browser, ICQ2Go, NTP-Uhr im Browser, etc und selbst wenn diese Anwendungen wegfallen, haben sie historische und pedagogische Bedeutung (wird an der UNI KL gelehrt, beispielsweise.). Man sollte es vielmehr nach Java-Applet "kopieren".
*Es fehlt der ganze J2EE/Server Bereich, der sehr viel gewicht hat.
*Es sollte auch eine deutliche Trennung vollzogen werden zwischen der Implementierung von SUN und der Sprache an sich.
*JAVA ist eine spezielle Sorte Kaffe, keine umgangssprachliche Beziechnung, oder?
*Es sollte vielleicht noch ein Verweis auf Vorgänger gemacht werden (Smalltalk, UCSD Pascal,...)
Wenn ich dazukomme, das in vernünftige Sätze zu packen, mache ich das.
OliD 20:53, 19. Mai 2003 (CEST)
thread_title:  Ich hab da ein Problem ... 

message: Ich muss Dir leider in ein paar Punkten widersprechen:
* Java ist rein objektorientiert, für alle primitiven Typen wie "int", usw. gibt es auch entsprechende Klassen, z. B. Integer.
* Applets sind nicht bedeutungslos, wenn Du Bankgeschäfte über das Internet abwickelst, kommst Du an Java nicht herum
* J2EE fehlt, da stimme ich absolut zu
* Nun, Sun ist nun mal der Erfinder von Java. Man könnte höchstens andere Implementierungen wie Kaffee (gnu) oder Jikes (IBM) erwähnen.
* Java ist eine ziemlich starke Kaffesorte, die von der Insel Java her bezogen wird
* Mit dem Vorgänger Smalltalk bin ich einverstanden
jonelo 21:45, 19. Mai 2003 (CEST)
thread_title:  Rein objektorientiert? 

message: Ich geb ja zu, manchmal übertreibe ich ein bischen... Aber immer nur zur Verdeutlichung :-))
*Mit dem "reinen" objektorientierten hast Du dir da grade selbst widersprochen oder? "Rein" ist Python, C# und Smalltalk. Dort gibt es nur (aussschliesslich) Objekte. Und keine Primitivtypen. Die sind übrigens auch noch ein Problem für die Portabilität, da ihre Grösse vom ausführenden System abhängt.
*Mit trennen (Java/SUN) meinte ich, dass Features der VM von Sun nicht von Eigenschaften der Sprache Java getrennt wurden. zB JIT ist ein Feature der VM, hat im Prinzip nix mit Java zu tun. Und die VM ist auch nicht von Java abhängig, man kann Bytecode drauf ausführen, der aus allen möglichen Sprachen herkommt. (Praktisch macht das recht wenig Unterschied, da eh 90% der Anwendungen auf der Sun VM laufen, und mit den Sun Klassen)
*Ich weiss, dass Applets nicht bedeutungslos sind, ich benutze fast täglich eins. Das ist aber eine Nische, die auch nicht grösser werden wird. Am interessantesten ist Java vor allem auf dem Server, und wenn auf dem Client, dann als normale Applikation.
*Eventuell noch ein Verweis auf C#, da es ähnliche Konzepte verwendet. (Done)
OliD 09:11, 20. Mai 2003 (CEST)
thread_title:  ein bischen ... 

message: Bin auch der Meinung, dass "rein" objektorientiert auf Java nicht zutrifft. Dasselbe gilt aber auch für c#, es kennt zwar autoboxing, aber primitive Datentypen sinds trotzdem. Mit Java 1.5 gibts ja auch autoboxing, aber deshalb wirds auch nicht "rein" oo
Sebastian 00:50, 9. Juli 2006 (CEST)
thread_title:  objektorientiert und c# 

message: Ich hab ein Problem mit Patrick Naughton:
Wie sollte ich denn bitte das dann in der Bio schreiben?
OliD 18:53, 20. Mai 2003 (CEST)
thread_title:  Vaterfigur 

message: Ich versuch mal das zusammenzufassen:
*Java ist in jeder Hinsicht plattformunabhängig.
*Nur James Gosling wird namentlich genannt.
*Die VM haben wir schon abgetrennt, einen Verweis auf C# haben wir auch schon.
*Material zur Geschichte von Java: ( 1 2 3 4 5 6 )
*Wir sollten vor allem als Vorgänger Simula einbauen, und Smalltalk. Die hatten vom Konzept her mehr mit Java zu tun, als C++. (VM, ...)
*Die Serverseite von Java sollte noch erwähnt werden. (J2EE)
*Die Mobile Seite fehlt auch noch (J2ME)
*Material zur VM: (1)
Wenn Dir was fehlt, machs einfach dazu. Ansonsten lösch einfach den Rest weg.
OliD 12:26, 21. Mai 2003 (CEST)
thread_title:  in jeder Hinsicht 

message: transient sorgt keineswegs für die automatische Serialisierung. Transient bestimmt, dass ein Member eben nicht serialisiert wird. Er taucht im serialisierten Zustand des Objekts nicht auf. Bei der Deserialisierung wird für transiente Variablen der Default-Wert (nicht Initialwert) eingesetzt, also 0 bzw. 0.0 bzw. false bzw. null. Soll ein Transient einen anderen Wert erhalten, so ist die Deserialisierung durch Implementieren von readObject() selbst zu übernehmen, wobei man noch defaultReadObject() kennen und eventuell aufrufen sollte.
--ChristianHujer 21:38, 3. Sep 2004 (CEST)
thread_title: (Keine) automatische Serialisierung bei <code>transient</code>

message: enum ist in Java kein Typ, insbesondere kein Primitiv, sondern ein Typkonzept, wie class oder interface eben keine Typen, sondern Typkonzepte sind. Deshalb habe ich enum aus der Liste der Typen entfernt. Vor allem sind Java-Enums komplex, d.h. sie haben Konstruktoren und können auch Member (statisch und Instanz-) haben.
--ChristianHujer 21:38, 3. Sep 2004 (CEST)
thread_title: Enum kein Typ

message: Ich habe heute den Link der API-Dokumentation wieder auf die Version 1.4.2 gesetzt. Wir können den Link auf die 1.5.0 (oder 5.0) setzen, wenn diese nicht mehr Beta oder RC ist sondern wenn sie es wirklich zum Release geschafft hat. --Herr Schroeder 09:37, 8. Sep 2004 (CEST)
thread_title:  Link auf API-Dokumentation 

message: Ich bin auf den Eintrag Java über die Rubrik in Review gestossen, und finde beim ersten Lesen eine ganze Reihe von Punkten, die ich für verbesserungsfähig halte. Hier hilft meines  Erachtens ein Vergleich mit der englischen Version, die mir in der Darstellung an einigen Stellen deutlich besser gefällt.
Haupteindruck: zu unübersichtlich, zu technisch, als Hauptseite teilweise zu detailliert.
Für einen Nicht-Experten geht die wahre Bedeutung daraus nicht hervor.
Eindruck von der Diskussion: Man diskutiert über Details, während Ausbau/Struktur der Seite noch nicht gut sind.
Da bereits eine Reihe von Autoren an diesem Artikel geschrieben hat, möchte ich meine 
Vorschläge zunächst zur Diskussion stellen. Falls die Ideen auf Zustimmung treffen, bin ich gern bereit, auch selbst Beiträge zu liefern.
Mir fehlen:<BR>
- Darstellung der Bedeutung von Java<BR>
- Der Architekturaspekt <BR>
- Garbage collection<BR>
- Klassen/Interfaces
Aus meiner Sicht zu ändern:<BR>
- Geschichte nach hinten, evtl. kürzer fassen<BR>
- Grundkonzepte erweitern<BR>
- Sprachkonstrukte zu technisch, zu ausführlich: Details auslagern<BR>
- Versionsgeschichte : wesentlich kürzer, max. 1 Seite !!!<BR>
- APIs : Hier sollten nicht die Einzeltechnologien, sondern die SUN Distributionen (J2SDK, J2EE, J2ME) aufgeführt werden. Die Technologien finden sich dann unter den entsprechenden, bzw. unter einem Link "Sonstige Java Technologien". Evtl. Abschnitt umbenennen zu Distributionen ?<BR>
- Modulare Ausführbarkeit : statt Modulen sollte man von Komponenten sprechen,
ich würde Doclets und Translets hier rausnehmen. Kriterium: Container-Spezifika.
gut gefallen mir bereits:<BR>
- Plattformunabhängigkeit<BR>
- Merkmale der Sprache<BR>
- Abgrenzung zu anderen Sprachen
hier würde ich vorläufig nichts ändern (diese Abschnitte sind 
teilweise besser dargestellt als im englischen Pendant).
Feedback ?
:Mein Feedback:
:* Bedeutung der Sprache ist ok, sollte aber zeitlos formuliert werden.
:* Was meinst Du mit dem Architekturaspekt?
:* Garbage Collection, Schnittstellen und Klassen sind unter "Merkmale der Sprache" schon erwähnt.
:* Sprachkonstrukte: Du meinst das unter Syntax oder? Das finde ich gut, danach kann man gleich anfangen zu programmieren.
:* Ja, Versionsgeschichte kürzer.
:* APIs: Das sind schon welche, gefallen tut mir der Abschnitt aber auch nicht.
:--Supaari sag'smir! 02:26, 6. Okt 2004 (CEST)
thread_title:  Generelle Anmerkungen 

message: Hallo Meph666, Jikes wird nicht von irgendwelchen Leuten als schneller angesehen, sondern ist objektiv und messbar schneller als javac. Dieser Artikel ist zwar schon etwas älter, aber auch heute ist Jikes immer noch deutlich schneller aks javac. Was mich nur noch interessieren würde: Kennst du Jikes, oder hast du "nur" reflexartig eine nach POV riechende Formulierung weichgespült? (Fasse das bitte nicht als persönlichen Seitenhieb auf. Mir war nur diese Wikipedia-typische Verhaltensweise aufgefallen; ich mache so was ja manchmal wahrscheinlich auch ;-) --Langec ☎ 11:01, 14. Mär 2005 (CET)
thread_title:  Jikes ist schneller 

message: Sind Zuweisungen in Java Ausdrücke oder Anweisungen?Ich habe einmal in Google-Groups "Java Zuweisungsanweisung" eingegeben - Ergebnis: 1. Dann habe ich "Java Zuweisungsanweisung" eingegeben - Ergebnis 0. Außerdem fragt Google: "Meinten Sie: Java Zwangseinweisung". Ich weiß nicht, was ich davon halten soll. --Flogger 12:14, 19. Mär 2005 (CET)
thread_title:  Java Zwangseinweisung 

message: Ich habe nun die Seite reorganisiert, wie bereits angekündigt. Es gibt jetzt die folgenden Seiten:
*Java (Programmiersprache)
*Java (Plattform)
*Java (Technologie)
In diesem Artikel müssen noch die Abschnitte Grundkonzepte der Sprache und Compiler angepasst werden. Dieses habe ich bislang nicht gemacht, da dieses erstens ein wenig mehr Arbeit ist und zweitens am ehesten Diskussionsbedarf weckt.
-- Herr Schroeder 16:17, 19. Jul 2005 (CEST)
thread_title:  Seite reorganisiert 

message: Das wäre ja das neuste !
Dokumente wie die API-Beschreibungen gibt es es bei SUN meistens nur auf Englisch und japanisch, neuerdings z.T. auch auf chinesisch.
Aber im allgemeinen ist Deutschland für SUN doch viel zu unbedeutend und unwichtig.
:Das ist ein guter Einwurf. Nach welchem Kriterium wird das hier eigentlich entschieden? Die API-Dokus sind genauso nicht auf Deutsch zu finden wie die Language Specification oder gar die Programmiersprache selbst. Lediglich einige vorgefertigte Klassen (wie etwa für Swing) halten an bestimmten Stellen Informationen auch mehrsprachig bereit, das hat aber mehr mit Internationalisierung als mit der Programmiersprache selbst zu tun. --Royd 21:17, 23. Nov 2005 (CET)
thread_title:  java deutschsprachig ? 

message: Mir fehlt ein Abschnitt über die Kritik an Java: Da Java fast rein objektorientiert ist, entsteht ein riesiger Overhead.
Und portabel: Ich habe weniger Probleme ein Windowsprogramm auf meinem Linuxrechner (wine) zu starten, als ein Javaprogramm.
--217.224.119.234 12:36, 14. Apr. 2007 (CEST)
replies: text: Dann liefer bitte nachprüfbare Belege für deine Aussagen im Sinne von Wikipedia:Quellenangaben. --jpp ?! 12:43, 14. Apr. 2007 (CEST)

text: durch OOP entsteht fast gar kein overhead, wenn dann durch die VM. Und das mit Portabilität ist kompletter Unsinn. --Kurt Seebauer 13:04, 14. Apr. 2007 (CEST)
thread_title:  Kritik an Java 

message: * Ein paar Beispiele bekannter Programme die mit Java geschrieben wurden fehlt mir irgendwie. Generator 16:36, 12. Jul. 2007 (CEST)
replies: text: Bin mir nicht sicher, ob das sinnvoll ist. Eine solche Liste zieht meistens jede Menge Spammer an. Aber wenn, dann gehört m. E. Apache HTTP Server hinein. Der betreibt vermutlich mehr als die Hälfte aller Webserver auf diesem Planeten. --jpp ?! 17:36, 12. Jul. 2007 (CEST)

text: Ich sehe keinen Sinn in solch einer Liste und der Apache ist ja nicht in Java geschrieben. Du meintest wahrscheinlich den Tomcat ;-) --Stefan Birkner 17:50, 12. Jul. 2007 (CEST)
replies: text: Nein, ich glaubte wirklich, der Apache sei in Java geschrieben. Oh Gott, wie peinlich. :-( --jpp ?! 18:09, 12. Jul. 2007 (CEST)
thread_title:  Beispiele 

message: Über die zentrale Ressourcenseite "Java" ist ein fertig eingerichteter Java-Kurs zu erreichen. Darin besteht der Mehrwert dieses Weblinks. --Nutzer 2206 11:01, 14. Jul. 2007 (CEST)
replies: text: Dies ist keine besonders hilfreiche weiterführende Information zum Thema Java (Programmiersprache). --Stefan Birkner 10:46, 15. Jul. 2007 (CEST)
replies: text: Es ist die Seite der Wikiversity mit zwei angebotenen Kursen, was soll daran nicht hilfreich sein!? Bei Wikibooks, Wikisource oder Wikinews würde es keine Diskussion geben... Bitte wieder rein. --Nutzer 2206 11:53, 15. Jul. 2007 (CEST)
replies: text: Siehe Wikipedia:Weblinks. Diese Kurse sind eben nicht vom Feinsten. --Stefan Birkner 12:02, 15. Jul. 2007 (CEST)
replies: text: Glückwunsch, du darfst was tun: Einmalige Gelegenheit, schau mal da vorbei und erklär warum der zugehörige Kurs nicht vom Feinsten ist... (Bitte bedenke:Er richtet sich an Einsteiger). --Nutzer 2206 12:04, 15. Jul. 2007 (CEST)
replies: text: Wenn du das erledigt hast, erklär mal bitte kurz, was ich auf WP:WEB finden sollte und weshalb das mit dem WV-Link kollidiert!? Kann da so direkt nichts sehen... --Nutzer 2206 12:07, 15. Jul. 2007 (CEST)

text: Der Artikel dient nicht dazu Einstiegskurse in Java zu verlinken. Auch habe ich nie behauptet, dass der Kurs Schrott ist. Ich habe nur indirekt angesprochen, dass die angegebene Webseite nichts besonderes ist. Ehrlich gesagt kenn ich mich in den Sammelsurium der dortigen Links nicht aus und mir erschließt sich auf die Schnelle deren Zusammenhang nicht. --Stefan Birkner 13:29, 15. Jul. 2007 (CEST)
replies: text: "Diese Kurse sind eben nicht vom Feinsten." - das sehe ich anders. Es ist keine Website (bitte mit i statt ei!, siehe auch hier: Website), sondern das Pendant zum Wikipedia-Artikel in der Wikiversity. Das der Artikel keine Einstiegskurse verlinken soll, wurde ja auch gar nicht bestritten. Nur dass er auch auf die Wikiversity als Wikipedia-Schwesterprojekt verweisen soll, da dort weitere Informationen zur Programmiersprache Java zu finden sind. Dass du bei den dortigen Links nicht durchblickst ist schade, aber ich werde das bei Gelegenheit weiter geben, so dass die Seite nach Möglichkeit einsteigerfreundlicher gestaltet wird. Im Übrigen, für die Zusammenstellung von Lehr- und Lernmaterialien ist wie gesagt die Wikiversity verantwortlich, deshalb ja auch der Link. --Nutzer 2206 13:35, 15. Jul. 2007 (CEST)
replies: text: Ich weiß nicht, was das Anliegen der Wikiversity ist und kann deshalb dort auch keine vernünftige Kritik eingeben. Für die Wikipedia sollen verlinkte Artikel dem Leser einen Mehrwert versprchend und vom Feinsten sein. Ich erkenne bei dem verlinkten Artikel jedoch nur ein Sammelsurium weiterer Links. --Stefan Birkner 13:38, 15. Jul. 2007 (CEST)

text: Wikiversity: Java (Programmiersprache) – Kursmaterialien, Forschungsprojekte und wissenschaftlicher Austausch
Denkaufgabe: Warum wird ein Standard-Link eingerichtet für die Wikiversity, der auch besonders auf "Kursmaterialien, Forschungsprojekte und wissenschaftlicher Austausch" hinweist, wenn dann Wikiversity-Seiten bitte nicht verlinkt werden sollen!? 
Du hast geschrieben: "Ich weiß nicht, was das Anliegen der Wikiversity ist" - Das "Anliegen" der Wikiversity ist die Zusammenstellung und Betreuung von Lehr- und Lernmaterialien sowie die Durchführung von Kursen auf Basis dieser Materialien. Das ist in etwa die Projektbeschreibung, weiteres erfährst du im WP-Artikel zur Wikiversity. Wie bereits erläutert, verlangt niemand, dass die Wikipedia ein Verzeichnis der Lernmaterialien pflegt, dafür ist die WV zuständig und das wird bereits erledigt, deshalb ja auch der Hinweis auf das Wikiversity-Verzeichnis.
Du hast geschrieben: "Ich erkenne bei dem verlinkten Artikel jedoch nur ein Sammelsurium weiterer Links." - Es ist kein verlinkter Artikel. Artikel finden ihren Platz in der Wikipedia und haben daher in der Wikiversity nichts verloren. Die Seite ist eine "Zentrale Ressourcenseite", solche Seiten bieten Zusammenstellung von Lehrbüchern, Kursen und wichtigen Ressourcen nach Themen. Das du dort nicht durchgeblickt hast, wird wie gesagt weitergegeben und bei einer Überarbeitung der Seite berücksichtigt. --Nutzer 2206 13:50, 15. Jul. 2007 (CEST)
thread_title:  Wikiversity 

message: >>Der Objektzugriff in Java ist über Referenzen genannte Zeiger implementiert<<
Referenzen und Zeiger sind nicht synonym zu verwenden, es sind zwei völlig verschiedene Konzepte! Zeiger zeigen direkt auf den Ablageort eines Datums (z.B. Speicherstelle). Referenzen verweisen auf ein Datum, in welchem der eigentliche Ablageort für die Referenz unsichtbar vermerkt ist. Der große Vorteil von Referenzen ist, das die Daten im Speicher nicht fix abgelegt, sondern verschiebbar sind und somit einer Speicherfragmentierung entgegengewirkt werden kann.
:Danke für den Hinweis. Ich habe den Satz korrigiert. --jpp ?! 13:13, 27. Apr. 2007 (CEST)
replies: text: Referenzen gibt es schon in Java. Die von dir zitierten Artikel behandeln lediglich die Parameterübergabe. Auch Referenzen werden als Wertparameter übergeben, d. h. die aufgerufene Methode kann zwar den Zustand des referenzierten Objekts ändern, jedoch nicht die von der aufrufenden Methode übergebene Referenz. --jpp ?! 14:52, 18. Jul. 2007 (CEST)
thread_title:  Referenzen 

message: Sind die Pakete nicht gleich Paket (UML) --SonniWP2 19:20, 22. Aug. 2007 (CEST)
replies: text: Nein, andere Abstraktionsstufe. Paket (UML) ist sozusagen die Metaklasse für die Java-Pakete, oder andersrum formuliert: Java-Pakete sind eine konkrete Implementierung des abstrakten UML-Konzeptes. Java-Pakete lassen sich aus UML-Modellen generieren, ebenso wie sich Java-Klassen aus UML-Klassen generieren lassen. Sie sind aber nicht das gleiche. --jpp ?! 23:04, 22. Aug. 2007 (CEST)
replies: text: Das Paket kam aber wohl eher aus der en-WP und die haben nur kein Java-Paket. (ein fehlendes k kann verdammt viel Unterschied machen).  --SonniWP2 00:01, 23. Aug. 2007 (CEST)
replies: text: Häh? Ich verstehe gerade nicht, worauf du hinauswillst. --jpp ?! 12:12, 23. Aug. 2007 (CEST)
thread_title:  Paket 

message: Sun wird Java ME, SE und EE unter der GNU GPL Version 2 veröffentlichen. Siehe: http://www.sun.com/software/opensource/java/project_overview.jsp Mms 22:41, 13. Nov. 2006 (CET)
thread_title:  GNU GPL 

message: Ich kenne die Programmiersprache Java nicht sonderlich gut, interessiere mich aber für diese. Es bleibt nach dem lesen dieses Artikels folgende Frage für mich offen: Welche Art von Programme werden mit Java vornehmlich programmiert? Und gibt es bekannte Beispiele für Programme die mit Java programmiert wurden. Ich würde mich freuen wenn diese Fragen in diesem Artikel auch noch beantwortet werden könnten. Liebe Grüße
: Spontan fallen mir ein:  Webservices (wie WWW) im Enterprise Bereich, plattformübergreifende Software,  Applets im Browser (über die Relevanz lässt sich streiten), begrenzt auch auf auf Handys (JavaME). Größere, mir bekannte Beispiele: Eclipse und NetBeans (die Entwicklungsumgebungen selbst), Maple, ImageJ,  NASA World Wind SDK. Macht eine Auflistung von ein paar Programmen hier wirklich Sinn? Anhand was will man dann entscheiden, welche Programme (nicht) relevant für die Liste sind?  --Locked 16:10, 19. Nov. 2007 (CET)
replies: text: Java wird heutzutage im Unternehmensbereich vielfach eingesetzt es existiert eine Unzahl von Programmen, die in dieser Programmiersprache geschrieben wurden. Eine Auflistung halte ich deshalb für mehr als überflüssig. Es dürfte für (angehende) Softwareentwickler leicht sein entsprechend Programme im Internet zu finden. --Stefan Birkner 12:07, 24. Nov. 2007 (CET)
thread_title:  Anwendungsbereich 

message: Java hat eine großartiges Standardbibliothek. Ein Überblick über die wichtiges Kategorieren wäre doch nett oder?
*java.awt - AWT (Abstract Windowing Toolkit) beinhaltet Klassen zur Grafikausgabe und zur Nutzung grafischer Benutzeroberflächen.
*java.io - Für Ein- und Ausgabe. Dateien werden als Objekte repräsentiert. Datenströme erlauben den sequenziellen Zugriff auf die Dateiinhalte.
*java.nio - Neue IO Implementierung , ggf performanter
*java.net - Client Server Programmierung , Sockets usw..
*java.lang - beinhaltet String, Thread und weiteres 
*java.rmi - für entfernte Methodenaufrufe 
*java.text - formatierung Datumswerte, Zahlen
*java.util - Datenstrukturen, Zufallszahlen
*java.math - große fließkomma Zahlen, Hilfsfunktionen 
*javax.net - beinhaltet SocketFactory
*javax.naming - Zugriff auf Namesndienste
*javax.print - Java Print Service API
*javax.swing - Swing Komponenten (Erweiterte GUI Komponenten)
*javax.xml.bind - XML Binding mittels JAXB
*javax.xml.stream - XML Pull Parser API ( Stax)
*javax.xml.xpath - XPath API
*org.w3c.dom - Klassen für DOM Baumstruktur nach W3C Standard
16:02 15.6 CEST
:Ansatzweise gibt’s das in Java Platform, Standard Edition. Ist aber noch nicht gut verlinkt. --j ?! 18:02, 16. Jun. 2008 (CEST)
replies: text: Sei mutig! :-) --j ?! 20:27, 16. Jun. 2008 (CEST)
thread_title:  Standardbibliothek 

message: "Zudem unterstützt Java die Datenkapselung (Programmierung) nur unzureichend, da der Zugriff auf interne Attribute - in der Regel über so genannte getter - Referenzen auf diese Attribute exportiert, über die die Attribute von außen direkt, also außerhalb der Kontrolle des Objekts, geändert werden können; die einzige sprachimmanente Absicherung der Datenkapselung durch Rückgabe von clones ist i.A. inperformant."
Datenkapselung wird unterstützt! Es steht dem Programmierer frei, ob er Getter/Setter Methoden implementiert. Dies hat nichts mit Datenkapselung zu tun! Außerdem sind das keine Referenzen, sondern Methoden der jeweiligen Instanz der Klasse.
:Ja, das Zitat ist Quatsch und zielt auf die lasche Benutzung von vorhandenen Objektschnittstellen ab. Das "Problem", was der Autor des Abschnitts anspricht hat schon mit Referenzen zu tun: er beschwert sich darüber, dass man mit einem Getter an das gekapselte Objekt kommt und dann alles damit machen kann, was das referenzierte Objekt erlaubt, auch ausserhalb des Kontextes des kapselnden Objektes. Ist aber tatsächlich quatsch, weil extrem implementationsspezifisch - das gekapselte Objekt muss schliesslich auch irgendwo im Heap liegen und ansprechbar sein... Wenn das kapselnde Objekt die volle Kontrolle über sein Abhängigkeiten behalten will, darf es halt keine getter bereitstellen und die Modifikationsoperationen selbst kapseln.. dann klappts auch mit dem Nachbarn. Und klonen bricht das Problem ja nun vollends in zwei Teile. Ersatzlos streichen. --Schmiddtchen 说 01:47, 1. Feb. 2008 (CET)
replies: text: Ja man kann nicht mehr benötigte Objekte unnötigerweise referenzieren, wenn man bspw. Quelltext umgeschrieben hat und drin alte nicht mehr benötigte Fragmente vorhanden sind, die nicht gelöscht wurden. Gruß -- Meph666  → post 01:20, 6. Okt. 2008 (CEST)
thread_title:  Objektorientiert 

message: "Deren wichtigster Bestandteil ist die Java Virtual Machine (Java-VM), die die Programme ausführt, indem sie den Bytecode interpretiert."
Hier wird gleich zu Beginn der Eindruck erweckt, Java sei noch immer eine interpretierte Sprache. Dabei wird, wie es auch später erwähnt wird, erst in Bytecode compiliert und dann beim Programmstart (just-in-time) in nativen Code compiliert.
: Nicht ganz. Siehe zB http://java.sun.com/products/hotspot/docs/general/hs2.html Abschnitt "Code Size" und "Dynamic Compilation" oder http://java.sun.com/javase/technologies/hotspot/. In Wikipedia unter Hotspot-Optimierung. Besserer Ausdruck ist wohl "indem sie den Bytecode interpretiert und bei Bedarf compiliert."--Locked 15:57, 6. Nov. 2007 (CET)
replies: text:  Java ist ein "Compreter". Der Quelltext wird durch einen Compiler in einen Zwischencode (bei Java "Bytecode" genannt) übersetzt (Quelle: ), welcher dann von einer Virtuellen Maschine interpretiert wird (Quelle: ). Intern arbeiten nahezu alle Interpreter als Compreter. Der Unterschied ist, dass bei Java für gewöhnlich der von "javac" erzeugte Zwischencode in eine Datei (Endung: .class) geschrieben wird. Diese Datei kann dann verteilt werden, sodass die Java-Anwendung plattformunabhängig bleibt (sie kann auf jeder Plattform ausgeführt werden, für die es einen Bytecode-Interpreter, eine sog. "Java Virtual Machine", gibt), ohne dass der Quelltext offengelegt werden muss. Java Bytecode ist viel abstrakter, als nativer Maschinencode, allerdings nicht so abstrakt, wie der Quelltext, aus dem er erzeugt wurde. Durch diesen Abstraktionsunterschied ist Java Bytecode, im Vergleich zu "native code", sehr anfällig für Reverse Engineering. 217.94.253.251 14:00, 29. Okt. 2008 (CET)
thread_title:  Java interpretiert 

message: Hallo. Im Abschnitt C# fehlt, daß C# (wie auch vb.net) Operatorüberladung beherrschen. 213.39.171.68 17:34, 7. Apr. 2007 (CEST)
replies: text: und wofür ist das relevant? ganz abgesehen davon, dass operatorenüberladen völlig überbewertet wird. ob ich nun z.b. die methode "add" aufrufe oder "+" direkt auf nen objekt anwenden kann, spielt ansich keine rolle. --217.84.41.45 12:44, 26. Nov. 2008 (CET)
thread_title:  Operatorüberladung 

message: Ich würde mal behaupten Java gibt es auf allen heute in nennenswerten Umfang eingesetzten Betriebssystemen auf dem PC, vergleichbaren und größeren Rechnern. Insbesondere auf allen UNIX-Systemen und zudem auf einer Vielzahl kleinerer Geräte insbesondere Smart Cards. 88.68.127.104 11:24, 16. Dez. 2008 (CET)
replies: text: Stimmt. Eine alte Version lief schon auf meinem Psion 5mx (unter Epoc32), und Java ME läuft auf jedem besseren Mobiltelefon. Es wäre zutreffender, in der Infobox hinter Betriebssysteme viele zu schreiben. --Thüringer ☼ 11:50, 16. Dez. 2008 (CET)
thread_title:  Liste der Betriebssysteme unvollständig 

message: Lizenz macht bei einer Programmiersprache doch gar keinen Sinn. Eher ein Patent käme hier in Frage, oder? Habe das auch mal auf der Diskussionsseite der Vorlage angesproches. Bitte um Kommertare dazu. Sonst werde ich den Parameter aus der Vorlage entfernen. --Thornard, Diskussion, 16:00, 10. Aug. 2007 (CEST)
replies: text: Java hat eine Lizenz und kein Patent. Hier machts also auf jeden Fall Sinn. Ansonsten siehe Vorlage Diskussion:Infobox Programmiersprache --Sebastian.Dietrich 09:55, 22. Dez. 2009 (CET)
thread_title:  [[Vorlage Diskussion:Infobox Programmiersprache]] 

message: Folgende Einstiegsbücher zu Java würde ich in die Literaturliste mit aufnehmen:
Schiedermeier R.: Programmieren mit Java. Eine methodische Einführung. ISBN 3827371163.
Barnes D.J., Kölling M.: Java lernen mit BlueJ. Eine Einführung in die objektorientierte Programmierung. ISBN 382737152X
Block M.: Java-Intensivkurs. In 14 Tagen lernen Projekte erfolgreich zu realisieren. ISBN 3540722718
Abts D.: Grundkurs Java. ISBN 3528357118
Zu Java und Bildverarbeitung ist folgendes Buch bereits ein Standardwerk:
Burger W., Burge M.J.: Digitale Bildverarbeitung. Eine Einführung mit Java und ImageJ. ISBN 3540309403
: imho ist die literatur angabe dazu da, zu vermerken, welche quellen man für ein lemma benutzt hat und nicht, um werbung für das ein oder andere buch zu machen. just my 2 ct. --Der uzi 10:06, 15. Okt. 2007 (CEST)
replies: text:  zur Programmiersprache Java gibts inzwischen jede Menge Bücher. Wenn man die Spezialbücher zu "Java und ..." dazunimmt, sinds vermutlich 1000+. Hier gilt somit insbesonders WP:Literatur und da "...wissenschaftlich maßgeblichen Werke oder um seriöse, möglichst aktuelle Einführungen" und "Deutschsprachige Literatur ist gegenüber gleichwertiger fremdsprachiger Literatur in der Regel zu bevorzugen". Die aktuelle Literaturliste gehört somit aufgeräumt - die oben genannten Bücher gehören da aber mMn auch nicht dazu... --Sebastian.Dietrich 09:52, 22. Dez. 2009 (CET)
thread_title:  Weitere Javaliteratur 

message: Ich habe den Link dorthin entfernt, da es sich bei den Bücher dort um Ruinen ohne echte Entwicklungschance handelt. Meines Erachtens sollte von hier nur auf nutzbare Bücher verlinkt werden. --84.131.153.161 16:05, 12. Okt. 2009 (CEST)
replies: text: Danke --Sebastian.Dietrich 09:45, 22. Dez. 2009 (CET)
thread_title:  Wikibooks-Link 

message: Mir ist gerade aufgefallen: im englischen Artikel steht als Erscheinungsjahr 1995, im deutschen 1996.
Ergebnis kurzer Suche:
On May 23, 1995, John Gage, director of the Science Office for Sun Microsystems, and Marc Andreessen, [...] announced to the SunWorldTM audience that JavaTM technology was real, it was official, [...]
http://java.sun.com/features/1998/05/birthday.html
1995: Java technology released to a select group on the Web site wicked.neato.org
* The San Jose Mercury News runs a front-page article about Java technology
* Name changed from "Oak" to "Java"
* Announced at Sun World -- Java technology is officially born
http://www.java.com/en/javahistory/timeline.jsp'
--Locked 08:50, 22. Dez. 2009 (CET)
replies: text: Das lag daran, dass die 1.0er Version erst im 96er Jahr rausgekommen ist. Nachdem die Sprache aber bereits 1995 offiziell vorgestellt wurde hab ichs inkl. Referenz geändert. --Sebastian.Dietrich 09:36, 22. Dez. 2009 (CET)
replies: text:  Dachte mir doch dass sich da jemand was dabei gedacht hat. Danke für dei Erklärung! --Locked 13:19, 22. Dez. 2009 (CET)
thread_title:  Erscheinungsjahr '95? 

message: Sollten die Artikel Java (Programmiersprache) und Java-Syntax nicht irgendwie verknüpft werden oder sogar zusammengefasst werden? Im erstgenannten gibt es auch einen Abschnitt zur Syntax aber keinen Link auf die Java-Syntax Seite und in der Begriffsklärung zu Java wird der Syntax-Artikel auch nicht erwähnt.
:Hi, beginne neue Themen bitte immer am Ende der Diskussionsseite und unterschreibe deine Diskussionsbeiträge mit „--~~~~“ damit die Diskussion nachvollziehbar bleibt.
:Der Link im Abschnitt Syntax war vorhanden aber ziemlich versteckt, ich habe ihn jetzt deutlicher hervorgehoben. Und Java-Syntax verweist direkt aus dem Einleitungssatz auf Java (Programmiersprache). Wie kann man das denn noch prominenter verlinken? Zusammenfassen halte ich aufgrund des Umfangs für eine schlechte Idee. --jpp ?! 14:56, 22. Jun. 2007 (CEST)
replies: text: Ist denke ich inzwischen ohnedies gut so. --Sebastian.Dietrich 12:53, 5. Jan. 2010 (CET)
thread_title:  Verwandte Artikel 

message: OSGi und JEE sind keine Frameworks, sondern Spezifikationen. JFreeChart und iText sind Bibliotheken. Und Jakarta-Projekt ist eine Ansammlung von Frameworks und Bibliotheken. Wäre es nicht sinnvoller, entsprechende Java-Frameworks als solche zu kategorisieren und lediglich besonders auf JEE ansprechen? (nicht signierter Beitrag von Slotties (Diskussion | Beiträge) 09:57, 31. Dez. 2009 (CET)
replies: text: Hab den gesamten Abschnitt "Siehe auch" aufgeräumt & nur auf die wichtigsten Punkte reduziert. --Sebastian.Dietrich 22:00, 11. Jan. 2010 (CET)
thread_title:  Framework Beispiele 

message: Ich halte das Entfernen des DMOZ-Links für einen strategischen Fehler, und zwar aus folgenden Gründen:
# Wir sagen immer, dass Wikipedia keine Linksammlung sei, was ja auch stimmt, und verweisen die Leute stattdessen zum Open Directory Project. Dann sollten wir nicht den Link darauf entfernen, weil wir uns damit unnötigen Diskussionsaufwand einfangen.
# Soo schlecht finde ich die dort versammelten Links gar nicht. Obwohl ich zugeben muss, dass es sich nicht um eine umfassende oder ausgeglichene Auswahl handelt.
--jpp ?! 13:39, 29. Okt. 2007 (CET)
thread_title:  Entfernung des DMOZ-Links 

message: Unter "Weblinks" sollte der folgende hinzugefügt werden:
"Java ist auch eine Insel" von Christian Ullenboom (12,3MB)
http://download.galileo-press.de/openbook/javainsel6/galileocomputing_javainsel6.zip
(nicht signierter Beitrag von Tcsp (Diskussion | Beiträge) 22:44, 31. Aug. 2007 (CEST)
replies: text: siehe nächsten Abschnitt --Sebastian.Dietrich 18:05, 23. Dez. 2009 (CET)
thread_title:  Gratis-eBook 

message: Gibt es die Möglichkeit verschiedene Beispiele anzugeben, was Java in einer Internetseite oder in einer Kaffemaschine machen kann? Das würde es irgendwie erleichtern zu verstehen. Kann jemand helfen?
(nicht signierter Beitrag von 212.18.9.14 (Diskussion) 14:39, 24. April 2007 (CEST)
replies: text: Naja Java ist eine Programmiersprache, mit der man (fast) alles machen kann. Von einem Egoshooter bis zu einem Anlagenbuchhaltungssystem. Siehe auch :Kategorie:Java-Programm --Sebastian.Dietrich 09:43, 22. Dez. 2009 (CET)
thread_title:  Beispiele 

message: Ich darf die Seite nicht bearbeiten, daher als Kommentar. Abschnitt "Unterschiede zu ähnlichen Sprachen", C++: "Sie ist daher nicht mit einem Dekonstruktor aus C++ vergleichbar." Ich habe noch nie jemanden "Dekonstruktor" sagen hören, das Ding heißt Destruktor. (nicht signierter Beitrag von 83.181.70.11 (Diskussion) 16:28, 22. Mai 2011 (CEST)
replies: text: da hast du wohl recht, danke. hab's geändert. -- ∂ 18:00, 22. Mai 2011 (CEST)
thread_title:  Dekonstruktor? 

message: : Java ist eine interpretierbare Sprache.
Dieser Satz stört mich. Vielleicht sollte man "interpretierte Sprache" schreiben oder klarstellen, was man damit eigentlich aussagen will. Dass das Zeugs in einer VM läuft? Und wer sollte mich daran hintern, einen C++-Interpreter zu schreiben? (Außer meine wenige Zeit) --188.194.78.254 21:55, 24. Jul. 2011 (CEST)
replies: text: in der angegebenen quelle wird's etwas deutlicher: durch einen bytecode-interpreter statt eines klassischen compilers wollten sie die turnaround-zeiten verkürzen - so jedenfalls verstehe ich das.  -- ∂ 03:43, 25. Jul. 2011 (CEST)
replies: text:  Ich habs jetzt versucht klarer zu stellen. In der Praxis gibts JVMs die nur interpretieren, zunächst interpretieren, dann compilieren oder nur compilieren. Es wird aber immer Bytecode interpretiert/compiliert und niemals Java Sourcecode. --Sebastian.Dietrich  ✉ 09:15, 25. Jul. 2011 (CEST)
replies: text: Nicht ganz, siehe . Somit gilt nicht nur der theoretische Einwand, dass jede Programmiersprache im Prinzip interpretierbar und kompilierbar ist, sondern auch der praktische, dass Java tatsächlich auch kompiliert wird (ohne Bytecode-Zwang), allerdings nicht im Rahmen der Java (Technik). Dass Designziel Java soll interpretierbar sein steht in den Quellen auch nicht explizit drin. Die erste Quelle bezieht "interpreted" auf "technology" bzw "java platform". Die zweite Quelle (Whitepaper von 1995) schreibt zwar, Java sei interpretiert, spricht dann aber später eher über die gute Interpretierbarkeit des Bytecodes. Seit 1995 ist etwas Zeit vergangen und die dort unverhohlen als Buzzword-Sammlung bezeichnete Buzzword-Sammlung könnte man einfach als Buzzword-Sammlung abstempeln. --Zahnradzacken 12:15, 25. Jul. 2011 (CEST)
thread_title:  Interpretierbar 

message: Der Artikel muss auf die Übernahme von Sun durch Oracle aktualisiert werden (nicht signierter Beitrag von Tigeryoshi (Diskussion | Beiträge) 14:52, 9. Feb. 2010 (CET)
replies: text: Recht hat er! (nicht signierter Beitrag von 195.50.137.186 (Diskussion | Beiträge) 07:21, 10. Aug. 2011 (CEST)
thread_title:  Aktualisierung auf die Übernahme durch Oracle 

message: Folgender Satz scheint falsch: 
Der Objektzugriff in Java ist über Referenzen implementiert, welche den aus C/C++ bekannten Zeigern ähneln.[10] Die Sprachdefinition (Java Language Specification) bezeichnet sie als „Reference Values“ um deutlich zu machen, dass sie als Call by value übergeben werden.
In Java werden aber nur die "nicht objektorientierten Grundtypen" als call by value übergeben (int, long, double, String,...).
Und call by value ist doch das Gegenteil von Call by reference. 
Daher ändere ein angemeldeter USer bitte das "call by value" auf "call by reference" 188.22.54.130 23:20, 10. Aug. 2011 (CEST)
replies: text: Es gibt kein Call by reference in Java. Vgl. z.B. ref-Parameter in C# als Kontrast. --Daniel5Ko 23:35, 10. Aug. 2011 (CEST)
replies: text: Siehe auch Diskussion:Java (Programmiersprache)/Archiv#Referenzen vs. Zeiger --Zahnradzacken 01:04, 11. Aug. 2011 (CEST)
thread_title:  Call by Value - Call by reference 

message: Als ich mir den Artikel eben durchlas, ist mir aufgefallen, dass dieser Abschnitt nicht besonders neutral klingt. SowohlJavas Klassenbibliothek bietet eine Reihe einfacher Möglichkeiten für Netzwerkkommunikation, von TCP/IP-Protokollen über Remote Method Invocation bis zu Webservices.als auchJava ist insbesondere auf Grund der dynamischen Optimierungen der Virtual Machine eine der effizientesten Programmiersprachen und liefert ähnliche Geschwindigkeiten wie C++- oder C#-Programme.undJava unterstützt Multithreading, also den parallelen Ablauf von eigenständigen Programmmabschnitten. Dazu bietet die Sprache selbst die Keywords synchronized und volatile – Konstrukte, die das „Monitor & Condition Variable Paradigma“ von C. A. R. Hoare unterstützen. Die Klassenbibliothek enthält weitere Unterstützungen für parallele Programmierung mit Threads. Moderne JVMs bilden einen Java-Thread auf Betriebssystem-Threads ab und profitieren somit von Prozessoren mit mehreren Rechenkernen.vertreten meiner Meinung nach nicht den neutralen Standpunkt. Vielleicht gibt es noch mehr in diesem Artikel, aber die finde ich am "schlimmsten". Was sagt ihr? --Elsensee 16:19, 28. Jun. 2011 (CEST)
replies: text: Beim letzten Zitat finde nichts auszusetzen. Die anderen kann man umformulieren, aber von der Aussage her stimmt es ja. --Euku:⇄ 22:41, 28. Jun. 2011 (CEST)
replies: text: Auf den Abschnitt Java_(Programmiersprache)#C.2B.2B trifft die Kritik ebenfalls zu. Dort sind die Formulierungen zwar nicht ganz so schlecht, aber ebenfalls teilweise nicht sachlich genug: Kann der Artikel kurz freigegeben werden? Sowas wie "Dies sorgt einerseits für eine Vereinfachung der Sprache an sich" ist reine Werbesprache, eine Formulierung ohne fassbaren Gehalt. -- 129.247.247.239 15:33, 1. Jul. 2011 (CEST)
thread_title:  Neutralität 

message: Teil vom Absatz ist Obsolet
"Programmiersprachen umsetzen. Im JDK Version 7, das derzeit etwa für Mitte 2011 erwartet wird,[14] " 
Das jdk ist am 28.07.2011 veröffentlicht worden.
http://openjdk.java.net/projects/jdk7/ 
Vorschlag: Im JDK Version 7, das am 28.07.2011 veröffntlicht wurde ... (nicht signierter Beitrag von 85.180.100.84 (Diskussion) 00:04, 10. Aug. 2011 (CEST)
replies: text: Done - allerdings stimmte der Satz so nicht ganz. Dynamische Sprachen wurden auch davor unterstützt, jetzt laufen sie halt viel schneller. --Sebastian.Dietrich  ✉ 10:16, 27. Okt. 2011 (CEST)
thread_title:  Absatz C# 

message: "In C# ist es ebenso wie in Java möglich, Ausnahmen (exceptions) zu einer Methode zu deklarieren. In Java können Ausnahmen so deklariert werden, dass sie auch verarbeitet werden müssen (checked exception)."
Der erste Satz stimmt nicht. C# kennt keine Exception-Deklarationen im Methodenkopf. Ich würde es ja korrigieren, aber dann käme wieder ein bescheuerter Admin und würde es rückgängig machen. Und weg... (nicht signierter Beitrag von 217.91.73.157 (Diskussion | Beiträge) 09:52, 27. Okt. 2011 (CEST)
replies: text: Dass Admins korrekte Infos rückgängig machen kommt extrem selten vor - Irren ist menschlich. Die hier angesprochene Änderung, vor allem wenn Du beim Speichern eine Referenz auf entsprechende Infos mitgibst, würde aber mit Garantie drinnen bleiben. Also machs ruhig --Sebastian.Dietrich  ✉ 10:16, 27. Okt. 2011 (CEST)
thread_title:  Falscher erster Satz 

message: Hier: 7.0.1
englishe wiki: Java Standard Edition 7 Update 1(1.7.1)
Was sit richtig??? (nicht signierter Beitrag von 93.232.55.153 (Diskussion) 14:01, 12. Nov. 2011 (CET)
replies: text: Das mit den Versionen ist so eine Sache. Es gibt eine "technische" Version (die mit "1." davor), und eine umgangssprachliche/marketingtechnische Version (die ohne "1.") davor. mMn ist alles korrekt - Java 7 Update 1, Java 1.7.1, Java 1.7 Update 1, ... --Sebastian.Dietrich  ✉ 16:55, 12. Nov. 2011 (CET)
replies: text:  nope, 1.7.0 update 1, nicht 1.7.1. -- ∂ 20:15, 12. Nov. 2011 (CET)
thread_title:  aktuelle Version 

message: -reflection
http://java.sun.com/developer/technicalArticles/ALT/Reflection/
Summary
Java reflection is useful because it supports dynamic retrieval of information about classes and data structures by name, and allows for their manipulation within an executing Java program. This feature is extremely powerful and has no equivalent in other conventional languages such as C, C++, Fortran, or Pascal. 
Es wird der Vorteil von reflection gegenüber C++ in keinem Wort erwähnt, sollte jedoch weil es ein gewichtiges Merkmal von Java ist. (nicht signierter Beitrag von 85.180.100.84 (Diskussion) 00:04, 10. Aug. 2011 (CEST)
thread_title:  Absatz C++ 

message: der Absatz Java_(Programmiersprache)#Java_als_freie_Software ist redundant zu Java_(Technologie)#Lizenz und OpenJDK#Geschichte - das sollte mMn nur in einem der Artikel stehen und nur darauf verlinkt werden... - der richtige Platz dafür wäre mMn bei OpenJDK --Sebastian.Dietrich 22:23, 4. Nov. 2009 (CET)
thread_title:  Redundanz mit [[Java (Technik)]] und [[OpenJDK]] 

message: === Smalltalk ===
Es sollte darauf eingegangen werden, dass Java von sich aus keine Messages unterstützt, was das wichtigste Sprachmittel von Smalltalk ist. Sonst entsteht der Eindruck, dass Java und Smalltalk sich sehr ähneln, obwohl deren Konzeptionen sich doch sehr stark unterscheiden. Smalltalk: dynamisch typisiert, Klassenobjekte (nicht verwechseln mit statischen Methoden), Messages, Blöcke.
Java: statisch und stark typisiert, nur statische Methoden (Klassen sind keine Objekte), keine Nachrichten nur "normale" Methodenaufrufe (Wobei man hier anmerken sollte, dass diese Eigenschaften Javas an der Grundidee von OOP vorbei gehen, siehe Ausführungen Alan Kay). --Karolherbst 09:47, 22. Sep. 2010 (CEST)
thread_title:  Unterschiede zu ähnlichen Sprachen 

message: Es sollte darauf eingegangen werden, dass Java von sich aus keine Messages unterstützt, was das wichtigste Sprachmittel von Smalltalk ist. Sonst entsteht der Eindruck, dass Java und Smalltalk sich sehr ähneln, obwohl deren Konzeptionen sich doch sehr stark unterscheiden. Smalltalk: dynamisch typisiert, Klassenobjekte (nicht verwechseln mit statischen Methoden), Messages, Blöcke.
Java: statisch und stark typisiert, nur statische Methoden (Klassen sind keine Objekte), keine Nachrichten nur "normale" Methodenaufrufe (Wobei man hier anmerken sollte, dass diese Eigenschaften Javas an der Grundidee von OOP vorbei gehen, siehe Ausführungen Alan Kay). --Karolherbst 09:47, 22. Sep. 2010 (CEST)
thread_title:  Smalltalk 

message: Seit XCode 3.2 gibt es im Prinzip keine Java Unterstützung mehr, da seit der 64-bit Implementierung von Cocoa die Java-ObjC Brdige nicht mehr weiterentwickelt wird, da diese auf Carbon aufbaut und es Carbon nicht als 64-bit Version geben wird (schon in XCode 3.1 merkte man die mangelnde Unterstüzung Javas). --Karolherbst 09:52, 22. Sep. 2010 (CEST)
thread_title:  Entwicklungsumgebungen 

message: Unter Literatur steht ein Link auf Roberta. Roberta ist aber kein Buch sondern ein Ausbildungskonzept. Sollte gestrichen werden. -- Signaturnachtrag: 134.106.56.253 am 1. November 2010 um 16:57; nachgetragen von --Zahnradzacken 18:46, 1. Nov. 2010 (CET)
thread_title:  Roberta 

message: Es sollte an geeigneter Stelle ein Verweis auf  Android (Betriebssystem) eingefügt werden. Schließlich wird dort java als Sprache (wenn auch nicht als bytecode) verwendet und Android hat doch eine sehr starke Bedeutung im Smartphone-Bereich -- 83.97.72.14 21:28, 29. Sep. 2011 (CEST)
thread_title:  Android