Diskussion:Java (Programmiersprache)/Archiv/1

aus Wikipedia, der freien Enzyklopädie
Dieses Diskussionsarchiv hat die empfohlene SeitengröVorlage:SSe erreicht und gilt damit als abgeschlossen. Sein Inhalt sollte nicht mehr verändert werden (ausgenommen Kleinbearbeitungen wie Link- und Vorlagenfixe). Verwende für die Archivierung von Diskussionsbeiträgen bitte das aktuelle Archiv und benutze bitte für aktuelle Diskussionen die aktuelle Diskussionsseite.
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/1#Abschnittsüberschrift]]
oder als Weblink zur Verlinkung auVorlage:SSerhalb der Wikipedia
https://de.wikiup.org/wiki/Diskussion:Java_(Programmiersprache)/Archiv/1#Abschnittsüberschrift

der ganz große Wurf wars noch nicht

Hab mal versucht etwas Struktur reinzubringen, der ganz grosse Wurf wars noch nicht, aber so macht der Artikel viel mehr her. Denke ich zumindest ;-) OliD 09:36, 20. Mai 2003 (CEST)

OliD, jetzt bist Du mir zuvor gekommen ;-) Hier noch meine Antworten vom vorherigen Abschnitt:

  • Primitivtypen machen der Objektorientiertheit von Java keinen Abbruch, ganz im Gegenteil, wer will schon zwei Objekte erzeugen und damit Speicher verbraten, um beispielsweise nur zwei Zahlen zu addieren. Ob sich "reine" Objektorientierung wirklich dadurch qualifiziert, dass Primitivtypen fehlen, ist fraglich. Mit Java kannst Du auf jeden Fall auch ohne Primtivtypen, "rein" mit Objekten programmieren, wenn Du das für besser hältst.
  • Bzgl. der Primitivtypen besteht übrigens kein Problem mit der Portabilität wie Du angenommen hast, da bei jeder Java VM, die der Java-Spezifikation entspricht (und da ist das Betriebssystem als auch die Plattform völlig egal), alle Primitivtypen die gleiche Datenmenge umfassen und auch in der gleichen Weise gespeichert werden. Plattformübergreifend gesehen, sind beispielsweise die Primitivtypen in C++ ein Problem, da hier Big- und Little Endian eine Rolle spielt und auch z. B. der Type "int" unterschiedliche Länge haben kann.
Zu C++: In der Praxis ist die unterschiedliche Länge nur in pathologischen Fällen ein Problem. Viel problematischer wäre es, wenn die Länge immer gleich wäre, denn das ginge auf Kosten der Geschwindigkeit. Dass Big Endian/Little Endian eine Rolle spielen, ist noch viel seltener der Fall.
Wie kommst Du darauf, dass die unterschiedliche Länge nur in pathologischen Fällen ein Problem darstellt? Ich hatte dieses Problem schon sehr konkret... Sobald man versucht plattformübergreifend in C++ zu programmieren ist das Problem nicht nur pathologisch sondern real existierend. --Herr Schroeder 22:13, 4. Jan 2005 (CET)
Ich weiß zwar nicht, warum etwas Pathologisches nicht real existierend sein soll, aber sei's drum ... Beispiel:
int a = 3;
int b = 4;
int x = a + b;
Dabei kommt das selbe Ergebnis heraus, und zwar unabhängig davon, ob int 16, 32 oder 64 Bit hat ... und das gilt für die erdrückende Mehrheit aller Fälle aus dem realen Leben.
  • Ja, die JIT sollte von der "Programmiersprache Java" getrennt werden. Erwähnen sollten wir sie trotzdem, da sie wichtiger Bestandteil heutiger Java VMs ist. Auch auf andere Performance Pusher wie Hotspot sollte hingewiesen werden.
  • Auf der Java VM kann natürlich theoretisch auch Bytecode ausgeführt werden, der auch von anderen Compilern erzeugt wurde, solange diese Compiler sich 100%ig an die Java-Spezifikation halten.
  • Dass Applets auf dem Rückzug sind, kann ich nicht bestätigen. Ledichlich die Menge der auf Java 1.1 basierten Applets wächst nach meinem Gefühl nicht mehr. Die auf Java 2 basierenden Applets jedoch, erreichen mitunter Profi-Qualitäten, siehe z. B. http://java.sun.com/products/jfc/tsc/sightings/S15.html
  • Auf C# können wir hinweisen.

Ich schau mir Deine Änderungen später an jonelo 12:37, 20. Mai 2003 (CEST)

kundig gemacht

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) Ein paar Links: http://java.sun.com/people/jag/green/index.html http://java.sun.com/people/jag/ http://java.sun.com/people/jag/OriginalJavaWhitepaper.pdf http://java.sun.com/people/jag/SimulaHistory.html http://java.sun.com/people/jag/Presentations/TheStoryOfJava/img0.htm


OliD,

  • auch die Byte-Order ist in der Java VM Spec festgelegt, d. h. auch Bitoperationen auf Primitiven sind in Java plattformunabhängig. Siehe Punkt 3.11,

"If an operand is more than one byte in size, then it is stored in big-endian order-high-order byte first." http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html#7143

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)

moven

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)
  • J2ME und J2EE sind zwei große Brocken, puh... (das leg ich erstmal auf Eis, bis ich wieder mehr Zeit habe) Vielleicht hat ja jemand anderes Lust dazu?

jonelo 21:22, 22. Mai 2003 (CEST)

Links

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)

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)

1.5.0 wird 5.0 heißen

war schonmal drin im artikel, aber ich bin mir nicht sicher wie offiziell der versionsnummernstrip schon ist. es heißt jedenfalls das 1. vorne würde in zukunft rausfliegen - ist ja auch sinnvoll, wenn man bedenkt in welchen abständen und mit welchen fortschritten die neuen versionen daher kommen. die 1.x.y_0z versionierung wurde langsam ein wenig unübersichtlich - und auch 1.2 wurde ja schon als java 2 verkauft. auf die dauer müsste man das mal einarbeiten -- D 03:09, 25. Jul 2004 (CEST)

Laut folgendem Artikel heisst es immer noch J2SE (Java 2 Platform, Standard Edition), nur die Versionsnummer der J2SE macht einen heftigen Sprung und zählt nun bei 5.0 weiter. Siehe http://java.sun.com/javaone/tech_sessions1.html
"... If you're wondering why Tiger is J2SE "5.0" instead of the traditional J2SE "1.x", Hamilton noted that "because J2SE 5.0 is our biggest update to the platform since the original 1.0, it felt kind of stupid that we were still calling things 1.1, 1.2, ... And with a big roaring Tiger, we wanted to change the numbering system, so we're now going to use the 5.0 number for J2SE, and similarly Java 2 Platform, Enterprise Edition (J2EE) is going to move to 5.0. Future releases will be 6.0 and 7.0."
Jonelo 19:12, 26. Jul 2004 (CEST)

Modulare Ausführung auf fernen Computern

Dort wird auf verschiedene Teilbereiche von Java referenziert (Applet, Servlet, MIDlet, etc). Nur die beiden Bereiche Doclet und Translet sind noch leer.

Ich vermute, dass dieses nicht durch Zufall so ist. Ein Doclet dient zur Aufbereitung der Dokumentation und ist fast ein Teil des Compilers.

Von einem Translet habe ich bislang noch nichts gehört.

Ich bin daher der Meinung, dass diese beiden Punkte gelöscht werden können.

--Herr Schroeder 11:48, 27. Jul 2004 (CEST)

Weil ich der Meinung bin, dass die beiden Punkte (Doclets und Translets) nicht gelöscht werden sollen, möchte ich hier widersprechen ;-) Ich habe auch endlich mal Zeit gefunden, mal schnell zwei Artikel zu Doclets und Translets zu schreiben.--ChristianHujer 15:05, 23. Aug 2004 (CEST)
Trotzdem bin ich der Meinung, dass die beiden Punkte (Doclets und Translets) nicht unter den Punkt "Modulare Ausführung auf fernen Computern" gehört. Beide (den Begriff Translet in diesem Zusammenhang höre ich trotzdem das erste mal) sind nicht dafür geschaffen auf einem entfernten Computer ausgeführt zu werden. Wir sollten nochmals überlegen wo diese sonst hingehören. --Herr Schroeder 18:25, 23. Aug 2004 (CEST)
Um Module handelt es sich bei allen, nur mit der "Ausführung auf fernen Computern" hapert es bei dem einen oder anderen Eintrag in diese Liste. Vielleicht sollte man eine Zwischenüberschrift "Java-basierte Komponententechnologien" einfügen und dann auch noch die JavaBeans (ohne Enterprise), JSPs und TagLibs in die Liste aufnehmen?
Das wäre zum Bleistift eine Möglichkeit... Wobei ich dann wieder mit den JSPs meine Probleme hätte, da dieses keine Komponenten im eigentlichen Sinne sind.
Hmmm... wenn Servlets Komponenten sind, dann sind es imho auch JSPs. Aus jeder JSP wird mit Hilfe des JSP-Compilers erstmal ein Servlet. Für JSP-Unterstützung braucht man einen JSP-Compiler, einen Servlet-Container und einen Mechanismus, der Zugriffe auf JSPs so erkennt, dass der JSP-Compiler, sofern nicht bereits geschehen, und das entstandene Servlet ausgeführt werden. --ChristianHujer 21:38, 3. Sep 2004 (CEST)

Ich habe heute wieder einen Link auf ein sogenanntes "Tutorial" entfernt. Dieser Link wurde schon einmal von Dnaber entfernt. Ich hoffe, dass der anonyme Editor nicht wieder anfängt das Tutorial wieder hier einzutragen, da der Link in meinen Augen nur Werbung (für Java-Kurse) enthält jedoch keine neutralen Informationen. Aus meiner Sicht ist bei dem Inhalt dieses Links die Grundsätze der neutralen Sichtweise nicht gegeben.

Über die Versionen kann ein jeder den Link finden und sich die dort gebotenen "Informationen" anschauen.

Wenn der Link wieder erscheint, so werde ich ihn wieder löschen und anschließend den Administratoren Bescheid geben, dass sich an dieser Stelle ein Edit-War anbahnt.

--Herr Schroeder 10:54, 11. Aug 2004 (CEST)

Liste der reservierten Wörter

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)

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)

Syntax: Standard-Signatur für main ist "public static void main(final String... args)"

Jemand hat die Signatur der Main-Methode im Hello World-Beispiel auf die alte Syntax geändert. Dazu ist folgendes zu sagen:

  • Es gehört zum guten Stil in Java, Parametervariablen grundsätzlich als final zu deklarieren, um fehlerhafte Variablenzuweisungen zu verhindern.
  • Seit 5.0 schreibt man in aller Regel immer vararg-Listen, weil ein Aufruf dann ohne explizites Array möglich ist.

Ich will aber keinen Edit-War vom Zaun brechen. Hat nochjemand eine Meinung zu dem Thema?

Wer behauptet, das wäre die neue Standard-Signatur? Erstmal ist Java 1.5 noch nicht fertig, auch wenn es nicht mehr lange dauern soll. Weiterhin wird es auch dann noch eine Weile dauern, bis sich die Programmierer auf diese neue Signatur umstellen, wenn überhaupt. -- Dishayloo [ +] 23:30, 16. Sep 2004 (CEST)
Darüber, ob die Deklaration sämtlicher Methodenparameter als final guter Stil ist oder nicht, besteht kein Konsens in der Entwicklergemeinde. Zwar gilt die Regel, niemals einem Parameter etwas zuzuweisen, wohl ohne Diskussion. Andererseits macht die gehäufte Verwendung von final den Code schnell unübersichtlich. Mit dem Einsatz von Style-Checkern lässt sich das Problem auch lösen, ohne den Code zu "verunreinigen". (Natürlich wäre es schöner, wenn die Sprachdefinition final als Default für Parameter vorsehen würde - ist aber leider nicht so.) Jpp 08:42, 17. Sep 2004 (CEST)
Stack ist teuer. Was für eine Verschwendung wäre es, wenn Parameter grundsätzlich final sind? Es ist schlechter Stil, wenn man anfängt, überall Parameter weiterzuverwenden, aber gerade in kleinen, überschaubaren und evtl oftmals/rekursiv aufgerufenen Methoden, die z.B. als Rückgabe den gleichen Typ haben, wie ein Parameter, da kann man diesen Paramter verändern und den dann zurückgeben. Oder ein Parameter wird auf null kontrolliert und ggf vor der Weiterverwendung mit einer neuen Referenz bestückt. --Messi 07:41, 27. Okt 2004 (CEST)
Das gilt wohl für Anwendungen, bei denen der Speicherplatz die kritische Ressource ist. In meinem Umfeld sind aber eher die Entwickler die kritische Ressource. Mit anderen Worten: Klarer, wartbarer Code ist wesentlich wichtiger als Optimierung von Speicher um jeden Preis. Meistens spart aber das eleganteste Design auch die meisten Ressourcen. "Fitzeln" zur Optimierung bringt m.E. nur wenig. --Jpp 22:30, 17. Jan 2005 (CET)
Ergänzend sei noch angemerkt, daß ein Java-Compiler ohne Probleme mehrere lokale Variablen auf ein und dieselbe lokale Variable in einem Stackframe legen kann, wenn ihre Benutzung sich nicht überschneidet. Eine Parametervariable zu recyclen, um Stack zu sparen, ist somit sinnlos. Allerdings gibt es trotzdem keinen Standard, der Parameter auf final festlegt. Konstruktionen wie "if(args.length==0) args=DEFAULT_ARGS;" oder der schon erwähnte NULL-check können durchaus als sauber angesehen werden. Mehrere Variablen für denselben Zweck würden an der Stelle die Lesbarkeit nicht erhöhen.

Links auf fehlerhafte Tutorials und Einführungen?

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)

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)
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)

Duke nervt!

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)

me too! -- D. Düsentrieb ⇌ 01:24, 6. Okt 2004 (CEST)
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)
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)

Diskussion aus dem Review

Bilder werden hier schwierig, die in dem englischen Artikel basieren alle auf 'Fair Use'. Was meint ihr? -- Dishayloo [ +] 21:20, 12. Sep 2004 (CEST)

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)
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)

Hab's mal durchgesehen. Hier ein paar Anmerkungen, vielleicht helfen die:

  • Hmm. Ich dachte, Hotspot war schon bei 1.3 drin... Bin mir aber nicht sicher.
  • Ort und Zeit: 4 Uhr morgens in einem Hotelzimmer des Sheraton Palace Hotels in der Nähe des Convention Centers. Klingt irgendwie mehr nach Kriminalroman, als nach Enzyklopädie...
  • Grundkonzepte der Sprache: Sammelliste stimmt nicht mit anschließenden Zeilen überein. Zudem unvollständig: "Java soll eine einfache, objektorientierte, verteilte, interpretierte, robuste, sichere, architekturunabhängige, portable, performante, nebenläufige, synamische Programmiersprache sein." (aus GoTo Java 2 von Guido Krüger) Sicherheit betrifft nicht nur das Ausführen auf anderen Rechnern, sondern auch die Vermeidung von Fehlern (unintialisierte Variablen etc.)
  • "(siehe auch Kapitel weiter unten)" klingt komisch. Ich würde hier auch nicht von Kapiteln, sondern eher von Absätzen oder sowas sprechen, aber vielleicht bin ich Wikibooks-geschädigt.
  • "unter anderem durch private und public" da gibt's doch ein Wort für, für die Dinger... (fällt mir grad aber auch nicht ein) ah da isses ja: Zugriffsmodifizierer
  • Grundkonzepte und Merkmale der Sprache überschneiden sich ein wenig.
  • Was noch fehlt: Was zum Streitthema: Ist Java langsamer als andere Sprachen?--Berni 23:27, 19. Sep 2004 (CEST)

Destructor - Abschnitt wieder entfernt

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)

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)

MF: Ja, es gibt die finalize()-Methoden. Diese sind aber (leider) nicht dafür geeigenet, um eine Resourcenverwaltung zu implementieren. Es ist laut Java-Spezifikation nicht definiert, wann genau (und ob überhaupt) finalize()-Aufrufe erfolgen. Dies ist eine Sache der jeweiligen speziellen Java-Runtimeumgebung, und kann in einigen Fällen sogar über Optionen gesteuert werden. Eine delete-Statement würde, wie Uli bereits schreibt, funktional gesehen den Close()-Aufrufen entsprechen. Ein Destruktor, wie ihn C++ bietet, hat dagegen den Vorteil, daß er _sofort_ aufgerufen wird, sobald ein Objekt den momentanen Gültigkeitsbereich verläßt. Auf diese Weise können die damit verknüpften Resourcen geregelt freigegeben werden. Wenn man versuchen würde, dies innerhalb von finalize()-Methoden durchzuführen, hätte man das Problem, dass beispielsweise Dateien viel zu spät geschlossen werden würden - eine Wiederverwendung im nachfolgenden Programmablauf könnte Probleme bekommen. Man denke z.B. daran, dass ein Close()-Aufruf auch dafür zuständig ist, Pufferinhalte über flush() endgültig in die Datei zu schreiben. Ein folgendes (lesendes) Öffnen der Datei ohne erfolgten Close()-Aufruf würde noch den alten Dateiinhalt sehen, ohne die gepufferten Änderungen. Im diese Probleme also zu vermeiden, ist derzeit jeder Java-Programmierer gezwungen, Konstrukte der folgenden Art zu verwenden: 

Java_function()
{
 Stream s = ...

 try {
  ... Beschreiben der Datei ...
 } finally {
  s.Close();
  s = null;
 }
}

Wohingegen das Beispiel in C++ um Einiges einfacher ausfällt: 

CPP_function()
{
 ofstream s("file.txt");

 ... Beschreiben der Datei ...

} // <- Hier wird automatisch der Destruktor aufgerufen,
  // der Dateipuffer geschrieben, sowie der reservierte Speicher freigegeben.

-- Martin Fuchs 20:12, 10. Okt 2004 (CEST)

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)

Zum "reich und berühmt werden": Schau Dir vielleicht einmal den C++-Dialekt C-Plusplus/CLI an. Dieser bietet sowohl Garbage Collection als auch automatische Variablen. Ich muß allerdings zugeben, dass ich selbst noch keine praktische Erfahrung mit dieser Sprache habe. Sie ist ja auch noch recht neu. :) -- Martin Fuchs 20:38, 10. Okt 2004 (CEST)

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)
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)

Fehlen eines Destruktors sollte auf jeden Fall wieder aufgenommen werden im Rahmen der Abgrenzung zu C++. finalize() ist kein Ersatz, wie der eine oder andere hier schon richtig angemerkt hat. --Michael Hüttermann 23:42, 19. Feb 2006 (CET)

Javac/Jikes: Interpreter / Just-in-Time-Compiler?

Zitate:

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)

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)

Ich habe es gestern geändert... Es sollte jetzt richtig sein --Herr Schroeder 11:53, 28. Okt 2004 (CEST)

Diverses zu Datentypen und Schlüsselwörtern

  • 4.1 Grunddatentypen
    • In der Tabelle steht als Beschreibung immer „Zweierkomplement mit Vorzeichen“. Aber „mit Vorzeichen“ ist redundant. Im Übrigen wäre es besser, im Text über der Tabelle dieses als Besonderheit von Java zu erwähnen. Also, daß Java außer char nur Ganzzahl-Typen im Zweierkomplement hat und keine vorzeichenlosen Varianten.
    • Die 1-Bit-Angabe bei boolean macht keinen Sinn. Intern wird boolean eh in int übersetzt.
    • Die sogenannten „Wrapper-Klassen“ sind mehr als nur Einwickler für primitive Typen. Sie bieten diverse Methoden, um zusätzlich mit den primitiven besser arbeiten zu können. Und daß die Verwendung von Objekten „inperformanter“ ist, ist klar. Der Satz kann eigentlich raus. Der Verwendungszweck ist einfach zu unterschiedlich.
    • In diesem Kontext sollte auch erwähnt werden, daß viele Klassen aus java.lang unveränderlich sind. Vielleicht gehört das auch zu den "3. Merkmale...", wenn es um Referenzen geht.
  • 4.2 Reservierte Wörter
    • Die Tabelle enthält eine Zeile für "default". Evtl wäre es besser, wenn das Wort anders geschrieben oder eine deutsche Übersetzung genommen wird. "default" ist ja kein Schlüsselwort. Vielleicht „(ohne)“ oder so.
    • abstract, final und static hat mit Polymorphie nichts zu tun. Java hat keine Polymorphie-Modifizierer. In Java sind alle Objekt-Methoden virtuell. Und "static" paßt sowieso nicht zu den anderen beiden.
    • Erwähnenswert wäre noch, daß finally immer aufgerufen wird.
    • Mit this() werden nicht die überladenen Konstruktoren aufgerufen, sondern andere der gleichen Klasse. Die überladenen kann man mit super() aufrufen.
    • Es gibt keine Membernamenskonflikte. Aber mit der Verwendung von this kann man Eigenschaften erreichen, die evtl von Parametern verdeckt werden.
    • new reserviert nicht nur Speicher, sondern füllt diesen mit einem Objekt auf dem Heap und der entsprechende Kontruktor wird aufgerufen. Ich meine, daß die JVM sogar Objekte "recycle"t. Erwähnenswert?
    • Der ganze Abschnitt könnte in Unterabschnitte (4.2.x) für die Schlüsselwörtergruppen aufgeteilt werden.

Was sagt ihr? --Messi 08:00, 27. Okt 2004 (CEST)

  • 4.1 Grunddatentypen
    • „Zweierkomplement mit Vorzeichen“ -> Hier stimme ich Dir zu.
    • 1-Bit-Angabe bei boolean -> Die Angabe bezieht sich IMHO auf den Informationsinhalt, und ist damit völlig korrekt.
Ich bin mir nicht sicher, ob es "völlig" korrekt ist, da boolean alternativ ja keinen Wertebereich 0..1 akzeptiert. Es ist ja als zwei nicht-numerische Zustände definiert: wahr und falsch. Ich wollte aber vielmehr auf die Gefahr hinweisen, daß die 1-Bit-Angabe als Speichergröße mißverstanden werden kann. --Messi
    • „Wrapper-Klassen“ ... sind mehr als nur Einwickler für primitive Typen. -> Ja. Was schlägst Du genau vor, im Artikel hierzu zu schreiben?
Kann wohl doch so stehenbleiben, weil im Javadoc auch vom Wrappern die Rede ist. --Messi

...Und daß die Verwendung von Objekten „inperformanter“ ist, ist klar. Der Satz kann eigentlich raus. Der Verwendungszweck ist einfach zu unterschiedlich. -> Dies sehe ich auch so, diese Anmerkung ist überflüssig.

Vielleicht ist hier ein Beispiel sinnvoll, wann die Objekte benutzt werden. --Messi
  • 4.2 Reservierte Wörter
    • ..."default". Evtl wäre es besser, wenn das Wort anders geschrieben oder eine deutsche Übersetzung genommen wird. -> Ein anderer Begriff für die Defaultzugriffsmethode, den man gelegentlich hört, ist auch der "Package-Zugriff".
Aber der Begriff Paketzugriff soll ja anhand der Tabelle erklärt werden. Zurzeit sieht es so aus, als wäre "default" ein reserviertes Wort. (Ich finde es übrigens schrecklich, wenn eine Programmiersprache anhand ihrer reservierten Wörter bzw. Schlüsselwörter beschrieben wird.) --Messi
    • Es gibt keine Membernamenskonflikte. Aber mit der Verwendung von this kann man Eigenschaften erreichen, die evtl von Parametern verdeckt werden. -> Ja, von Parametern und von lokal definierten Variablen.
Ja, genau. Von lokal-definierten Variablen. Ist besser. Parameter sind in Java nichts anderes. --Messi
    • new reserviert nicht nur Speicher, sondern füllt diesen mit einem Objekt auf dem Heap und der entsprechende Kontruktor wird aufgerufen. -> Mhh, der new-Operator an sich reserviert eigentlich wirklich nur den Speicher. Der Aufruf des Konstruktors wird durch die folgenden Klammern (mit evenetuellen Parametern) veranlasst.
Ja, schwierig. Ist wohl besser, wenn new einfach als Operator zum Instanziieren bzw. zum Erstellen eines Exemplars oder Feldes beschrieben wird. Keine Interna, wie Speicherreservierung usw. --Messi 13:11, 2. Nov 2004 (CET)

-- Martin Fuchs 22:43, 1. Nov 2004 (CET)

Zu 1-Bit-Angabe bei boolean: Afaik: Logisch gesehen braucht boolean 1 bit, in einem Array braucht boolean 8 bit, als Register braucht boolean 32 bit, serialisiert braucht boolean 8 bit, auf dem heap braucht boolean 8 bit. So ausführlich wollt's aber wohl keiner hinschreiben.
"Zweierkomplement mit Vorzeichen" ist redundant, erinnert die Programmierer, die nicht wissen, was Zweierkomplement ist, aber daran, dass es mit Vorzeichen bedeutet, ich würde die Redundanz lassen.
Zu Reservierte Wörter: default ist reserviertes Wort (switch case default).
Zu abstract, static, final: In Java bezeichnet man Modifizierer als Polymorphie-Modifizierer, wenn Sie die Möglichkeiten der Polymorphie bezüglich eines Members beeinflussen. Der Modifizierer abstract erzwingt Polymorphie dahingehend, dass abstrakte Member noch keine Ausgestaltung mitbringen und diese von den verschiedenen Subklassen erzwungen wird (oder sie müssen wieder abstrakt sein). final verbietet Polymorphie dadurch, dass es verboten ist, den Member zu überschreiben. Static beeinflusst die Polymorphie dahingehend, dass das Symbol bereits vom Compiler "gelinkt" wird, nicht zur Laufzeit, was die Symbolauflösung auf die deklarierte Klasse beschränkt, womit ebenfalls kein Polymorphismus stattfindet.
Zu this() Ein Konstruktor in der selben Klasse mit anderer Parametertypenliste ist ein überladener Konstruktor. Ein Konstruktor aus der Superklasse ist weder ein überladener noch ein überschriebener Konstruktor. Konstruktoren werden nicht vererbt und können daher auch nicht überschrieben werden. Überladen und Überschreiben bitte nicht verwechseln.
new reserviert wirklich nur den Speicher und löscht ihn. Das füllen mit dem Objekt erledigen die durch die Konstruktoren automatisch aufgerufenen Instanz-Initialisierer.
Natürlich gibt es Membernamenskonflikte:
class X {
   int x;
   class Y {
       int x;
        void method() {
            x = X.this.x;
        }
    }
}
Schonmal gesehen?
Ja, nicht-statische innere/eingeschlossene Klasse. Y.x verdeckt X.x. Das ist aber kein Konflikt, denn beide sind erreichbar und sie schließen sich nicht gegenseitig aus. Oder habe ich etwas übersehen? --Messi
Okay, Konflikt ist etwas zu drastisch in der Formulierung. Auf der Suche nach einem Eintrag in der JLS wird man aber im Index unter conflict fündig und erhält den gewünschten Hinweis auf Hiding. --ChristianHujer 18:29, 3. Nov 2004 (CET)
Die 5.0 VM wird sich unter Umständen in optimierten Implementierungen Mühe geben, Objekte zu recyclen, zumindest was die Wrapper-Klassen anbelangt. Ansonsten wäre mir ein Objektrecycling völlig neu, imho durch vernünftige Speicherverwaltung auch völlig überflüssig.

--80.140.172.124

Java_(Programmiersprache), 8. November

Die in der WP am besten beschriebene Programmiersprache, hat im Review große Fortschritte gemacht, wurde aber bisher noch nicht hier vorgeschlagen. Darum tue ich das hiermit. Zum Vergleich: Python_(Programmiersprache) ist bereits exzellent. -- Kurt seebauer 18:29, 8. Nov 2004 (CET)

abwartend Vielleicht noch ein paar Codebeispiele mehr?
pro --Kurt seebauer 18:29, 8. Nov 2004 (CET)
pro genau das muß in eine Enzyklopädie rein! --Zahnstein 22:51, 8. Nov 2004 (CET)
pro auch wenn mich der Satz etwas stört: Heutzutage wird Java hingegen hauptsächlich zur Entwicklung von Webanwendungen eingesetzt, wohingegen Java-Applets eine untergeordnete Rolle spielen... -- da didi | Diskussion 23:13, 8. Nov 2004 (CET)
abwartend ich weiss nicht genau woran es liegt aber ich kann mich mit dem Artikel nicht anfreunden. Ich versuchs aber mal:
  • Zweiter Satz "Java-Programme laufen üblicherweise auf einer Java Virtual Machine, das heißt einer virtuellen Maschine, die die konkreten Details von Hardware und Betriebssystem für das Programm verbirgt." 1. überhaupt nicht Oma-tauglich ;-), meine mE also nicht verständlich für interessierte Laien. 2. Inhaltlich würde ich mich dem Satz auch nicht ganz übereinstimmen, in Virtuelle Maschine stehts etwas anders drin.
  • Im Abschnitt Geschichte steht "Die Urversion von Java, auch Oak genannt," mmh mE wird die Sprache nicht mehr Oak genannt. Außerdem wird im gesamten Abschnitt nicht klar ob die beiden nebeneinander existierten oder der Name Java später gewählt wurde. Wenn zweiteres, dann steht nicht wann der Name Java offziell wurde. Weiter "Im März 1995 wurde die erste Alphaversion (1.0a2) des Java-Quellcodes für die Öffentlichkeit freigegeben und die Downloadzahlen explodierten." Zahlen und präzise Angaben wären mir hier lieber.
  • "dass die gebräuchlichen Browser mit veralteten Versionen der Laufzeitumgebung ausgeliefert werden." stimmt so nicht, der IE wurde sicher mit dem Uralt-MS-Java ausgeliefert. Opera und die ganze Mozilla-Familie noch nie mit alten, sollte präzisiert werden.
  • "Version 1.0 enthielt noch eine überschaubare Menge von Standardpaketen" keine Erklärung was ist ein Standardpaket, keine Erklärung, dass Java eine der wenigen Sprachen ist die von Anfang mit einer für die grundlegendsten Programmieraufgaben ausreichenden kostenlosen Bibliothek, genauer API, ausgeliefert wurde und wird. Das war mE mit ein Grund für die rasante Verbreitung der Sprache. Bitte jetzt keine Vergleiche mit Delphi und den MS-Produkten da legt man für ähnliche Basisbibliotheken viel Geld hin.
Ich denke das sollte erst mal reichen. Viele ähnliche Sachen, vorausgesetzten Wissen, inkonsistente Benennungen (Standardpakete <-> Standardbibliothek), "der ... geplante JSR 203 wurde auf Java 1.6 verschoben", "objektorientiert aufgebaut"??? etc. findet sich immer wieder. Als Neuling in Java hätte ich die wichtigen Unterschiede zu anderen Sprachen kaum rausbekommen. Gruss --finanzer 23:53, 8. Nov 2004 (CET)
  • abwartend mir fehlen Abbildungen. Wie wären Bildschirmfotos und Logos, vielleicht vom Originalkaffee, nachdem es benannt ist? Stern !? 00:59, 9. Nov 2004 (CET)
Die Abbildungen sind aufgrund von Rechteproblemen wieder rausgeflogen. -- Dishayloo [ +] 09:46, 9. Nov 2004 (CET)
  • abwartend Die Bilderwünsche können so nicht erfüllt werden, denn sowohl das Java-Maskottchen als auch der Kaffee sind wohl markenrechtlich geschützt und damit nicht gemeinfrei zu haben. Zum Artikel ich finde Finanzers Kritik angebracht. Für einen erfahrenen Programmierer scheint der Artikel mit Sicherheit exzellent, aber für die angesprochene Oma, oder auch nur einen durchschnittlichen Computer Nutzer wird wahrscheinlich vieles rätselhaft bleiben; zum Beispiel auch das Konzept der Internen Klassen. Solche Info muß a) erklärt werden oder b) wegelassen. Wobei b) natürlich nicht unserem Standard hier entspräche. ;-) --chris (nachgetragen) 15:19, 10. Nov 2004 (CET)
  • contra Vielleicht gut für eine Computerzeitschrift, aber für eine Enzyklopädie zu wenig erklärend, zu wenig von Grund auf bzw. für Laien verständlich. --WHell 11:35, 9. Nov 2004 (CET)
  • contra Mir gefällt nicht, daß die Syntax durch Aufzählung der Schlüsselwörter beschrieben wird. const und goto sollten ans Ende. Einige Merkmale der Sprache sind eigentlich Merkmale der Plattform. Alle Java-Klassen liegen in einer eigenen Datei/classfile. Allgemein sollte die Sprache und die Plattform getrennt unter Java Technologie eingegliedert werden. Die wichtigsten Datentypen werden nicht beschrieben: Referenztypen (Objekt u. Feld). Der Abschnitt Abgrenzung zu anderen Sprachen wäre besser als Unterschiede zu ähnlichen Sprachen beschrieben. Bei abstract, final und static muß deutlich werden, daß es sich um statische Polymorphie-Modifizierer handelt. (Wobei ich persönlich glaube, daß es soetwas nicht gibt.) Die Einleitung ist recht kurz. Ansonsten fehlt noch ein größeres Beispielprogramm mit Syntaxhervorhebung (Schlüsselwörter fett) und ein paar (Javadoc-)Kommentaren, damit auch unsere Oma schnell sieht, was gemeint ist. --Messi 13:41, 9. Nov 2004 (CET)
  • contra: Zu viele Listen und Aufzaehlungen. --zeno 14:41, 9. Nov 2004 (CET)
  • contra: Schon der zweite Satz ist zu schwammig. Als VOrteil muss nur der C-Compiler an verschiedene Computer angepasst werden, schon laufen die C-Programme gilt für alle (!) Sprachen. Ist das wirklich da schon erwähnenswert und der Hauptvorteil? Der anschliessende Geschichte-Teil liest sich für mich wie aus einer mittelmäßigen Computerzeitschrift, viel zu wenig Konkretes, viel Überflüssiges (Maskottchen, unauffälliges Bürogebäude, na ja?!). Abschnitt Versionen: Gleich mit Details zu Klassen und Pakete, ohne dass ein einziges Wörtchen über Klassen und Pakete in der Sprache ein Wort verloren wurde. Aber dafür gleich noch Applets und Callback-System hinterhergeworfen. Und dann folgen viele meist unerklärte TLAs (die in der Computerei so beliebten "Three Letter Acronyms") - RMI, JAR, JDBC, JDK, API, JCP, JSR, J2SE, angereichert mit Hotspot-Optimierung, Generics, Metadaten, Look and Feel da bin selbst ich verwirrt, ähem erschlagen. Wer sich bis hierher durchgeschlagen hat, erfährt endlich etwas über die Sprache selbst - immer heisst der Artikel Java (Programmiersprache). Der Grundkonzepte-Teil ist wesentlich besser als alles vorherige! Doch dann, unter Syntax: Ein Beispiel, dann relativ ausführlich Datentypen, dann Reservierte Wörter. Das ist doch nicht die Syntax der Sprache, die hier beschrieben wird. Von Syntax keine Spur, kann ich mir dann aus dem Beispiel zusammenreimen. Na ja, da es if,else usw. gibt, kann der Eingeweihte das wohl noch, aber das ist nicht die Zielgruppe. Unterschiede zu ähnlichen Sprachen: relativ brauchbar, danach nur noch lose zum Thema gehörende Extras mit einer langen API-Liste. --Hubi 15:49, 10. Nov 2004 (CET)
  • contra: Dieser Artikel hat meiner Meinung nach noch keine enzyklopädische Eignung. Es ist noch zu techniklastig und zu "geek-haft" geschrieben. Der Artikel sollte auch aufgeteilt werden (ich weiß nur nicht wie ;), da derzeit versucht wird die gesamte Welt in einem Artikel zu erklären. Vielleicht wäre es denkbar den Artikel in drei Teile (anfangs) aufzuteilen: Sprache, VM, Bibliotheken.--Herr Schroeder 19:12, 24. Nov 2004 (CET)
  • contra für laien leider zu 80% vollkommen unverständlich, ansonsten hat Hubi das schon viel besser gesagt als ich es mangels fachkenntnis könnte. -- southpark 01:30, 25. Nov 2004 (CET)

Sprung zum exzellenten Artikel

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:
    1. Programmiersprache (enthält den Abschnitt, in dem die Syntax derzeit steht) – Dieser Abschnitt sollte erweitert werden, damit die komplette Syntax erklärt wird.
    2. API – Der Abschnitt APIs kann meiner Meinung so bleiben (Liste mit Links).
    3. VM – Ein Artikel zur Java VM inklusive der Differenzen zu anderen VMs.
    4. Geschichte – Sollte ein eigene Artikel mit zwei Abscnitten werden:
      • Entstehungsgeschichte von Java
      • Versionsgeschichte von Java
    5. 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)

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)
klingt gut! -- D. Dÿsentrieb ⇌ 01:57, 9. Dez 2004 (CET)

Sehe die letzten Vorschläge ebenfalls sehr positiv, würde die weitere Gliederung aber etwas anders aufziehen:

kurzer geschichtlicher Abriß und Beurteilung der Bedeutung der Sprache

  • eigene Seiten für die Java-Technologien, Zuordnung und detaillierte Beschreibung der zugehörigen APIs dort
  • Seite Java APIs wäre eine reine Übersichtsseite
  • jedes API erhält eine eigene Seite
  • eigene Behandlung von Java als Programmiersprache (Syntax, Sprachelemente, Beispiele)
  • VM muss allgemeiner diskutiert werden : Darstellung der technischen Architektur über die unterschiedlichen Laufzeitumgebungen (VM, Servletcontainer, EJB-Container ...). Im Zusammenspiel muss der Zusammenhang als Verteiltes System hersgestellt werden.
  • Geschichte: Sehe ich genau wie Herr Schröder: Auftrennung in Entstehungsgeschichte/Versionsgeschichte. Die Versionsgeschichte (allgemein) sollte die Weiterentwicklung von Java über JSR (Java Specification Request) und den JCP (java Community Process) abhandeln. Konkrete Versionen wiederum sind eigentlich den Technologien zuzuordnen.

Bei einer Neugestaltung Java ist zu beachten, daß z.T. schon eigene Seiten für Technologien (z.B. J2EE) und zahlreiche APIs wie JDBC, Servlet bestehen.

Praktische Frage: Kann man die vorliegende Diskussionsseite Java aufräumen und ältere Beiträge löschen / auslagern ? --Exilfranke 11:57, 15. Dez 2004 (CET)


  • Hier Jungs - man kann es (gesprochen "kanns") mit den Klammern (und deren Randbemerkungen) auch übertreiben.

Zuweisung vs. Ausdruck vs. Anweisung

Zur Frage, wie die Zuweisung zu bewerten ist:

  1. Jeder Ausdruck ist eine Anweisung. Z.B. ist i+3 die Anweisung, den Wert der Variablen i mit 3 zu addieren und zugleich ein Ausdruck, dessen Wert eben das Ergebnis ist.
  2. Ebenso, wie das Pluszeichen ein Operator ist, der zwei Operanden erwartet (im Beispiel i und 3) und ein Ergebnis liefert, erwartet auch der Zuweisungsoperator = zwei Operanden und liefert ein Ergebnis, nämlich den Wert des rechten Operanden!
  3. Der Zuweisungsoperator hat jedoch zwei Besonderheiten:
    • Er verändert den linken Operator.
    • Er wird von rechts nach links ausgewertet: a = b = c wird also wie folgt ausgewertet:
      1. Setze b auf den Wert von c.
      2. Das Ergebnis ist der rechte Operand, also c
      3. a wird auf dieses Ergebnis gesetzt.

Somit ist die Zuweisung eine Anweisung (die VM wird angewiesen, eine Referenz oder den Wert eines Basisdatentyps zu setzen). Zugleich ist sie ein Ausdruck, da sie selbst einen Wert besitzt.

Alle Klarheiten beseitigt?

--Johann Uhrmann 18:04, 20. Mär 2005 (CET)

Jupp ;) Nur dass da ein Fehler ist: "i+3" ist zwar in C eine Anweisung, nicht jedoch in Java. In Java sind ausschließlich solche Ausdrücke auch Anweisungen, die einen Nebeneffekt haben. In Java gilt: Alles, was einen Wert liefert, ist ein Ausdruck. Als Anweisung sind nur solche Ausdrücke zulässig, die einen Nebeneffekt haben oder haben könnten. Das sind alle Ausdrücke mit Operatoren mit Nebeneffekt (++, --, =, +=, -=, *=, /=, %=, &=, |=, >>=, >>>=, <<=) sowie alle Methoden- und Konstruktoraufrufe. Zur Verifikation einfach mal versuchen, folgendes Programm zu compilieren: --ChristianHujer 14:47, 30. Mär 2005 (CEST)
class Expr {
    public static void main(final String... args) {
        int i = 10;
        i + 3;
    }
}
Nein, i+3 ist in C keine Anweisung sondern ein Ausdruck. --Hades 14:04, 3. Apr 2005 (CEST)
Ich habe nie behauptet, i+3 sei in C kein Ausdruck. Aber i+3 ist in C eben auch eine gültige Anweisung (sofern mit Semikolon terminiert), wie folgendes C-Programm demonstriert, das mit jedem mir bekannten C-Compiler compiliert:
main() {
    int i;
    i + 3;
}
In C ist jeder Ausdruck als Anweisung gültig. In Java sind es nur solche Ausdrücke, die Nebeneffekte haben können. Und genau darum ging es hier.--ChristianHujer 19:43, 3. Apr 2005 (CEST)
Ja, so kann man es sagen. In C gilt: Ausdruck plus Semikolon gleich Ausdrucksanweisung. --Hades 20:28, 4. Apr 2005 (CEST)
... kleine Ergänzung: das Programmierbeispiel wird sich nicht mit jedem Compiler übersetzen lassen, denn es ist kein gültiges C. c'est la vie ;-P --Hades 20:30, 7. Apr 2005 (CEST)
Ich kenne C99 nicht bis ins kleinste Detail, und mein gcc unterstützt es noch nicht vollständig (gcc 3.3 20030226), aber es compiliert bei mir auch mit -std=c99. Es ist zwar deprecated weil kein return type für main() angegeben ist, das erzeugt bei C99 eine Warnung, außerdem wird auf i zugegriffen, ohne i initialisiert zu haben, sehr unschön, aber ich kann keine wirklichen Probleme erkennen. int main() { int i = 0; i + 3; } sollte aber in jedem Fall einwandfrei funktionieren, es sei denn die Definition von Statement hat sich bei C99 gegenüber den früheren Versionen geändert. --ChristianHujer 19:54, 9. Apr 2005 (CEST)
Wow, 205,40 Euro. Ich dachte, ich bestelle mir mal eben den C99-Standard, aber *das* ist mir definitiv zu teuer. Nachdem die Industrie das sowieso schon finanziert hat, sehe ich das nicht ein, das grenzt an Wegelagerei und Halsabschneiderei. Dann doch lieber die JLS online... Oder was denkst Du? --ChristianHujer 19:59, 9. Apr 2005 (CEST)

Java Wiki

Wo ist der "Java Wiki" (externe) Link? --Alien4 23:24, 31. Mär 2005 (CEST)

Der ist berechtigterweise am 15. Feb rausgeflogen. Wikipedia ist schließlich kein Site-Promoter. Siehe Wikipedia:Verlinken und Wikipedia:Was Wikipedia nicht ist --Messi 12:55, 2. Apr 2005 (CEST)
Zuerst dachte ich, das müsse mir erklärt werden; nachdem ich aber dort war, verstehe ich's (auch ein Link von hier dorthin, würde die Situation im momentanen Zustand dort nicht verbessern). --Alien4 02:28, 4. Apr 2005 (CEST)
Schade, dass kein brauchbares Java Wiki existiert. --Alien4 14:51, 10. Apr 2005 (CEST)
Was ist ein brauchbares Java Wiki? WikiBooks ?
Auch wenn es natürlich nicht "WikiBuch" oder "WikiLlbrum" (...) heisst, weiss ich trotzdem noch nicht, wie es mir weiterhelfen soll. Ich will kein Buch schreiben, sondern nur eine Lösung für mein Java Problem. Ein (multisprachlich umfassendes) Java Forum (FAQ, ...) -> Java Wiki wäre da sehr hilfreich. --Alien4 17:57, 10. Apr 2005 (CEST)
Nimm die Newsgroup [[1]] - es muss nicht immer ein Wiki sein! --Bastie 13:49, 16. Apr 2005 (CEST)
(Sicher beantworten alle gerne immer wieder dieselben Fragen (gibts ein newsgroup archiv, hierarchisch strukturierbar, oder wenigstens komfortabel durchsuchbar, verlinkt mit anderen Sprachen: mir ist egal ob die Frage(n) auf meine Schwierigkeit(en) auf deutsch, englisch oder gar französisch (, ...) beantwortet wird(/werden)), nicht das ich sagen will, mein Problem sei eine "faq". Wenn ich mal wieder einen einigermassen sauber konfigurierten Newsreader haben werde, werde ich wohl mal vorbeischauen.) --Alien4 19:25, 17. Apr 2005 (CEST)
Hallo - schlecht geschlafen? Variante 1 Offizielle FAQ Seite der Newsgroup; Variante 2: Google mal im Newsgroup Bereich von dclj nach FAQ. Nebenbei wenn du ein JSP / Servlet Wiki findest was unter "javaserver" läuft mache ich dir sofort dein JWiki... --Bastie 13:32, 30. Apr 2005 (CEST)

Weblinks

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)

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 [2] sagen? --Herr Schroeder 11:19, 2. Mai 2005 (CEST)
BTW nach welchen Kriterien hast Du die Links eigentlich aussortiert? --Herr Schroeder 11:20, 2. Mai 2005 (CEST)
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)
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)
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)

Ich bin dafür die Linkliste erheblich zu kürzen. Es sollten nur noch die Links auf die Java-Seiten von Sund, die Download-Seite, die Programmierrichtlinie, das Wikibook und den Eintrag im OpenDirectory Project bleiben. Alle anderen sollten dan im OpenDirectory Project unterkommen. Die meisten Tutorien sind eh nicht so gut wie die Online-Versionen einiger unter Literatur angegebener Bücher (z.B. Java ist auch eine Insel). --Squizzz 10:18, 18. Mai 2006 (CEST)

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

Memo: Vollständige Weblinks

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)
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)
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)

Reorganisation der Seite

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

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)

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)
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)
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)
  • Ich habe vor die Artikel nach dem 10.06. entsprechend der Vorlage umzugestalten. Ich wünsche von daher, dass an dieser Stelle bis dahin möglichst viele Meinungen eingehen. --Herr Schroeder 13:23, 2. Jun 2005 (CEST)
Die neue Einordnung sieht sehr sinnvoll und gut aus. Meinen Segen hast du. ;-) --Qbi 16:39, 3. Jun 2005 (CEST)

Foren-Links-Kompromiss

Um das ständige Hin und Her in der Sektion Weblinks zu beenden, möchte ich folgenden Vorschlag machen: Wir setzen Links zur Google- und MSN-Suche z. B. für "java forum" auf deutsch und keine direkten mehr zum einen oder anderen Forum. Das ist m. E. fair und quasi selbstregulierend. Ich werde gleich mal mutig sein und das machen. Wem es nicht gefällt, soll es ändern, aber bitte auch hier erklären, warum nicht. Hat WP eigentlich Vorlagen für sowas? -- messi 11:37, 6. Jun 2005 (CEST)

Um erlich zu sein finde ich diesen Kompromiss mehr als faul. Wenn die Leute nicht mehr imstande sind diese Abfrage selbst durchzuführen, dann kann ihnen kaum noch jemand helfen. Ebenso ist das Problem, dass die meisten hier eingetragenen Links nur von mittelmäßiger Qualität sind und nicht wirklich weiterführend. Von daher wäre ich eher dafür diese Linksektion komplett zu löschen inklusive aller Foren. --Herr Schroeder 13:49, 6. Jun 2005 (CEST)
Ausnahme wären höchstens die links auf die Seite [[3]]. --Herr Schroeder 14:48, 6. Jun 2005 (CEST)
Du findest den Kompromiss faul? Naja, wenn du jetzt alle Links heraus nimmst, kommen sie eines Tages wieder. Die beiden Links lassen zumindest eine direkte Foren-Verlinkung redundant wirken. Aber meinetwegen können auch alle Links verschwinden. -- messi 15:11, 6. Jun 2005 (CEST)
Ich bin mir der Problematik bewußt. Habe schon selbst häufig genug nicht relevante Links entfernt. --Herr Schroeder 15:17, 6. Jun 2005 (CEST)
Völlig falscher Ansatz - sorry. Weblinks auf Foren sind nicht erwünscht. Dass immer wieder neue Links eingestellt werden ist normal - nich nur bei Java. Ich revertiere täglich an die 50 Weblinks in den Artikeln auf meiner Beobachtung... --ncnever 19:33, 6. Jun 2005 (CEST)
Calm down! Bin ich jetzt hier plötzlich derjenige, der direkte Foren-Links setzt?
Woher weißt du, daß Foren-Links nicht erwünscht sind? Hast du eine Umfrage gemacht? Erzähl mir aber jetzt nichts von Wikipedia-Verlinkungsrichtlinien. Ich bin schon ein wenig länger dabei.
Außerdem verzichte bitte in Zukunft auf polemische Sprüche, à la "Bin ich hier im falschen Film [..]".
Naja, es war halt nur ein Kompromissvorschlag, damit auch du nicht mehr so viel rumrevetieren mußt.
-- messi 19:55, 6. Jun 2005 (CEST)

Sätze entfernt

Ich habe einige Sätze aus dem Text entfernt: Die Kehrseite des Verzichts auf die Zeigerarithmetik, der zwar den Schutz eines Speicherüberlaufs weitgehend vorbeugt, ist jedoch gleichzeit der Verzicht auf eine effiziente Programmierung, die letztendlich nicht über Referenzen kompensiert werden kann. Das sehe ich nicht so. Bei Tests hier zeigte sich im Vergleich mit gcc eher eine Schwäche Javas bei Numbercrunching als bei Speicherverwaltung. Für die Behauptung möchte ich dann doch eher Belege sehen, um überzeugt zu werden. Zudem ist daher auch die Übergabe per Referenz bei Methoden - bei Java zumindest - nicht möglich. Bei Java erfolgt nur die Übergabe von einfachen Datentypen 'per value', alle anderen Übergaben sind automatisch 'per reference'. Die Aussage ist also schlicht falsch. -- Dishayloo [ +] 17:56, 7. Aug 2005 (CEST)


Ich bin zwar nicht ganz bewandert auf diesem Gebiet, aber ist es nicht so, dass Java eigentlich keine richtiges 'per reference' verwendet.
Beispiel:
Farbe f = Farbe("rot");
..
public static void funktion(Farbe f)
{
 f = new Farbe("blau");   
}
...
funktion(f); //Das Attribut 'farbe' der Klasse bleibt trotzdem 'rot'

Im Gegensatz dazu C++: 

void funktion(Farbe *f)
{
 free(f);
 f = new Farbe("blau"); //Hier wird auf 'blau' geändert
}
Kann man das bei Java also wirklich 'per reference' nennen? 84.179.162.160 10:52, 23. Aug 2005 (CEST)

Deine Beispiele werden leichter verständlich, wenn man die globale Variable anders nennt als die lokale. Also so: 

Farbe g = new Farbe("rot");
...
public void funktion(Farbe f) {
    f = new Farbe("blau");
}
...
funktion(g);

In diesem Java-Beispiel behält g seinen Wert. Es wird innerhalb der Methode funktion auch weder gelesen noch geändert. Das Beispiel ist also vollkommen sinnlos. Das C++-Beispiel tut aber das gleiche, du musst es nur vollständig hinschreiben: 

Farbe* g = new Farbe("rot");
...
void funktion(Farbe* f) {
 free(f);
 f = new Farbe("blau"); //Hier wird auf 'blau' geändert
}  
...
funktion(g);

Dieses Beispiel verursacht übrigens einen hübschen Absturz, wenn du anschließend versuchst, g zu verwenden. Denn g zeigt nach Aufruf der Funktion auf einen nicht mehr reservierten Speicherbereich. Beide Funktionen (Java und C++) bekommen zwar Referenzen, tun aber nichts damit. Die Beispiele sind also unsinnig. --jpp ?! 11:11, 23. Aug 2005 (CEST)


Also bei mir verursacht folgendes Programm keinen Absturz - die Ausgabe ist auch 'blau' (im Gegensatz zu Java):
#include <iostream>

class Farbe
{
 private:
  char *farbenName;
 public:
  Farbe(char *f) {farbenName = f;}
  char *getFarbe() {return farbenName;}
};

void funktion(Farbe *f)
{ delete f; f = new Farbe("blau");} 

void main()
{
 Farbe *g = new Farbe("rot");
 funktion(g);
 std::cout << (*g).getFarbe();
}

Anmerkung:

84.179.162.160 13:18, 23. Aug 2005 (CEST)

Die Referenz wird als Wert übergeben. --jpp ?! 13:42, 23. Aug 2005 (CEST)
Dass das C++-Beispiel funktioniert, ist reiner „Zufall“, da die neue Instanz an der gleichen Speicheradresse erstellt wird. Nice try! --messi 14:22, 23. Aug 2005 (CEST)

Referenzen in Java

  • Java leitet Objekt Referenz an Methoden mit Call by Value weiter.
    • Ein ändern der übergebenen Objekt Referenz ist nicht möglich.
  • Aber: Die zugehörigen Attribute des Objektes können innerhalb einer Methode geändert werden.

Beispiel: würde die Klasse Farbe ein Attribute 'String farbname' besitzen könnte in der Methode 'funktion' das Attribut beliebig geändert werden. --Sonntag.michael 11:03, 2. Nov 2005 (CET) Also Java arbeitet grundsätzlich bei Objekten mit Call by Reference, ich glaube nur das hier einigen nicht klar ist was das bedeutet. Es ist aber nicht möglich die Referenz durch Übergabe an eine Methode zu verändern. Referenzen z.B. | Handbuch der Java-Programmierung 10.2.2 --Sonntag.michael 13:17, 10 November 2005 (CET)

Plattformunabhänigkeit

Vielleicht sollte man diesen Absatz durch die kritische Bemerkung ergänzen, dass Java zwar Plattformunabhänig ist, nur dass es zwischen den einzelnen Versionen teilweise zu Komplikationen können. Es kommt manchmal vor, dass von eher exotischen Befehlen der Syntax geändert wird und dann muss das Programm für die Nachfolgeversion angepasst werden. Eventuell kann man sich diesen EIntrag aber auch sparen, da es relativ selten vorkommt. -- Karsten K 21:12, 17. Aug 2005 (CEST)

Wenn wir schon dabei sind:
Java ist eine objektorientierte, plattformunabhängige Programmiersprache [...]
Was soll das plattformunabhängige? Welche Programmiersprache ist bitte Plattformabhängig? Ist doch nur eine Frage für welche Plattform ein Compiler oder Interpreter existiert.
Java wird als plattformunabhängige Programmiersprache bzw. plattformunabhängiges System bezeichnet. Die Plattformunabhängigkeit erreicht Java durch die Definition einer eigenen Plattform..
Das ist doch wohl ein Widerspruch. Java ist an die Java-Plattform gebunden und daher Plattformunabhängig? Wenn man bei Programmiersprachen schon von Plattformunabhängigkeit sprechen will, ist Java wohl die plattformabhängigste Programmiersprache überhaupt. Was man bei Java meint ist nicht die Plattformunabhängigkeit, sondern die mitgelieferte Plattform, die Java-Bytecode für die unterliegende Architektur kompiliert (oder JITet) (in SUN Worten: Compile Once, Run Everywhere. Wobei das alles nicht an die Programmiersprache Java gebunden ist, wie die native Java Compiler beweisen.
Ach, da fällt mir noch auf:
Java basiert in seiner Syntax auf der objektorientierten Programmiersprache C++.
Nein, sicher nicht. Die Syntax unterscheidet sich deutlich. Die Syntax beider Programmiersprachen basiert eben auf C.
--Kingruedi 19:49, 31. Aug 2005 (CEST)
So, hab das mit der Plattformunabhängigkeit mal korrigiert --Kingruedi 21:55, 31. Aug 2005 (CEST)

Lesenswerte-Diskussion

Pro Antifaschist 666 00:46, 17. Okt 2005 (CEST)

  • Contra. Viele technische Ungenauigkeiten/Fehler, teils chaotische Struktur (z. B. werden wichtige Sprachkonzepte nur im Kapitel „Unterschiede zu ähnlichen Sprachen“ erwähnt). --Jan Arne Petersen 01:13, 17. Okt 2005 (CEST)
  • Contra - Muss mich meinem Vorredner anschließen. Beispiele: Sun hat sich jedoch für die C++ Syntax entschieden und gleichzeitig verlauten lassen, Java würde von C++ abstammen. Eigentlich unterscheidet sich die Syntax von C++ und Java enorm. Die Gemeinsamkeiten sind eher auf die C Wurzel zurück zu führen. --Kingruedi 19:47, 19. Okt 2005 (CEST)

Pro nicht exzellent, aber lesenswert auf jeden Fall.--Heliozentrik 20:00, 19. Okt 2005 (CEST)

  • Contra --Elian Φ 02:52, 21. Okt 2005 (CEST)
  • Contra zu wenig Geschichte, Unterschiede zwischen den Versionen wären wünschenswert. --Bricktop 22:34, 21. Okt 2005 (CEST)

IDE

Sind die (Java...) Entwicklungsumgebungen integraler (inherent!!!) Bestandteil der Programmiersprache? --Alien4 19:47, 14. Dez 2005 (CET)

Nein. Aber JRE und JDK sind integraler Bestandteil der Java-Technologie. Warum fragst du? --jpp ?! 22:49, 14. Dez 2005 (CET)
Was ist die Java-Technologie? (Kann das auf Java ( -> Programmiersprache, Laufzeitumgebung(en), Hilfsmittel (IDE(s)...), Plattformen(?), Verfahren(?), ...?), so wie es dort steht (verstanden wird? / zu verstehen sein sollte?...), wirklich so angewendet werden?; und falls ja, müssten dann doch demnach wohl Java IDE...s so Bestandteil jener "Technologie" sein (vielleicht dann in den Artikel verschieben?), nicht?) --Alien4 16:41, 6. Jan 2006 (CET)
Nein, IDEs gehören nicht zur Java-Technologie. --jpp ?! 23:18, 6. Jan 2006 (CET)
Hab ich das (zusammenfassend) jetzt richtig verstanden: Java(!) IDEs gehören eigentlich weder inherent zur Programmiersprache (also eigentlich nicht wirklich in diesen Artikel), noch eigentlich zur Technologie? In welchen Artikel würde es dann (zugegeben, nur "korektesterweise") richtigerweise gehören: In einen eigenständigen Artikel ("Java IDEs"?) oder in einen noch zu kreierenden übergeoordneten ("Java Programmiersystem" (Sprache, VM (Plattform?), IDE, SDK, ... eben alles was mit Java Programmierung ... Ausführung usw. zu tun hat; vielleicht sogar inkl. JavaScript?), "Java...."), ... oder...? --Alien4 02:58, 2. Mär 2006 (CET)
Schonmal den Artikel Java (Technologie) gelesen? --jpp ?! 13:29, 2. Mär 2006 (CET)
Wieso? --Alien4 16:43, 2. Mär 2006 (CET)
Weil du oben fragtest, ob IDEs zur Java-Technologie gehören. Aus dem Artikel geht hervor, dass sie das nicht tun.
Um noch mal auf die IDEs zurückzukommen: Es gibt sowohl IDEs, die nicht in Java implementiert sind, mit denen sich aber Java-Programme entwickeln lassen (z. B. IntelliJ IDEA), als auch IDEs, die in Java geschrieben sind, mit denen sich aber Programme in anderen Programmiersprachen entwickeln lassen (z. B. Eclipse). Damit will ich sagen, dass IDEs eigenständige Produkte sind, und nicht etwa Teil einer Programmiersprache oder Technologie, also auch kein „inherenter“ Bestandteil (was auch immer „inherent“ in diesem Zusammenhang bedeuten mag).
Aber jetzt habe ich doch etwas den Faden verloren. ;-) Worauf willst du eigentlich hinaus bzw. warum stellst du diese Fragen? --jpp ?! 17:19, 2. Mär 2006 (CET)
Soll ich das so interpretieren, (für dich?) es gibt nicht "Java IDE"? --Alien4 20:14, 2. Mär 2006 (CET)

Es gib Java-IDEs. Allerdings sind diese weder Bestandteil der Sprache, noch der unter dem Namen Java bekannten Technologie. --Squizzz 20:32, 2. Mär 2006 (CET)

Zur Zusammenfassung: Es gibt Java-Entwicklungsumgebungen. Diese können in einer beliebigen Programmiersprache entwickelt sein (im Prinzip ist jeder Texteditor dafür geeignet). Es gibt Entwicklungsumgebungen, die in Java geschrieben sind, mit welchen man jedoch in beliebigen Programmiersprachen entwickeln kann. Genauso ist es aber auch für jede andere Programmiersprache. Ich kann für jede Programmiersprache einen beliebigen Editor benutzen um in dieser Sprache zu entwickeln. IDEs dienen nur zur Vereinfachung der Entwicklung.

An Alien4: Gibt es eine Programmiersprache, wo die IDE Deiner Meinung nach inherenter Bestandteil der Sprache ist? Ich persönlich kenne zumindest keine. Einzig bei Smalltalk wird dieses Bundling häufig vorgenommen, jedoch ist es kein inherenter Bestandteil der Sprache, da ich nach wie vor meine Klassen in einem beliebigen Editor schreiben kann und dann in das System einbinden kann. --Herr Schroeder 09:37, 3. Mär 2006 (CET)

Es ist schon so - ich werde Wikipedia wohl nie verstehen. Nachdem ich Probleme (Fragen) mit Java IDE(s) hatte, dachte ich, Wikipedia hätte mir evtl. dabei (weiter?)helfen können. Ich hätte nur irgendwo (und zwar an der richtigen Stelle: inherent -> im Programmiersprache Artikel - nicht() -> anderswo) eine Liste (nicht Aufzählung; vielleicht auch mit Vergleich?) von Java IDEs (dummerweise finde ich Code Completion, ... zu angenehm(?)) praktisch gefunden (Wikipedia -> Enzyklopädie -> Hilfe, Info ... auf verschiedensten Gebieten?). (Bin ich wohl der Einzige?) --Alien4 16:05, 17. Mär 2006 (CET)
Es hat halt noch niemand eine entsprechende Aufstellung erstellt. Das ist auch recht schwierig, wenn mann von einer reinen Aufzählung absieht, dann dazu müsste man sie auch alle intensiv ausprobieren um einen Vergleich anstellen zu können. Oder man hat so einen LaLa-Vergleich der technischen Daten, der nicht unbedingt besonders aussagekräftig ist. Als Enzyklopädie ist die Wikipedia eine Wissenssammlung und kein Hilfe-Forum. Wenn du Hilfe brauchst, so schau doch auf dem Java-Forum von Sun nach. Ansonsten sind deine Text schwierig zu lesen, da ziemlich unstrukturiert durch die häufige Benutzung von Klammern. Stell einfach noch mal deine Fragen in vernünftigen deutschen Sätzen. Ich werde sie gerne beantworten. --Squizzz 16:50, 17. Mär 2006 (CET)
Irgendwann dachte ich vielleicht mal Wikipedia sei ein "Gemeinschaftsprojekt" (dass die, die damit arbeiten nicht wenigstens ein bisschen die Vor- und Nachteile einer Sache kennen, würde mich sehr verwundern), dass Einer vielleicht mal nur mit einem, und erst noch kurzen Eintrag beginnen könnte, und dann vielleicht Andere es erweitern (also alles, was unseren geschäzten Admins zuwiderläuft -> dummerweise so, wie ich es angehen würde). Reine Funktionsvergleiche (dieses hat "Code Completion", dieses nicht, hat/nicht "Word Match", ... (Bug x / y noch offen, oder "erledigt" ...)) sollte doch dann nicht so schwierig sein.
Weshalb Wissensverbreitung/-teilung nicht hilfreich sein soll, musst du mir vielleicht noch erklären (oder vielleicht einfach nur, was ein Wikipedia "Purist"(?) ist). --Alien4 20:54, 23. Mär 2006 (CET)
Es ist niemand, hier der sich befähigt fühlt einen entsprechenden Artikel zu schreiben und auch die Zeit hat. Dazu ist einiges an Wissen notwendig. Die einfachen Features, die du erwähnt hat, hat doch heutzutage jede IDE. Die sind kein Unterscheidungsmerkmal. Die Unterschiede liegen in anderen Bereichen und die sind schwerer zu ermitteln. Einen einfachen Einblick, welche IDEs es gibt liefert ja dieser Artikel. Ansonsten sag ich's noch einmal: du tust anderen und wahrscheinlich auch dir einen Gefallen, wenn du klar sagst, was du willst und nicht irgendwelche philosophischen Diskussionen beginnst. --Squizzz 22:47, 23. Mär 2006 (CET)

+ ist kein überladener Operator

Siehe [4] und [5]: + ist kein überladener Operator. Wenn + überladener Operator wäre, müsste das in der Klasse Object oder String definiert sein. Es ist aber ein in der Sprachspezifikation von Java definiertes Compilerverhalten. Sonst müsste man auch &, | und ^ als überladene Operatoren bezeichnen, da sie sowohl auf arithmetische als auch auf logische Operanden angewandt werden können. --ChristianHujer 00:07, 19. Mär 2006 (CET)


Die Passagen der Spec kenn ich, habe ich sie doch nochmal studiert bevor ich den Post gemacht habe. Ich denke wir sollten nicht so tief reingehen hier eine entsprechende Unterscheidung zu machen, da der "normale" Leser dies nicht unterscheiden kann. Von aussen betrachtet ist es egal ob es ein Compilerverhalten ist oder nicht....das '+' wird aus Sicht des gewöhnlichen Corporate Developers überladen. --Michael Hüttermann 16:10, 19. Mär 2006 (CET)

Das mag schon sein, ist für mich aber kein Grund, in der Enzyklopädie wissentlich Falschinformationen zu verbreiten. Ich kann den Revert der Löschung daher nicht nachvollziehen. Von "Fakt" kann überhaupt nicht die Rede sein. Überladen von Operatoren bedeutet die Möglichkeit, Operatoren abhängig vom Typ zu definieren. Ohne diese Sprachmöglichkeit, und in Java ist sie nicht gegeben, gibt es kein Überladen. Es sei denn, man zählt auch Operatoren dazu, die durch die Sprachdefinition selbst typabhängiges Verhalten zeigen. Aber dann, wie gesagt, sind auch &, | und ^ überladen. Von "Innerhalb von Java-Klassen" kann dann aber erst recht nicht die Rede sein.
@Michael: Abgesehen davon hast Du den Satz an den falschen Absatz angefügt ;)
Ich habe den Absatz jetzt dahingehend geändert, dass er das entsprechend erläutert. Ich hoffe, mit der Lösung können wir beide leben. --ChristianHujer 00:16, 20. Mär 2006 (CET)
@Christian: Damit kann ich leben, ja. :-) "Wissentliche Falschinformationen" finde ich doch etwas übertrieben. Dein neuer Absatz ist sehr gut, differenziert und super formuliert. --Michael Hüttermann 20:53, 22. Mär 2006 (CET)

Geschichtliche Informationen?

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)

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)

JFC

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. (nicht signierter Beitrag von 212.202.173.196 (Diskussion) )

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)

JIT schneller als nativer Code?

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... (nicht signierter Beitrag von 84.172.128.243 (Diskussion) )

Wer behauptet denn sowas? Beziehst du dich auf eine bestimmte Stelle im Artikel? --jpp ?! 09:20, 10. Aug 2006 (CEST)
Zur Performance gibt es kaum 'falsche' Aussagen, da diese je nach Anwendungsfall, Architektur und Mondstand stark unterschiedlich sein kann. Siehe beispielsweise [6], [7], [8]. 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)

Frameworks

Es hat keinen Sinn hier alle Frameworks für Java aufzulisten, da einige Hundert existieren. --Squizzz 15:51, 30. Aug 2006 (CEST)

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)
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)
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)
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)
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)
Ja, auch ich würde Text gegenüber einer Liste bevorzugen. Darin sind wir uns einig. --jpp ?! 16:20, 10. Okt. 2006 (CEST)

Write Once, Run Anywhere

Hi, eine IP hat den entsprechenden Abschnitt jetzt schon zweimal gelöscht und beim zweitenmal behauptet, der entsprechende Inhalt stünde bereits in Java-Plattform. Da ich IPs leider nicht per Diskussionsseite ansprechen kann: Wo steht denn dort etwas zum Thema Write Once, Run Anywhere? Ich kann’s nicht finden, aber vielleicht habe ich ja wirklich Tomaten auf den Augen. --jpp ?! 19:47, 5. Dez. 2006 (CET)

Auch IPs haben Diskussionsseiten.
In dem anderen Artikel steht zu wenig zu den Themen in dem fraglichen Abschnitt, in Java Virtual Machine steht dann wieder ein Teil.
In jedem Fall ist es aber in einem dieser Artikel richtig aufgehoben, hier nicht. Hier geht es um die Sprache; daß Java vor allem für VMs entwickelt wird, muß erwähnt werden, ist es aber auch. Für die Sprache selbst ist es irrelevant, in welche Umgebung das Ergebnis läuft. --193.254.155.48
Wie du selbst schon sagst, an anderer Stelle steht (noch) nicht genug. Daher finde ich es ungünstig, erst an einer Stelle zu löschen und dann an anderer Stelle nachzutragen (wenn du das denn jemals tust). --jpp ?! 18:30, 6. Dez. 2006 (CET) PS: IPs haben zwar Diskussionsseiten, aber in 90 % der Fälle nützt das nix, weil sie dynamisch sind. Und ich bin zu faul um nachzuschauen, ob du nun dynamisch oder statisch bist. So wie du keine Lust verspürst, dich anzumelden.
Trag's halt an anderer Stelle nach, wenn da etwas fehlt. Hier gehört es mit Sicherheit nicht hin, warum sollte es also hier stehen? (Komische Diskussion) --193.254.155.48
Wenn du eine Information entfernst, egal ob sie vorher an der richtigen Stelle stand oder an der falschen, dann ist sie weg. Du hast also die Menge des in der Wikipedia enthaltenen Wissens verringert. Das finde ich nicht in Ordnung. Na gut, füge ich’s halt selbst woanders ein, somit hast du es geschafft, andere für dich arbeiten zu lassen. Gratuliere. --jpp ?! 21:03, 6. Dez. 2006 (CET)
Erklärst Du mir bitte, warum eine Verbesserung der Wikipedia eine Arbeit für mich sein soll? Erklärst Du mir bitte, warum eine falsche Information in einem Artikel eine Verbesserung der Wikipedia darstellt? Erklärst Du mir bitte unter welchen Umständen das Entfernen falscher Informationen für Dich ok ist? --217.235.251.113
Liebe IP, ich glaube, du schnappst über. Ich starte trotzdem mal einen Erklärungversuch: Die Information ist nicht falsch, sondern richtig. Sie stand nur an einer Stelle, an die sie eigentlich nicht hingehört. Wenn du bei der Verbesserung der Wikipedia behilflich sein willst, mach bitte keine halben Sachen. An Artikeln herumschnippeln kann jeder, hilfreich ist das nicht. Leg dir lieber einen Benutzernamen zu und schreib Artikel. Oder bleib zu Hause. --Kurt Seebauer 23:57, 6. Dez. 2006 (CET)
Wenn ich als IP Dich persönlich beleidigt hätte, hätte umgehend jemand die Wikipolizei gerufen und mich blocken lassen. WP:KPA gilt für Dich nicht? Reiß Dich mal ein wenig zusammen, das ist hier kein Schulhof.
Wenn der gleiche Absatz in Deutscher Bundestag stünde, wolltest Du dann erst warten, bis sich ein lauschiges Plätzchen gefunden hat, wo er besser paßt? Die Information war hier falsch, also mußte sie hier weg. Offen gesagt glaube ich nichtmal, daß hier jemand anderer Meinung ist, sonst wäre es mir als IP nicht erlaubt worden, eine nicht authorisierte Änderung an der heiligen Wikipedia durchzuführen.
Nur der Vollständigkeit halber: Erklärst Du mir bitte, warum eine Verbesserung der Wikipedia eine Arbeit für mich sein soll? Erklärst Du mir bitte unter welchen Umständen das Entfernen falscher Informationen für Dich ok ist? --217.235.251.113
Nein. --Kurt Seebauer 17:27, 7. Dez. 2006 (CET)
Nein, WP:KPA gilt für Dich nicht? Na, daran werde ich denken, wenn wir uns nochmal über den Weg laufen. --217.235.238.230

Der Name Java

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)

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)

Java Umleitung

Entschuldigt, habe jetzt erst gesehen, dass der Link Java auf Programmiersprache_Java umgeleitet wurde. Hat mich etwas verwirrt (weil es keine Umleitungsanzeige gibt). -- HelmutLeitner

Ich hab da ein Problem ...

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)

Rein objektorientiert?

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) Im Text steht :

C# kennt ebenso wie Java eine Unterscheidung zwischen Werttypen (engl. "value types"; z. B. int, struct) und Referenztypen (engl. "reference types", z. B. class), allerdings sind auch die elementaren Datentypen objektbasiert.

struct gibt es in java nicht, und in C++ sind sowohl struct als auch class "class types" (der einzige unterschied zwischen struct und class ist dass in struct per default alles public ist)... also irgendwie ist dieser satz humbug...

ein bischen ...

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)

objektorientiert und c#

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)

Vaterfigur

Ich hab ein Problem mit Patrick Naughton: [9] [10] [11]

Wie sollte ich denn bitte das dann in der Bio schreiben? OliD 18:53, 20. Mai 2003 (CEST)

Slashdot - News for NERDS Da bist Du wohl jemanden auf den Leim gegangen ;-) Das hier ist auch witzig: Steffi Graf Wins Case Vs. Microsoft http://yro.slashdot.org/yro/02/05/28/1911247.shtml?tid=123 from the refusal-to-promise-a-perfect-tomorrow dept.

Nun im Ernst: die englische Beschreibung aus Wikipedia "Java Programming Language" listet Patrick Naughton übrigens nicht, da Gosling die Vaterfigur von Java war. Siehe auch http://java.sun.com/java2/whatis/1996/storyofjava.html

jonelo 20. Mai 2003

in jeder Hinsicht

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)

JNI und JDBC

Mir fehlen im Beitrag Informationen zu plattformspezifischen Lösungen (insbesondere JNI) und der Datenbankanbindung (JDBC). Insbesondere das Java Native Interface ist m.E. von besonderer Bedeutung, da hierdurch vorhandene Ressourcen eingebunden resp. weitergenutzt werden können.

Hhoffmann 3. Juni 2003 (CEST)


Go ahead!

jonelo 5. Juni 2003 (CEST)

Kontrollstrukturen gelöscht? Links zu Webstart und Plugin gelöscht?

In der letzten Zeit wurde hier editiert wie die Axt im Walde! Es gibt keinen Link zu Plugin mehr, keinen zu Webstart, und die Kontrollstrukturen sind ebenfalls alle gelöscht (bei Perl z.B. sind sie aber noch da). Warum? Hat jemand Angst, man könnte einem Wikipedia-Benutzer zu viele Informationen liefern?

Zu Java Webstart / Carter666: Java ist nicht nur eine Sprache, sondern auch das API, die VM etc.. Java Webstart gehört definitiv dazu, es ist nicht einfach irgendeine Anwendung sondern spielt eine ebenso zentrale Rolle wie Servlets oder Applets.

(Die Änderung zu "Container" mit Aufzählung finde ich dagegen sehr gut)

(Keine) automatische Serialisierung bei transient

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)

Enum kein Typ

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)

Link auf API-Dokumentation

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)

Generelle Anmerkungen

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:
- Darstellung der Bedeutung von Java
- Der Architekturaspekt
- Garbage collection
- Klassen/Interfaces

Aus meiner Sicht zu ändern:
- Geschichte nach hinten, evtl. kürzer fassen
- Grundkonzepte erweitern
- Sprachkonstrukte zu technisch, zu ausführlich: Details auslagern
- Versionsgeschichte : wesentlich kürzer, max. 1 Seite !!!
- 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 ?
- 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:
- Plattformunabhängigkeit
- Merkmale der Sprache
- 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)

Wikipedia:Kandidaten für exzellente Artikel

Jikes ist schneller

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)

Java Zwangseinweisung

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)

Seite reorganisiert

Ich habe nun die Seite reorganisiert, wie bereits angekündigt. Es gibt jetzt die folgenden Seiten:

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)

java deutschsprachig ?

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)

Kritik an Java

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)

Dann liefer bitte nachprüfbare Belege für deine Aussagen im Sinne von Wikipedia:Quellenangaben. --jpp ?! 12:43, 14. Apr. 2007 (CEST)
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)

Wikiversity-Link

Leitseite bitte wieder rein, darum geht es. "Inhalte" sofern das Java betrifft, werden auch niemals in der Wikiversity, sondern immer in der Wikipedia zu finden sein, weshalb der Wikipedia-Artikel auch drüben an erster Stelle verlinkt ist. Über die WV-Seite sind aber die in der WV verlinkten Lehrbücher auffindbar und es gibt ein Kolloquium zur Sprache, ergo sind das die "Inhalte", die in der Wikipedia keinen Platz finden können. Daher den Link bitte wieder einfügen. Falls wir Benutzer mit Java-Kenntnissen für die WV begeistern können, bzw. Wikipedians interessiert wären, Java zu lernen, können sie sich ebenfalls drüben melden. Aktuell laufen zwei WV-Kurse "Java" an. --Nutzer 2206 14:48, 13. Jun. 2007 (CEST)

Die von dir genannten Kurse sind jedoch nur Rümpfe von Kursen und erfüllen so nicht unsere Anforderungen an Links. --Stefan Birkner 14:52, 13. Jun. 2007 (CEST)
Beim einen Kurs wird am Kursmaterial gearbeitet, das wird erprobt, beim anderen Kurs ist das Material fertig und wird von extern genutzt. Es gibt wie beschrieben das "Diskussionsforum" zu technischen Fragen zur Sprache und zur Problembehebung, wie beschrieben, was hier nicht zu leisten ist, bzw. kein Bestandteil eines Lexikons sein kann. Ich wäre wie gesagt dafür, die Leitseite wieder zu verlinken. Falls du bei den Kursen mithelfen kannst, willst bzw. falls du bereit wärst, ebenfalls das Kolloquium zu beobachten, wäre das nett. --Nutzer 2206 15:29, 13. Jun. 2007 (CEST)
Die Wikipedia ist explizit eine Enzyklopädie. Verlinkt werden Seiten, die Informationen bieten, die über den Artikel hinausgehen. Dazu zählen explizit keine Foren und ähnliches (Wikipedia:Weblinks). Auf den Seiten der Wikiversity habe ich jedoch keine interessanten Information zur Programmiersprache Java entdeckt. Habe ich etwas übersehen? Dann zeig es mir.
Nein, zur Mitarbeit habe ich keine Lust. Bin in der Wikipedia schon genug ausgelastet. --Stefan Birkner 15:53, 13. Jun. 2007 (CEST)

Okay, das hatte ich so jetzt bei einem "Schwester"projekt nicht erwartet, aber Ok. Die Begründung ist vernünftig, daher akzeptiert.

Das ist für die WV ein Problem. Der Mehrinhalt der WV besteht ja gerade darin, dass dort die Möglichkeit bereitgestellt wird, über Inhalte zu diskutieren und dort Kurse angeboten werden, die Programmiersprache zu lernen. Eine Lösung habe ich da jetzt auf die Schnelle auch nicht parat.

Bei Interesse, schau mal hier: v:Wikiversity:Lehrbücher#Java. Die Wikiversity soll Kurse und Projekte anbieten, Inhalte zur Sprache gehören IMHO eher in die WP, als in die WV, daher wird die Wikiversity da wohl auch mittelfristig keine weitergehenden Inhalte bereitstellen können. Da sehe ich (für die WV) ein Problem. Löschung des Links akzeptiert. --Nutzer 2206 16:12, 13. Jun. 2007 (CEST)

Beispiele

  • Ein paar Beispiele bekannter Programme die mit Java geschrieben wurden fehlt mir irgendwie. Generator 16:36, 12. Jul. 2007 (CEST)
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)
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)
Nein, ich glaubte wirklich, der Apache sei in Java geschrieben. Oh Gott, wie peinlich. :-( --jpp ?! 18:09, 12. Jul. 2007 (CEST)

Wikiversity

Ü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)

Dies ist keine besonders hilfreiche weiterführende Information zum Thema Java (Programmiersprache). --Stefan Birkner 10:46, 15. Jul. 2007 (CEST)
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)
Siehe Wikipedia:Weblinks. Diese Kurse sind eben nicht vom Feinsten. --Stefan Birkner 12:02, 15. Jul. 2007 (CEST)
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)
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)

Die Erläuterung in der Wikiversity, warum der Kurs "Schrott" ist, steht noch aus! Ich möchte dich schon bitten, das noch zu erledigen. Der Java-Artikel verzeichnet keinerlei Lehrbücher oder Hilfen beim Einstieg in diese Sprache, da schafft der "Link" auf die Wikiversity Abhilfe. Dort wurden in einem ersten Schritt erste, grundlegende Lehrbücher verzeichnet. Zudem steht dort die Infrastruktur bereit, die Sprache (Kurs) zu erlernen und sich grundlegende Fragen beantworten zu lassen. --Nutzer 2206 12:50, 15. Jul. 2007 (CEST)

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)
"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)

Folgender Beitrag wurde von Stefan Birkners Diskussionsseite hierhin übertragen:--Nutzer 2206 13:50, 15. Jul. 2007 (CEST)

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)

Schau dir bitte den Beschreibungstext für die Wikiversity bei Weblinks an, dort steht:

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)

Referenzen

>>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. (nicht signierter Beitrag von 145.253.2.23 (Diskussion) )

Danke für den Hinweis. Ich habe den Satz korrigiert. --jpp ?! 13:13, 27. Apr. 2007 (CEST)

Der Objektzugriff in Java ist über Referenzen implementiert. Das ist im meinen Augen einfach falsch. Der Satz Der Objektzugriff in Java ist über Referenzen genannte Zeiger implementiert. war schon richtig. Dort steht ja "Referenzen genannte". Eigentlich sind es Zeiger:

--194.245.91.129 13:16, 18. Jul. 2007 (CEST)

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)

Gescheiterte KLA vom 7.-14. August 2007.

Bin ich grad drauf gestoßen, finde ich sehr übersichtlich und informativ. Von mir ein Pro --Rohieb 会話 +/- 15:32, 7. Aug. 2007 (CEST)
Pro Er ist in der Tat gut geschrieben und sehr informativ. Das Thema an sich ist angesichts der Verbreitung der Sprache schon sehr relevant, sollte also auch gelesen werden... --Nutzer 2206 15:49, 7. Aug. 2007 (CEST)

  • Contra. Sorry, das ist noch etwas sehr zusammengewürfelt. Ich selbst arbeite auch viel mit Java und habe nach dem Lesen des Artikels nicht den Eindruck, dass der Inhalt die Programmiersprache lesenswert darstellt. Hier mal nur ein paar Beispiele ohne Wichtung in Reihenfolge oder sonstwas, die mir aufgefallen sind:
    • Es wird nicht erwähnt, wieso keine Mehrfachvererbung zugelassen wird, abstrakte Klassen werden nicht erwähnt, dafür die Interfaces mehrfach (aber was machen die denn nun genau?)
    • die Vererbungs-Konzepte hinter public/private/protected/default sollten zumindest grob erklärt werden
    • In der Einleitung wird erwähnt, dass Quellcode in Bytecode übersetzt wird, unter Compiler werden dann wieder die Native Compiler erwähnt, so dass sie gleichrangig mit den Bytecode-Compilern erscheinen
    • JNI taucht "nebenbei" in den Vergleichen mit C# auf
    • Das ganze Sicherheitskonzept gehört deutlich besser erklärt
    • primitive Datentypen werden erwähnt, aber es gibt doch auch entsprechende Klassen für Integer, Float, Double usw.?
    • Wer hat eingeteilt, was ein "Grundkonzept" und was ein "Merkmal" der Sprache ist? Irgendwie scheint mir das etwas willkürlich aufgeteilt. Falls es entsprechende Quellen gibt, die sowas belegen, bitte als Einzelnachweis aufführen.
    • Swing/AWT wird erwähnt, aber was ist mit den ganzen anderen Features der Klassenbibliothek? RPC fällt mir da nur spontan als recht wichtig ein
    • Instantierungskonzepte fehlen komplett - ich denke, es ist schon wichtig, dass Klassen auch statisch instantiiert werden können.
    • Falls es für Unterthemen eigene Artikel gibt, sollte man doch zumindest im "Hauptartikel" eine grobe Zusammenfassung geben. Der Abschnitt zur Syntax ist jedenfalls ein Witz. Gerade, da für die meisten Leser die Syntax sehr wichtig sein wird.
    • Die Historie lässt sich bestimmt auch deutlich besser darstellen.
    • Der ganze "siehe auch"-Abschnitt gehört gelöscht und wichtige Links an den entsprechenden Stellen in den Artikel eingebaut.
Ich weiß, lesenswerte Artikel dürfen viel Fachsprache enthalten, aber ich denke, hier ist ein Leser, der absolut keine Ahnung von Programmiersprachen hat, einfach nur überfordert und auch der Leser mit Fachkenntnis wundert sich über den wüsten Informationshaufen. --Carstor|?|ʘ| 23:50, 7. Aug. 2007 (CEST)
Zusätzliche Anmerkungen: Der Artikel wertet gern mal (paar Beispiele: „Bemerkenswert ist auch die explizite Unterscheidung von Schnittstellen und Klassen“, „die fehleranfällige Zeigerarithmetik“, „Wer lieber einen Texteditor verwendet, findet in Emacs […] ein mächtiges Werkzeug.“, von dem OOP-Werbetextchen „Die Grundidee der objektorientierten Programmierung ist die softwaretechnische Abbildung in einer Art und Weise, wie wir Menschen auch Dinge der realen Welt erfahren. [usw]“ mal ganz abgesehen) und ist imo unangemessen unkritisch. Java hat nicht nur Fans.
Für Aussagen wie „Auf der anderen Seite führt diese Technologie […] dazu, dass Java-Bytecode genau so schnell wie native, kompilierte Programme ausgeführt wird.“ hätt ich auch gerne unabhängige Belege. In Summe: Fettes Contra. —mnh·∇· 06:37, 8. Aug. 2007 (CEST)
  • Contra, und zwar ein fettes. Neben dem, was mnh und Carstor schon geschrieben haben: Irgendwie wirkt der Artikel, als sei alles mögliche zusammengeworfen worden, was irgendwie zu "Java" gehört. Der Abschnitt "Merkmale der Sprache" ist genauso lang wie das IMHO höchst überflüssige Vergleich mit anderen Sprachen, der "Siehe auch"-Abschnitt ein Assoziationsblaster, die Literaturliste ist ein Sammelsurium von Java-Lehrbüchern ("Sehr gute Einführung!"), da tauchen Weblinks außerhalb des Weblink-Abschnittes auf, ... --Complex 09:31, 10. Aug. 2007 (CEST)
  • Ich hätte da so ein paar Kritikpunkte:
    • "Java-Programme werden in Bytecode übersetzt und dann in einer speziellen Umgebung ausgeführt" - das ist eine Implementationsmöglichkeit. Es ist aber keine Eigenschaft der Sprache, dass das so realisiert wird (Selbstwiederspruch mit "Compiler"-Abschnitt)
    • "Von Portierung spricht man... [selten]" - Java ist schon sehr gut was seine Abwärtskompatibilität angeht. Daher halte ich die Erwähnung von Portierung im Führtext für reichlich überflüssig.
    • "explizite Unterscheidung zwischen Schnittstellen und Klassen" - Naja, der Artikel tut ja so, als hätte Java das erfunden.
    • Bei "Merkmale der Sprache" oder "Syntax" könnte man noch anmerken, dass Java bewußt auf diverse nützliche Syntaxelemente zugunsten einer simplen Sprache verzichtet (non-member functions, funktionsparameter mit namen, deep copy, überladene/neudefinierte operatoren und so)
    • "Die Syntax von C# entspricht in großen Teilen der Syntax von Java" - In C+# sind eine Menge interessante Sachen möglich, die mit Java umständlich oder langsam sind
    • Irgendwie hört der Artikel mittendrin auf: Was'n mit Praxis? Für was für Softwareprojekte wird Java gerne Verwendet? Gibt es populäre Beispiele? Für was eignet sich Java eigentlich und für was nicht?
    • Was ist mit häufig zitierten angeblichen Problemen der Sprache? (zB die Sache mit der Geschwindigkeit)
    • Was für wesentliche Änderungen ergaben sich mit den einzelnen Versionen von Java?
    • Edit: Ach ja: Und natürlich die ganzen Punkte von Carstor noch.
Der Artikel mag ja für Einsteiger ganz Informativ sein, als Fortgeschrittener/Profi vermisse ich doch einiges. Daher ein klares Contra --John.constantine 21:52, 10. Aug. 2007 (CEST)
  • contra - aus den genannten Gründen. --Kurt Seebauer 10:47, 11. Aug. 2007 (CEST)

Paket

Sind die Pakete nicht gleich Paket (UML) --SonniWP2 19:20, 22. Aug. 2007 (CEST)

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)
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)
Häh? Ich verstehe gerade nicht, worauf du hinauswillst. --jpp ?! 12:12, 23. Aug. 2007 (CEST)

GNU GPL

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)

---> auf der englischen Wikipedia Seite von Java steht, dass Java unter der GPLv2 steht! Bitte ändern!

> Java steht bereits unter der GPLv2.Soleil88 13:47, 20. Okt. 2007 (CEST)

Anwendungsbereich

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)
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)

Tolle Meinungen, gehören aber nicht in einen Wikipedia-Artikel

"Java lehnt seine Syntax an die der Programmiersprache C++ an. Im Gegensatz zu C++ fanden jedoch komplexe Konstrukte wie Mehrfachvererbung oder die fehleranfällige Zeigerarithmetik keinen Einzug. Die interne Speicherverwaltung wird dem Java-Entwickler weitgehend abgenommen; dies erledigt die automatische Speicherbereinigung. Deshalb ist Java in vielen Fällen leichter zu handhaben als C++." - Das ist definitiv wertend und zudem unbelegt. --91.47.253.136 22:31, 6. Dez. 2007 (CET)

Hallo, wieso zitierst du hier den ganzen Absatz? Nur den letzten Satz könnte man als problematisch ansehen, er ist zwar nicht mit Einzelnachweisen belegt aber er braucht es IMHO nicht, denn dies ist eine recht allgemeine Aussage die aus der weiterführenden Literatur entnommen werden kann. Bezüglich der Wertung kann ich dir auch zustimmen, man kann ihn etwas neutraler formulieren. Oder willst du etwa behaupten, dass manuelle Speicherverwaltung des Heaps und Zeigerarithmetik, welche bei Java entfallen nicht kompliziert sind? Falls du tatsächlich den ganzen Absatz gemeint haben solltest und nicht nur den letzten Satz, dann würde ich dir dringend empfehlen die weiterführende Literatur zu lesen, die wohl ziemlich Zahlreich aufgezählt ist auch mit Online-Ausgaben. Viele Grüße -- Meph666 → post 23:42, 6. Dez. 2007 (CET)
Ich find den Satz ganz unproblematisch. Wenn eine bestimmte, nachweislich fehleranfälllige Routineaufgabe automatisch passiert, dann darf man das wohl als Erleichterung bezeichnen. 'In vielen Fällen' sollte doch wohl ausreichen, hier etwas den POV herauszunehmen.
Und 'unbelegt'? - Tut mir leid, aber das ist für mich common sense für jemanden, der sich mit der Materie beschäftigt hat. --INM 07:55, 7. Dez. 2007 (CET)
Meine Worte, INM :-) -- Meph666 → post 09:45, 7. Dez. 2007 (CET)

Mehrfachvererbung (2)

Den folgenden Absatz finde ich sehr missverständlich:

"Ferner unterstützt Java keine direkte Mehrfachvererbung (wie z. B. Eiffel), wobei diese jedoch über Schnittstellen simuliert werden kann."

Ich verstehe was der Schreiber damit sagen möchte, aber Schnittstellen können definitiv keine Mehrfachvererbung simulieren. Wenn ich zwei Klassen habe, kann ich keine dritte erstellen, die Eigenschaften und Methoden beider Klassen erweitern. Ich kann zwar die Methoden mehrere Schnittstellen implementieren, aber das ist einfach etwas anderes als Mehrfachvererbung. Ich würde den zweiten Satzteil ersatzlos löschen. Vielleicht währe es besser darauf hinzuweisen, dass auf die Mehrfachvererbung verzichtet wurde, da dieses Objektorientierte Mittel als umstritten gilt, was die Erzeugung einfachen/sauberen Codes anbelangt. Guru 23:20, 21. Dez. 2007 (CET)

Da stimme ich zu. --INM 10:53, 22. Dez. 2007 (CET)
Manche Problemstellungen, die in entsprechenden Programmiersprachen mittels Mehrfachvererbung angegangen werden, kann man auch durch der Verwendung mehrerer Schnittstellen lösen. Es ist nicht so dass die beiden Ansätze gar nichts miteinander zu tun hätten. Denn durch die Mehrfachvererbung werden auch die Schnittstellen der Elternklassen an die Kindklasse weitergegeben. Dasselbe geschieht beim Implementieren mererer Schnittstellen. Der Unterschied zur Vererbung ist bei Schnittstellen dass keine Attribute und keine Methodenimplementierungen an die abgeleitete Klassen weitergegeben werden.
Verbesserugnsvorschlag: „Ferner unterstützt Java keine direkte Mehrfachvererbung (wie z. B. Eiffel), wobei einige Problemstellungen, die damit gelöst werden, durch den Einsatz mererer Schnittstellen angegangen werden können. Dabei werden nur die Methodensignaturen an die abgeleiteten Klassen weitergegeben, jedoch keine Attribute und keine Implementierungen der Methoden.“
Wenn man Schnittstellen mit abstrakte Klassen vergleicht, dann fallen die Implementierungen der Methoden auch weg. Siehe auch Schnittstelle: „Das Implementieren einer Schnittstelle stellt eine Art Vererbung dar.“ Viele Grüße -- Meph666 → post 14:24, 22. Dez. 2007 (CET)
Der verbesserte Text ist fachlich korrekt formuliert und sagt genau das aus, was an dieser Stelle auch eigentlich gemeint ist. Ich währe für den neuen Text. Pflegt das wer ein? Guru 16:05, 26. Dez. 2007 (CET)

Lizenz

Im Zusammenfassungsfenster (rechts oben) steht unter Lizenz noch immer BCL. Ich bin mit dem ganzen Lizenzquatsch nicht firm, glaube aber vor ca. einem Jahr gelesen zu haben, dass Sun ihre Java-Implementierung unter die GPLv2 gestellt hat. Weiss da jemand etwas genaueres? Guru 16:26, 26. Dez. 2007 (CET)

Naja.. is eher die Frage was das überhaupt da soll.. eine _Programmiersprache_ unter GPL (oder sonst einer Lizenz)? Ich denke fast das ist noch aus der Zeit, wo es nur einen Artikel zu Java gab, und die Splittung in Technologie/Plattform/Sprache etc noch nicht bestand. Du schreibst ja auch: "ihre Java-Implementierung" - also höchstens das JDK oder die JRE von Sun, Java im Ganzen ist aber nicht gleich Sun.  :) Das Lizenzgebrösel gehört somit vermutlich eher, wenn überhaupt, in den Java-Plattform-Artikel. Das die Programmiersprache selbst lizenziert werden muss, halte ich für unwahrscheinlich, denn das schadet deren Verbreitung und Verwendung, zumal sich dann die Frage stellt: wer ist der Urheber der Programme, die in Java geschrieben werden.. die Programmiersprache selbst erreicht vermutlich nicht die Schöpfunghöhen-Hürde. --Schmiddtchen 说 18:20, 26. Dez. 2007 (CET)
Die binären Distributionen, beispielsweise die fertig compilierte und installierbare Laufzeitumgebung JRE [12], stehen nach wie vor unter der Binary Code License von Sun. Der größte Teil des JDK-Quellcodes steht jedoch unter der GPL v2 ([13]).--j ?! 18:42, 26. Dez. 2007 (CET)
Die Sprache selbst wird durch die Spezifikation festgelegt, die wiederum offenbar einer von Sun selbstgestrickten Lizenz unterliegt, die für mich ziemlich proprietär aussieht. Ich denke, hier müssen wir die Infobox tatsächlich korrigieren, bin aber noch etwas unsicher. --j ?! 18:47, 26. Dez. 2007 (CET)
Der Link bezieht sich auch wieder nur auf die Plattform, und nicht auf die Sprache.
Ich denke der Knackpunkt ist, dass es sich bei der Programmiersprache nicht um ein urheberrechtlich geschütztes Werk handelt, sondern um eine Standard (vgl ISO/DIN/EN), deren Standardisierungsinstanz Sun ist - da gibts den Community Process, mit dem auf die Sprachenspezifikation eingewirkt werden kann, und Sun, das neue Spezifikationsversionen als Referenz herausgibt (die dummerweise genauso heissen wie die jeweiligen Referenzimplementationen) - nur auf diesem Wege sind alternative Java VMs überhaupt denkbar.
Falls die Vermutung geäussert wird, dass für den Bau einer Java VM eine Lizenz für die Sprache von Sun erworben werden muss, würde ich mich spontan bereit erklären, dies zu Beginn des neuen Jahres mit Prof. Hochberger vom Institut für Mikrorechner hier an der TUD zu klären, dieserwelcher nämlich für die Autorenschaft an einer Java VM für Eingebettete Systeme verantwortlich zeichnet, welche wiederum auch kommerziell verwertet wird. Spätestens dann würde ja sicherlich eine Lizenz fällig werden, falls überhaupt irgendwo eine Lizenz fällig wird. Ich tippe aber wie gesagt darauf, dass hier Standardisierung mit Urheberrecht vermischt wurde. --Schmiddtchen 说 18:57, 26. Dez. 2007 (CET)
Oha, ich korrigiere mich: dein letzter Link bezieht sich doch ~irgendwie~ auf die Sprache, denn in Punkt 2 geht es um die Implementierung der Spezifikation und die Verbreitung dergleichen. Im Großen und Ganzen steht in dem Punkt aber nur, dass man die Spezifikation weder erweitern noch verändern darf, und dass Patentrechte an der Sprache unberührt bleiben. Sonst aber: perpetual, non-exclusive, non-transferable, worldwide, fully paid-up, royalty free, limited license (..) under any applicable copyrights or (..) patent rights it may have covering the Specification to create and/or distribute an Independent Implementation of the Specification.
Die ganze notwendige Unterscheidung in Sprache, Plattform und Implementierungen erleichtert die Grundfrage nicht gerade. :/ --Schmiddtchen 说 19:19, 26. Dez. 2007 (CET)

Einfluss auf PHP

Könnte man in der Infobox hinzufügen, dass Java auch PHP (siehe Objektorientierung in PHP5) beeinflusst hat? (Der vorstehende, nicht signierte Beitrag stammt von 212.23.103.64 (Diskussion • Beiträge) 14:51, 8. Feb. 2008)

Wenn du das durch Fachliteratur belegen kannst, dann ja. --Stefan Birkner 10:04, 9. Feb. 2008 (CET)
Tut mir leid, ich habe vergessen, dass sich hier bei wikipedia nur *** User herumschleichen, die von Tuten und Blasen keinerlei Ahnung haben - sich jedoch noch weniger bei den Themen auskennen, bei denen sie sich in den Diskussionen einmischen. JEDER Blindfisch sieht (sorry Stefan, du bist ausgenommen, denn du siehst nichtmal das) die Einflüsse von Java. Die syntaktische Handschrift ist so gut wie einmalig. Eure englischen Kollegen haben diese Info schon seit keine-Ahnung-wie-lange in ihrem Artikel (http://en.wikipedia.org/wiki/PHP). Nunja, deutsche Spießigkeit, wie sie leibt und lebt.
(nicht signierter Beitrag von 212.23.103.8 (Diskussion) )
Misstraue dem scheinbar offensichtlichen, denn es kann dich in die Irre führen. Beleidigungen werden dich übrigens (nicht nur hier) nicht viel weiterbringen. Wie wäre es, wenn du statt dessen mal ernsthaft recherchierst? Vielleicht gibt es ja irgendwo ein Interview mit den Schöpfern von PHP, in dem sie ihre Einflüsse preisgeben? --j ?! 20:27, 11. Feb. 2008 (CET)
Die „synktaktische Handschrift“ von Java ist so einmalig, dass man sofort den Unterschied zu C erkennt!? --Stefan Birkner 23:25, 11. Feb. 2008 (CET)
Ähm... ja? Tu' mir mal bitte den Gefallen und guck dir an, wie Klassen in C++ (die gab es in C noch garnicht) programmiert werden. Und dann sag mir wonach das im Vergleich zu PHP5 aussieht. (Btw. an den Löscher: Hier gibt es Leute [mind. 1 Person], die offen zugibt, nicht den Unterschied zwischen C und Java erkennen zu können. Trotzdem ist es dieser Person erlaubt, im Namen von wikipedia über eben diesen Sachverhalt zu treffen. Es geht hier um den Einfluss von Java auf PHP und dieser ist im Bereich der Objektorientierung seit PHP5 nicht zu übersehen. Wenn man sich einmal die Objektorientierung von C# und PHP5 im Vergleich ansieht, wird man eklatante Ähnlichkeiten sehen. Das ist das Resultat daraus, dass beide Sprachen die Objektorientierung in Anlehung an Java gestaltet haben. [Bevor Gegenäußerungen kommen, bitte erstmal den eigenen Eintrag zu C# lesen.])
Nebenbei wollte ich nochmal die Seite http://www.damninteresting.com/?p=406 anmerken, die sich einige Leute bei wikipedia einmal zu Gemüte führen sollten. (Btw.: Das ist sicherlich kein persönlicher Angriff, sondern eine Empfehlung.)
Weiß hier jemand, wer oder was Slashdot ist? Ich hoffe inständig darum! http://developers.slashdot.org/article.pl?sid=04/08/05/1915255
Zend, the Israeli company backing the development of PHP, promises on their web site that "full integration with Java will be closer than ever before."
With the release of PHP 5, it's apparent that the developers of PHP and the Zend Engine (essentially a single group) felt compelled to make PHP much more like Java with respect to object-oriented programming.
PHP's object model was re-written from the ground up and mimics the abstract properties of Java's object method. There are private and protected members and methods, abstract classes and interfaces, in practice, identical to Java's object model. The extent of the influence that Sun has on PHP today is clear. If you have experience with Java and PHP, reading the details of the object model reveals the absolute cloning of the Java object model within PHP 5. From throwing exceptions to static variables, PHP 5's object model mimics Java in concept all the way to the syntactical level.
(Die fettgedruckten Hervorhebungen sind von mir.)
Und als Nebeninfo: der Artikel ist von 2004.

Standardbibliothek

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 (nicht signierter Beitrag von 84.162.205.42 (Diskussion) )

Ansatzweise gibt’s das in Java Platform, Standard Edition. Ist aber noch nicht gut verlinkt. --j ?! 18:02, 16. Jun. 2008 (CEST)

genau soetwas meinte ich das sollte zumindest im Java Hauptartikel verlinkt werden! Ggf. noch ein paar Ergäzungen (siehe oben) .net und .xml sind schon wichtig. Ob da jemand Böse wird wenn ich die obigen ergänze? Falls es keine Antwort gibt mache ich es in 3 Tagen einfach :) 18:47, 16. Jun. 2008 (CEST)

Sei mutig! :-) --j ?! 20:27, 16. Jun. 2008 (CEST) PS: Deine Diskussionsbeiträge kannst du mit „--~~~~“ unterschreiben, oder mit einem Klick auf den zweiten Button von rechts über dem Bearbeitungsbereich.

Objektorientiert

"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. (nicht signierter Beitrag von User0816 (Diskussion | Beiträge) )

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)

"... Letztlich muss der Programmierer dafür sorgen, dass nicht mehr verwendete Objekte nirgends mehr referenziert werden..." Kann man denn überhaupt "nicht mehr verwendete Objekte" referenzieren? Ich meine wie soll das gehen, wenn man keine Referenzen mehr auf das Objekt hat????

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)

Java interpretiert

"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)
Java ist ein "Compreter". Der Quelltext wird durch einen Compiler in einen Zwischencode (bei Java "Bytecode" genannt) übersetzt (Quelle: [14]), welcher dann von einer Virtuellen Maschine interpretiert wird (Quelle: [15]). 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)

Ist der Java Hamster relevant genug um ihn zu erwähnen? --JoeKing1515 15:58, 25. Okt. 2008 (CEST)

Operatorüberladung

Hallo. Im Abschnitt C# fehlt, daß C# (wie auch vb.net) Operatorüberladung beherrschen. 213.39.171.68 17:34, 7. Apr. 2007 (CEST)

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)

Liste der Betriebssysteme unvollständig

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)

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)

Mehrfachvererbung

Der englische Begriff multiple inheritance bedeutet, dass jemand von mehreren Personen etwas erbt. Der deutsche Begriff mehrfache Vererbung bedeutet, dass jemand an mehrere Personen etwas vererbt. Deshalb ist mehrfache Vererbung eine unglückliche Übersetzung für multiple inheritance. In allen objektorientierten Sprachen kann eine Klasse ihre Elemente an beliebig viele andere Klassen vererben, ein solches mehrfaches Vererben (engl. multiple bequeathing) ist somit immer (auch in Java) erlaubt. Einige objektorientierte Sprachen erlauben es, dass eine Klasse mehrere andere Klassen beerbt. Ein solches mehrfaches Beerben (multiple inheritance) ist in Java nicht erlaubt.

Im Prinzip richtig, aber die Übersetzung hat sich im OOP-Jargon wohl so eingebürgert. Der Begriff Mehrfachvererbung zieht sich in diesem Zusammenhang auch durch die ganze Wikipedia. An der relevanten Stelle ist er aber zumindest gut erklärt. Diskussionsbeiträge bitte in Zukunft mit vier Tilden (~~~~) unterschreiben, das wird dann zu Benutzername und Datum expandiert. --Kurt Seebauer 15:12, 21. Apr. 2007 (CEST)
Ich halte die Aussage, daß Javaklassen nur einfach *Beerben* ;) könnten, für falsch. Es ist richtig, daß Java-Klassen jeweils nur höchstens eine andere Klasse beerben - also nur die Implementationen einer einzigen Klasse erweitern können. Es ist aber auch richtig, daß Java-Klassen von vielen Interfaces die Signaturen erben können:
 class Foo
  extends Bar
  implements Serializable, Comparable<Foo>
{ ... }
Siehe auch java.lang.String
Außerdem sind Vererbung und Zeigerarithmetik nach meinem Verständnis weniger Konstrukte, sondern vielmehr Konzepte. Ebenso halte ich die Aussage "fehleranfällige Zeigerarithmetik" für in diesem Zusammenhang a) falsch, b) zu stark wertend und c) unwichtig. Nicht die Zeigerarithmetik ist fehleranfällig, sondern vielmehr die Denkweise des Menschen in Bezug auf jene. Ich werde mir bei Zeiten evtl. auch einmal den Artikel Zeiger (Informatik) anschauen, der zumindest in diesem Punkt auch eher dürftig und wenig informativ zu sein scheint und genau die gleiche falsche Aussage bzgl. Fehleranfälligkeit trifft. 91.37.242.31 08:40, 5. Jan. 2009 (CET)

nahezu durchgehend OO und Komponente von Java Technologie

Derzeit steht als Einleitungssatz:

Java ist eine objektorientierte Programmiersprache und als solche ein eingetragenes Warenzeichen der Firma Sun Microsystems. Sie ist ein Bestandteil der Java-Technologie.

Finde das auch ok so. Benutzer:Phontoras möchte folgende 2 Punkte reinbringen (bitte korrigiere mich):

  • OO von Java stärker herausarbeiten
  • Java (Programmiersprache) ist Teil der Java (Technologie)

Vorschlag ist:

Java ist eine nahezu durchgehend objektorientierte Programmiersprache und als solche ein eingetragenes Warenzeichen der Firma Sun Microsystems. Sie ist eine wichtige Komponente der Java-Technologie.


  • Ich denke es ist nicht notwendig in der Einleitung bereits die nicht vollständige, aber doch sehr weit gehende OO von Java anzusprechen. "OO Programmiersprache" reicht mMn hier völlig. Unten wirds eh noch genauer beschrieben. Alles andere ist (für den Einleitungssatz) zu verwirrend.
  • Ich finds wichtig (schon im Einleitungssatz) zu erwähnen, dass Java (Programmiersprache) ein Teil der Java (Technologie) ist - damit man die 2 Dinge auseinanderhalten kann. Ich möchte aber das Wort "Komponente" vermeiden, da Komponente im IT Bereich damit meist Komponente im Sinne eines Komponentendiagrammes, also "Modul", "Applikationsteil", "Hardwarekomponente" gemeint ist. Darum finde ich "Bestandteil" besser. Vorschlag: Sie ist ein wichtiger Bestandteil der Java-Technologie.

--Sebastian.Dietrich 13:42, 9. Dez. 2009 (CET)

Das mit der Einleitung ist ok - man kann im Folgeteil sicherlich noch weiter darauf eingehen und dies vertiefen. Auf "Komponente" möchte ich mich natürlich auch nicht unbedingt festlegen. Mit der Umschreibung "wichtiger Bestandteil" ist im Bereich der Einleitung sicherlich auch ausreichend darauf hingewiesen, dass die Programmiersprache Java die eigentliche Basis aller Java-Technologien ist und diese zumeist in dieser Sprache realisiert sind. Danke und viele Grüße. -- Phontoras 15:21, 9. Dez. 2009 (CET)
Wo wir grad dabei sind - was bedeutet denn hier als solche? Die Objektortientiertheit hat doch nun mit Sun nix zu tun! Ich möchte mal vorschlagen, dieses verwirrende Füllsel wegzulassen. --INM 16:51, 9. Dez. 2009 (CET)
Sorry, aber das verstehe ich nicht ganz. Fakt ist doch, dass Java generell weitgehende objektorientierte Eigenschaften und Möglichkeiten zur Verfügung stellt. Um aber objektorientierte Lösungen zu realisieren, muss man schon objektorientiert denken und vorgehen. Dies liegt letztendlich primär nicht an Sun oder der Programmiersprache, sondern eher wohl an den jeweiligen Denkweise der Architekten und Realisierer. -- Phontoras 17:59, 9. Dez. 2009 (CET)
Sorry, das hatte ich wohl missverstanden. -- Phontoras 21:39, 9. Dez. 2009 (CET)


Passen die in Java7 kommenden Closures so derart in das OO-Bild? Die Closures kommen doch eigentlich aus der funktionalen Richtung. --Locked 17:02, 9. Dez. 2009 (CET)
Zu diesem Thema gibt es genügend Diskussionen. Ob die kurzfristige Entscheidung, Closures in Java 7 zu implementieren, die Richtige war oder nicht - sollte jeder selbst entscheiden. Es kann auch jeder entscheiden, ob er solche Features dann real nutzt oder nicht. Meiner Meinung nach sollte man auch nicht päpstlicher als der Papst sein - auch in Bezug auf die Objektorientierung sind in der realen täglichen Praxis immer Kompromisse angesagt. Leider haben sich langfristig gesehen auch keine rein objektorientierten Sprachen wie Smalltalk, etc. durchgesetzt.
An dieser Stelle geht es letztendlich auch lediglich um einen konkreten Hinweis auf die ausgeprägten objektorientierten Eigenschaften von Java und die sind sicherlich nicht strittig und sollten daher auch herausgestellt werden. -- Phontoras 17:59, 9. Dez. 2009 (CET)

@"als solche" - denke auch dass man das wegnehmen kann- Java wäre ja auch eingetragenes Warenzeichen von Sun, wenn es keine OO Programmiersprache wäre. Ich habs jetzt mal entsprechend geändert - hoffe das ist auch in Eurem Sinne.

@Closures - passen denke ich gut ins OO-Bild. In Smalltalk wurde immer gesagt "auch Funktionsblöcke sind Objekte", d.h. Closures waren ein Zeichen für besonders tolle OO. Ich persönlich halte (in Java) nix davon. Die Syntax ist grauslich & erschwert nur den Einstieg ohne wirklich was zu bringen. --Sebastian.Dietrich 18:06, 9. Dez. 2009 (CET) P.S. Mir ist neu, dass Closures jetzt doch kommen. Lt. http://openjdk.java.net/projects/jdk7/features/ sind sie nicht wirklich dabei --Sebastian.Dietrich 18:09, 9. Dez. 2009 (CET)

@ProContra Closures: Moment, nicht abdriften. Es geht hier ausschließlich um die Frage ob Closures ins OO-Konzept passen oder ob sie funktional sind. Die Frage ob man Closures mag oder nicht ist an dieser Stelle absolut irrelevant. Sind Clusoures also OO? Wenn "funktional", dann wäre der oben genannte Punkt "OO von Java stärker herausarbeiten" eigentlich obsolet. Wenn sie ins OO-Bild passen, kann man den OO-Bezug auch gerne stärker herausarbeiten. Falls es keine wirkliche Definition dazu gibt .. tjo - dann enthalte ich mich eines Urteils mangels Nachweisen. Dass Closures wirklich kommen ging vor wenigen Wochen durch die (sozialen) Medien: zB hier, hier und hier --Locked 20:01, 9. Dez. 2009 (CET)

Danke für die Info... Ich denke Closures sind nicht wirklich einem Konzept wie OO oder Funktional zuzuordnen. Aber auch wenn sie ein typisches OO Konzept wären ist Java dennoch nicht 100% OO. Darum ist es mMn nicht nötig den Punkt "Java ist eine OO Sprache" in irgendeine Richtung zu verändern. --Sebastian.Dietrich 21:06, 9. Dez. 2009 (CET)

@Closures: Ich glaube jetzt ist die Thematik wohl insgesamt etwas abgedriftet. Eigentlich ging es doch erst einmal nur darum, in der Einleitung und ggf. im Artikel etwas stärker herauszustellen, dass Java eine objektorientierte Sprache ist - gut es ist sicherlich keine "rein" objektorientierte Sprache. Aber das wurde ja bereits festgestellt. Nunmehr sind wir aber quasi dabei angekommen, ob bei einer zukünftigen Implementierung von Closures in Java 7, die Objektorientierung von Java vielleicht bereits in Frage gestellt sein könnte oder nicht. Das passt irgendwie nicht ganz zusammen. Closures sind in vielen modernen objektorientierten Sprachen implementiert und wenn man es genau nimmt, stellen Closures eine Art Kapselung dar - was damit wohl sicherlich auch in irgend einer Form der Objektorientierung zugeordnet werden könnte. Aber das ist wohl wie in vielen Fällen sicherlich reine Ansichts- und Geschmackssache. Ich werde mich aus der weiteren Diskussion zu diesem Thema erst einmal ausklinken und bedanke mich für Eure Beiträge. -- Phontoras 21:39, 9. Dez. 2009 (CET)

"Aber das ist wohl wie in vielen Fällen sicherlich reine Ansichts- und Geschmackssache." Ja das fürchte ich auch. Ich glaubte mal ein Blogpost von James Gosling gelesen zu haben, indem er gesagt hat, dass er Closures als funktionales Konzept in Java sehr begrüßt - genialerweise finde ich die die Quelle aber nicht wieder :-/ Weitestgehend OO trifft bei Java vielleicht am besten zu. Ein Smalltalk Fan hat mal die ganz andere Richtung einngeschlagen und gemeint, Java wäre GARNICHT OO, weil ja nicht mal(!) die Operatoren (+,-,..) Objekte wären und es auch noch primitive Datentypen gibt (int, float, ...). Ganz unrecht hat er sicherlich nicht. --Locked 08:59, 10. Dez. 2009 (CET)
"Ein Smalltalk Fan hat mal die ganz andere Richtung einngeschlagen und gemeint, Java wäre GARNICHT OO,... (+,-,..) ... int, float, ...". Wenn dies so wäre, dann hätte dies aber sicherlich in keinster Weise, Auswirkungen auf die Popularität von Java genommen - wenn man schon einmal einen diesbezüglichen Vergleich zwischen Java und Smalltalk anführen würde ;-) Aber man soll "Fans" gleich welcher Destination ruhig einige kleine Freuden gönnen - die Realität der Projektpraxis ist zuweilen schon hart genug. Es wird wohl in der heutigen Zeit sicherlich kein verantwortlicher Architekt darüber philosophieren, ob man das objektorientierte Java und dessen assoziierte Frameworks zur Implementierung lieber ausschließen sollte, weil Operatoren nicht als Objekte zur Verfügung stehen, es primitive Datentypen gibt oder demnächst Closures Bestandteil sein werden. Entscheidungen über den Einsatz von Basistechnologien finden heutzutage einige Ebenen über den relativ nebensächlichen Ausprägungen einer Programmiersprache statt (EDIT: womit ich sicherlich nicht grundsätzliche objektorientierte Eigenschaften wie Kapselung, Vererbung, Polymorphie, etc. meine). -- Phontoras 10:09, 11. Dez. 2009 (CET)

Vielleicht sollte das ganze jetzt nicht in Wortklauberei ausarten und das "Änderungen hin und Änderung her"-Spiel eingeleitet werden. Ich bin der Meinung, dass "Java ist eine objektorientierte Sprache..." sicherlich ausreichend ist - hatte ich auch bereits weiter oben geschrieben und wir sollten es jetzt wirklich dabei belassen ... Vielen Dank für Euer Verständnis. -- Phontoras 12:46, 11. Dez. 2009 (CET)

Bin ganz Deiner Meinung. --Sebastian.Dietrich 16:39, 11. Dez. 2009 (CET)

Vorlage Diskussion:Infobox Programmiersprache

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)

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)

Weitere Javaliteratur

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)
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)

Wikibooks-Link

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)

Danke --Sebastian.Dietrich 09:45, 22. Dez. 2009 (CET)

Erscheinungsjahr '95?

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)

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)
Dachte mir doch dass sich da jemand was dabei gedacht hat. Danke für dei Erklärung! --Locked 13:19, 22. Dez. 2009 (CET)

Verwandte Artikel

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. (nicht signierter Beitrag von 134.245.253.156 (Diskussion) )

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)
Ist denke ich inzwischen ohnedies gut so. --Sebastian.Dietrich 12:53, 5. Jan. 2010 (CET)

Framework Beispiele

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))

Hab den gesamten Abschnitt "Siehe auch" aufgeräumt & nur auf die wichtigsten Punkte reduziert. --Sebastian.Dietrich 22:00, 11. Jan. 2010 (CET)

Entfernung des DMOZ-Links

Ich halte das Entfernen des DMOZ-Links für einen strategischen Fehler, und zwar aus folgenden Gründen:

  1. 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.
  2. 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)

Java ist langsamer

http://verify.stanford.edu/uli/java_cpp.html(nicht signierter Beitrag von 149.211.153.99 (Diskussion) 09:48, 29. Jun. 2010 (CEST))

Schau mal auf das Datum. --Euku:⇄ 09:55, 29. Jun. 2010 (CEST)
@Euku: Nur weil ein Beleg alt ist, wird er nicht automatisch falsch. Java benötigt immernoch eine Laufzeitumgebung und C++ wird nach wie vor direkt für eine Plattform compiliert. Sollte sich die Leistungsfähigkeit merklich verändert hat, muss es dafür einen Beleg geben, der dem von IP 149.211.153.99 angegeben wiederspricht. -- 195.141.2.13 15:15, 21. Okt. 2010 (CEST)
So weit ich weiß, ist die JVM in C geschrieben und C ist schneller als C++. Ich glaube Berichte gelesen zu haben, die zeigen, dass Java an C++ herankommen kann, habe aber nur dies schnell gefunden, was zeigt, dass C++ 2 bis 3 mal so schnell wie Java ist http://bruscy.republika.pl/pages/przemek/java_not_really_faster_than_cpp_160-430.html .--Karolherbst 16:24, 21. Okt. 2010 (CEST)
Es sei angemerkt, dass diese Test auf dem GCC basieren. C++ Programme, die mit dem ICC kompiliert werden, haben dann noch mehr Performance, was dann Java deutlich langsamer macht. --Karolherbst 16:32, 21. Okt. 2010 (CEST)

Sorry, aber dass Java langsamer als C oder C++ sein sollte ist ein uralter Mythos. Das stimmte noch 1996, als Java interpretiert wurde, aber spätestens seit Java 1.2 ist das falsch. Dazu gibts hunderte Untersuchungen und Gegenbeweise. Zwei davon hab ich in den Artikel eingefügt. Natürlich kann jeder jederzeit einen Microbenchmark schreiben, der zeigt, dass Java 100 mal langsamer (oder auch schneller) als C / C++ ist. Aber die Praxis schaut anders aus: Es ist nicht die Sprache, die ein Java Programm langsam macht, sondern schlechte Programmierung (dasselbe gilt natürlich analog für langsame C / C++ Programme). --Sebastian.Dietrich ✉ 22:29, 21. Okt. 2010 (CEST)

Java ist langsamer als C oder C++, weil die JVMs auf C oder C++ aufsetzen und der Bytecode erst bearbeitet werden muss. Java kann nicht schneller werden als Systemprogrammiersprachen, schon allein aus dem Grund, dass Java nicht als Maschinensprache vorliegt. Aber du hast Recht, wenn du sagst, dass Java die letzten Jahre stark aufgeholt hat, darum habe ich auch den Benchmark hier reingetan, der zeigt, dass C++ ca. 2-3 mal so schnell ist in Microbenchmarks, was auf eine Anwendung betrachtet ein sehr kleiner Unterschied ist. Also wir nehmen im Optimalfall sehr gut geschrieben C und Java Programme an vergleichen diese und werden bemerken, dass Java langsamer ist, besonders weil die GUI nur über JNI oder Softwaretechnisch erst gebaut werden muss. Im Endeffekt jedoch ist das Programmieren mit Java einfacher, da man sich um Pointer und andere Dinge nicht kümmern muss, was Java wiederum schneller macht. Aber dennoch ist Java schon allein von der Konzeption her etwas langsamer als C++. --Karolherbst 10:16, 22. Okt. 2010 (CEST)
Es sei angemerkt, dass deine Quellen von 2003 (Java 1.4, Gcc 3.2 ) und meine von 2008 (Java 6, Gcc 4.3) ist. Ich muss nicht sagen, dass in der IT Welt 5 Jahre eine lange Zeit ist. --Karolherbst 10:23, 22. Okt. 2010 (CEST)
Doch, manchen Menschen muss man das erklären. Die haben sich ihre Meinung gebiltet, und lassen sich von so was banalem wie Fakten nicht überzeugen... --P.C. ✉
Okay, dann nochmal 2 Links die das Gegenteil beweisen, nachdem MArkso nett war, die Version zurückzusetzen http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=javasteady&lang2=gcc http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=javasteady&lang2=gpp (nicht signierter Beitrag von Karolherbst (Diskussion | Beiträge) 15:09, 22. Okt. 2010 (CEST))
Wie wäre es mit der Seite? Hier schlägt Java (-server) in manchen Benchmarks C/C++ (gcc)? --Mark Nowiasz 15:03, 22. Okt. 2010 (CEST)
Ja in der Codegröße scheint Java wohl besser zu sein, wirklich ein wichtiges Kriterium. Und mit manchen meinst du wohl in 5% der Tests, aber das Java in anderen Test ca 10 mal so langsam ist, scheint ja egal zu sein. Java ist nicht schneller, selbst das englische Wiki sagt, dass Java um den Faktor 1-4 langsamer ist als C oder C++ --Karolherbst 15:07, 22. Okt. 2010 (CEST)
Wer lesen kann, ist klar im Vorteil. Schau Dir java6 -server vs gcc, Benchmark "k-nucleotide" an.--Mark Nowiasz 15:11, 22. Okt. 2010 (CEST)
k-nucleotide
Java 6 -server 49.46s
C++ GNU g++ 13.66s
jo Java ist schneller, klar. Und wenn du den C Test meinst, Java verbraucht dafür 3 mal so viel RAM bei nahezu gleicher Geschwindigkeit. Ist dafür in allen anderen Benchmarks langsamer --Karolherbst 15:14, 22. Okt. 2010 (CEST)
Von welcher Hardware redest Du? Auf der 32bit-Hardware ist Java schneller, auf der 64bit-Hardware ist Java beim n-body-Problem schneller. Einfach mal genau hinschauen, danke. --Mark Nowiasz 15:18, 22. Okt. 2010 (CEST)
habe ich bereits schon gezeigt: http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=javasteady&lang2=gcc http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=javasteady&lang2=gpp besser sind aber http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java und http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=gcc --Karolherbst 15:19, 22. Okt. 2010 (CEST)
(BK) Ja. Es kommt immer auf den Benchmark an. Wie gesagt: Es gibt gute und schlechte Programme... die Frage, ob VM oder compile schneller ist, ist völlig falsch, da der Just in Time Compiler laufzeitoptimierungen durchführt und so den von Dir geschriebenen Code abwandelt. Und das nicht statisch, sondern dynamisch anhand der beobachteten Laufzeitergebnisse. Beispielsweise: Du schreibst eine "Warteschleife"... mit for {int i=0;i<MAXINT;i++){} und überprüfst, wie schnell die verschiedenen Programme sind... Nur: Es kann passieren, dass der JIT diese Schleife in eine Zuweisung (i=maxint) umwandelt, weil er sieht, dass da nichts anderes drin ausgeführt wird. Das Schreiben eines Benchmarks für Java ist nicht trivial. --P.C. ✉ 15:24, 22. Okt. 2010 (CEST) Ist natürlich nicht mehr "Jit" sondern "HotSpot"... ist aber kein Unterschied... --P.C. ✉ 15:27, 22. Okt. 2010 (CEST)

Nachtrag: Diese Diskussion hat nichts mehr mit dem Artikel zu tun, sondern nur noch mit "Meine Sprache ist Besser". Tatsache ist, die Aussage, das Java "allgemein" langsamer ist, als nativer Code ist so nicht zu halten. --P.C. ✉ 15:27, 22. Okt. 2010 (CEST)

leider programmiere ich zur Zeit hauptsächlich in Java und mag C++ aus diversen Gründen nicht. Ich warte nur noch, dass ein objektiver Blick hier rüber gelegt wird. Sonst ist auch das sehr interessant: http://en.wikipedia.org/wiki/Java_performance#Comparison_to_other_languages . Aber ist mir jetzt auch egal, soll ein andere entscheiden, was nun richtig ist. --Karolherbst 15:36, 22. Okt. 2010 (CEST)
ACK, von mir deshalb auch ein EOD zu dem Geraffel - ich bin eigentlich auch aus dem Alter "Amiga ist besser als Atari" raus :-) --Mark Nowiasz 15:31, 22. Okt. 2010 (CEST)

Ein Punkt noch: Es taucht immer wieder die Aussage auf "Java kann nicht schneller als X sein, da die JVM auf C oder C++ aufsetzt und der Bytecode erst bearbeitet werden muss". Das stimmt, allerdings nur für einzelne Befehle. Was aber, wenn in Java ganze Befehle weggelassen werden könnten oder auf Zeiten verschoben werden, wo weniger zu tun ist? Beides kann die JVM. Ersteres durch Laufzeitwissen und zweiteres durch Garbage Collection. z.B. kann eine JVM zur Laufzeit Variablen (die z.B. beim Programmstart aus einer Config-Datei geladen werden) in Konstanten umwandeln (d.h. Schleifen & if-Abfragen auflösen bzw. wegschmeissen). --Sebastian.Dietrich ✉ 18:52, 22. Okt. 2010 (CEST)

Da wäre folgendes noch interessant zu nennen: http://de.wikipedia.org/wiki/Low_Level_Virtual_Machine und in Bezug auf Java: http://de.wikipedia.org/wiki/Low_Level_Virtual_Machine#vmkit ich hoffe, dass sich LLVM am Ende durchsetzen wird, dann gibt es keine Diskussionen wie obige mehr. Aber wir werden sehen. --Karolherbst 12:31, 25. Okt. 2010 (CEST)

kritik?

gibt es keine kritik bzw. keinen kritik-abschnitt über java? die perfekte sprache ist java laut einigen gerüchten nicht gerade... 79.226.170.48 08:39, 26. Okt. 2010 (CEST)

Gute Idee - aber vermutlich nicht leicht realisierbar. Eine Kritik an einer Sprache ist mMn nicht zulässig - was wäre z.B. die Kritik an der deutschen Sprache? "Sätze/Befehle in Deutsch/Java sind länger als Sätze auf Englisch/C++" - ja aber ist kürzer wirklich besser? Die perfekte (Programmier-)sprache gibts einfach nicht. Wäre auch die erste Programmiersprache mit einem Kritik Abschnitt. --Sebastian.Dietrich ✉ 00:18, 27. Okt. 2010 (CEST)
Naja, anders als bei natürlichen Sprachen, bringen PLs ja ihre eigene Semantik mit, ohne die nun wirklich keine Aussage über die Sprache getroffen werden könnte. Mit Semantik aber kann man das Konzept auch kritisieren. Ein bisschen kritische Auseinandersetzung findet schon im Artikel statt (keine Mehrfachvererbung, nicht voll OO), aber die Formulierungen tendieren zum Unter-den-Teppich-Kehren. Ist Auto(un)boxing ein vollwertiger Ersatz für einheitliche OO? Verliert man mit den Pointern nicht auch praktische "Hacks" (Funktionspointer)? Dass Aufwärtskompatibilität besteht, fehlt, logischer Weise auch die damit verbundenen Probleme (type erasure bei Generics). Gerade wenn der Abschnitt 1 ("Grundkonzepte") so breit getreten wird, sollten die dort genannten Ziele der geläufigen Kritik gegenübergestellt werden. „Sicherheit Dafür stehen Konzepte wie der Code-Verifier[...]“ kann man ja so nicht stehen lassen. Gibt es für diese Formulierung überhaupt Belege? --Zahnradzacken 10:30, 27. Okt. 2010 (CEST)
Genau das meinte ich "keine Mehrfachvererbung" ist beispielsweise für einige ein Nachteil, für andere ein Vorteil. In Java wurde das ja bewusst weggelassen, ebenso Pointer (u.a. um eben die praktischen aber unwartbaren Hacks zu vermeiden), OperatorOverloading (detto).... In den Abschnitt Kritik müsste also "Java kann kein X - das ist bewusst so gewählt worden und wird von vielen als Vorteil empfunden".
@voll OO - das ist natürlich Auslegungssache. Java gehört zu den OO Sprachen, bei denen fast alle (bis auf vielleicht Smalltalk) für Puristen als "nicht voll OO" gelten.
@Gundkonzepte & Belege - die hier genannten Konzepte & Erläuterungen dazu stammen aus den referenzierten Artikeln. Sag doch konkret, welche Punkte dMn noch belegt werden müssten. Das mit den Code-Verifiern etc. kann man z.B. bei der JVM nachlesen.
P.S. Bin übrigens voll bei Dir: den Artikel könnte man noch deutlich verbessern. Die Abschnitte nach Abschnitt 1 sind weder vollständig noch gut gegliedert. Der Abschnitt "Merkmale der Sprache" Dinge, die oben schon beschrieben wurden. etc. --Sebastian.Dietrich ✉ 17:48, 27. Okt. 2010 (CEST)
Achso, ich habe ganz vergessen zu erwähnen, dass ich bezüglich eines Abschnitts Kritik auch skeptisch bin, weil das dann womöglich zusammengebastelt und aus dem Zusammenhang gerissen ist (oder dem vorbeugend Aussagen aus anderen Abschnitten wiederholt werden müssten). Ich stimme da ganz zu, dass eine differenzierte Darstellung im Zusammenhang sinnvoller ist ("Mehrfachvererbung wurde vermieden, weil ..., wird aber von manchen vermisst, weil ...").
@voll OO – nur ein Beispiel tendenziell kritischer Formulierungen, die bereits im Artikel vorhanden sind.
@Grundkonzepte: die in diesem Abschnitt angegebenen Quellen habe ich nach "verifier" erfolglos durchsucht. Die Argumentation pro "sicher" findet in den Quellen auf etwas anderer Ebene statt. Wenn ich die Stelle übersehen habe, wäre ich über eine kleine Orientierungshilfe dankbar.
Schade nur, dass ernsthafte Verbesserungen aufwändig sind. --Zahnradzacken 21:10, 27. Okt. 2010 (CEST)
@verifier - ich hab mal ein bisschen recherchiert - der Teil des Textes ist schon seil vor 2006 im Artikel und die Quellen sind erst viel später reingekommen. Ich denke wir können den Punkt mit dem verifier getrost löschen (was ich soeben getan habe). --Sebastian.Dietrich ✉ 21:53, 27. Okt. 2010 (CEST)

Ich finde unter Kritik könnte auch Dinge wie die OpenSource Geschichte von Java beinhalten. Also auch Dinge, die nicht die Sprache an sich betreffen, sondern auch das, was rundherum geschieht. Zb: Was passierte mit Java, seitdem Sun von Oracle gekauft wurde. Was sagt die OS-Community dazu, etc, etc. --Karolherbst 12:31, 28. Okt. 2010 (CEST)

Referenzen vs. Zeiger

Bitte hier um Diskussion - "was hat Java, Referenzen oder Zeiger"? Zur Definition: Referenz (Programmierung): "Im Gegensatz zu expliziten Zeigern ist die Adresse selbst nicht mehr änderbar und verborgen, insbesondere sind Operationen auf der Adresse (Zeigerarithmetik), die oft fehlerträchtig sind, nicht möglich." Das spricht für mich eindeutig dafür, dass Java Referenzen hat (so wie auch vermutlich 100% der Literatur zu Java). --Sebastian.Dietrich ✉ 17:19, 5. Nov. 2010 (CET)

Bei Referenzen könnte man eine swap-Funktion schreiben:
public void swap(Object a, Object b) {
   Object t = a;
   a = b;
   b = t;
}
Schöner ist es in der von mir hier verlinkten Quelle beschrieben. Denn bei Java werden nicht die Objekte als Referenz an die Methoden/Funktionen übergeben sondern nur Pointer. Nach dem Aufruf von swap(c,d) sind die außerhalb der Funktion definierten Objekte immer noch die selben. Java verwendet also immer "copy by value", lässt lediglich die Zeigerarithmetik weg, wodurch immer gültige Zeiger (Ausnahme null) entstehen. Referenzen, die swap erlauben würden, gibt es gar nicht. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 17:56, 5. Nov. 2010 (CET)
Nachtrag: Dies ist leider ein vielfach wiedergegebener Irrtum, der auf dem Marketing von Java beruht (Zeiger = Böse, Instabil, Unsicher). In der Sprachdefinition ist es ja selbst als Zeiger bezeichnet. [16]
When the method or constructor is invoked (§15.12), the values of the actual argument expressions initialize newly created parameter variables, each of the declared Type, before execution of the body of the method or constructor. The Identifier that appears in the DeclaratorId may be used as a simple name in the body of the method or constructor to refer to the formal parameter.
Das die Dinger nun überall Referenzen genannt werden, ist schlichtweg inkorrekt. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 18:03, 5. Nov. 2010 (CET)
Wieso denkst Du, dass man mit Referenzen Swap Funktionen schreiben kann? Das ist keine definierte Eigenschaft von Referenzen. Das was Du ansprichst ist die explizite Designüberlegung, dass in Java Parameter (&somit auch Referenzen) shallow-kopiert werden (d.h. es gibt eigentlich nur "call by value" und kein "call by reference"). Das gilt für Referenzen, wie auch für Primitive. Dass man in Java keine Swap Methode schreiben kann heisst ja auch nicht, dass es in Java keine Primitive gibt.
Mit Zeigern kann man weit mehr als mit Referenzen (Referenzen sind ja quasi eingeschränkte Zeiger):
  • die physikalische Adresse ausgeben
  • Zeigerarithmetik betreiben
  • auf beliebige andere Objekte (anderen Typs) oder auch Methoden oder auch wiederum Pointer oder auch ins Nirvana zeigen lassen
  • sie verwenden, ohne dass sie initialisiert sind
das alles kannst mit Java Referenzen nicht. Darum hat Java Referenzen und keine Zeiger (und eine gewöhnungsbedürftige Parameterübergabe, was aber ein anderes Kapitel ist). --Sebastian.Dietrich ✉ 19:05, 5. Nov. 2010 (CET)
Referenzen wirken sich auch auf Bereiche Außerhalb der Funktion aus. So wäre es möglich die Objekte auch außerhalb zu tauschen, was aber nicht geht. Dementsprechend sind es keine Referenzen, sondern nur Zeiger ohne (sichtbare) physikalische Adresse und eingeschränkter (nicht vorhandener) Arithmetik, da sie eben per copy-by-value übergeben werden. Referenzen sind by default nicht copy-by-value sondern copy-by-reference --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 19:11, 5. Nov. 2010 (CET)
Auch das macht keine Referenzen aus. Mit Pointern kannst z.B. auch swaps machen, also sind lt. Deiner Diktion Pointer Referenzen. --Sebastian.Dietrich ✉ 19:44, 5. Nov. 2010 (CET)
Ich bin mir sicher, ihr versteht beide, was da intern abgeht, nur habt ihr verschiedene Auffassungen der Begriffe. Die Diskussion ist deshalb bestimmt nur dann fruchtbar, wenn hier Begriffsdefinitionen auf den Tisch gelegt werden. Die Wikipediaartikel dazu sind leider nicht besonders tauglich, denn in Referenz (Programmierung) steht das obige Zitat von Sebastian.Dietrich, was sich so liest, als seien Referenzen eingeschränkte Zeiger. In Zeiger (Informatik) heißt es dagegen: „Ein Zeiger ist ein Spezialfall und in einigen Programmiersprachen die einzige Implementierungsmöglichkeit des Konzepts einer Referenz.“ Vielleicht ganz tauglich ist aber: „Eine Referenz repräsentiert einen Verweis auf ein Objekt.“ So gesehen gibt es zwar in Java Verweise auf Objekte (nämlich das, womit die "Swap"-Funktion arbeitet), der Zugriff auf die Verweise ist aber nur über Referenzen möglich, zum Beispiel Object a, Object b oder Object t. Aber ohne Begriffsdefinition ... --Zahnradzacken 20:53, 5. Nov. 2010 (CET)

@Sebastian.Dietrich: Nein kannst du nicht. Ein einfaches Beispiel im C-Code sollte das zeigen, wobei hier ein type mit einem Objekt in Java vergleichbar ist, da in C auch die Primitive als Objekte bezeichnet, bzw. als solche verwendet werden können. 

void swap1(type &a, type &b) {                  // Hat kein Äquivalent in Java
    type t = a;
    a = b;
    b = t;
}
                                                // Äquivalent in Java
void swap2(type *a, type *b) {                  // void swap2(Double a, Double b) {
    type t = *a;                                //     double t = a.getValue();
    *a = *b;                                    //     a.setValue(b.getValue());
    *b = t;                                     //     b.setValue(t);
}                                               // }

int main() {
    type A = 1;                                 // In Java nicht möglich (Primitiv)
    type B = 2;
    swap1(A, B); 
    // A ist nun 2 
    // B ist nun 1
                                                // Äquivalent in Java
    type *C, *D;                                //
    C = (type *) malloc(sizeof(type)*1);        // Double C = new Double();
    *C = 3;                                     // c.setValue(3)
    D = (type *) malloc(sizeof(type)*1);        // Double D = new Double();
    *D = 4;                                     // d.setValue(4)
    swap2(&C, &D);                              // swap2(C,D);

    // Danach sind die Pointer/Objekte C und D gleich geblieben, ihr Inhalt wurde aber vertauscht.

    type E = 5;                                 // In Java nicht möglich, da es keine solche flache 
    type F = 5;                                 // Allokation für Objekte gibt, während sich von 
    swap2(&E, &F);                              // Primitiven keine Referenzen/Zeiger/Adressen besorgen lassen
}

Ich hoffe es ist nun klar geworden, warum bei Java keine Referenzen verwendet werden sondern kastrierte Zeiger. Es ist nämlich nicht möglich swap1 zu schreiben, egal ob Objekt oder Primitiv. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 21:33, 5. Nov. 2010 (CET)

Der Vergleich hat einen kleinen Haken: In Java gibt es keine Methode der Art Double.setValue(double). swap2 besitzt daher auch in Java kein Äquivalent. Auch entspräche der manuelle Austausch der Objektinhalte nicht wirklich dem Tausch der Zeiger auf die Objekte... (nicht signierter Beitrag von 93.122.68.162 (Diskussion) 13:35, 8. Feb. 2011 (CET))

Definition von Zeiger und Referenz

Zeiger
Ein Zeiger ist eine Variable die indirekt auf die Position eines anderen Datenstücks verweist. Der Wert eines Zeigers ist dabei häufig die Speicheradresse der interessanten Daten. Einige Programmiersprachen erlauben es diese Position zu ändern, andere nicht.
Referenz
Eine Referenz ist ein anderer Name (Alias) für eine Variable. Jede Änderung der Variable ändert auch direkt den Inhalt der ursprünglichen Variable.

Geht man nach dieser Definition, dann verwendet Java keine Referenzen, sondern nur Pointer für Objekte. Dies resultiert allein daraus, das wenn wirklich Referenzen verwendet würden und man swap() aufruft sich auch der Inhalt der übergebenen Variablen sich ändern müsste, was er im Falle von swap() aber nicht macht. Daraus folgt, das Java Zeiger anstatt Referenzen verwendet, die aber nicht durch Arithmetik verändert werden können. In diesem Zusammenhang wird auch klar warum selbst Sun (heute Oracle) in der Sprachdefinition festhielt (sie haben sie ja entwickelt), das es Pointer wären.

"The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object." [17]

Ich hoffe das ist jetzt genug der Aufklärung. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 22:20, 5. Nov. 2010 (CET)

Danke für die "Aufklärung". Das Problem damit ist, dass das Deine persönliche Definition ist und somit nur beschränkt tauglich. Sie widerspricht auch den in WP Artikel stehenden Definitionen.
Ich persönlich denke, dass die Definitionen in der deutschen und englischen WP korrekter sind:
en:Reference (computer science): "a reference is a value that enables a program to indirectly access a particular data item" und weiters "Pointers are the most primitive. Due to their intimate relationship with the underlying hardware, they are one of the most powerful and efficient types of references. However, also due to this relationship, pointers require a strong understanding by the programmer of the details of memory architecture."
Referenz (Programmierung): "Eine Referenz repräsentiert einen Verweis auf ein Objekt. Im Gegensatz zu expliziten Zeigern ist die Adresse selbst nicht mehr änderbar und verborgen, insbesondere sind Operationen auf der Adresse (Zeigerarithmetik), die oft fehlerträchtig sind, nicht möglich."
en:Pointer (computing): "A pointer is a simple, less abstracted implementation of the more abstracted reference data type."
Zeiger (Informatik): "Ein Zeiger ist ein Spezialfall und in einigen Programmiersprachen die einzige Implementierungsmöglichkeit des Konzepts einer Referenz."
d.h. das Konzept heisst "Referenz", Zeiger ist eine Implementierung dieses Konzeptes, Zeiger lassen Zeigerarithmetik zu
Nachdem Zeigerarithmetik in Java nicht möglich ist, kennt Java keine Zeiger und somit nennt man das was Java kann nach dem Überbegriff "Referenz". Dasselbe gilt natürlich auch analog für andere Programmiersprachen wie z.B. Eiffel oder VB. --Sebastian.Dietrich ✉ 10:14, 6. Nov. 2010 (CET)
Dann zeugt das leider von unscharfen, falschen Definitionen. Diese Definition stammt in leicht anderem Wortlaut auch aus dem C/C++ Kompendium von Dirk Louis, Pearson Education Deutschland, ISBN 3-8272-6335-2. Dort setzt er sich von Seite 421–499 mit Zeigern und Referenzen auseinander. Zu Referenzen schreibt er folgendes:
"Referenzen sind Aliase für Variablen und werden in ähnlicher Weise wie Zeiger zur Übergabe von Variablen und Funktionen eingesetzt, wenn die Funktionen die übergebenen Variablen direkt ändern (call by reference [siehe Kapitel 12.4.1]) oder Laufzeitverschlechterungen durch Kopieren großer Datenobjekte vermieden werden sollen. [...]" (S. 489)
Weiterhin schreibt er:
"Referenzen repräsentieren keine eigenen Objekte, sondern verweisen auf bestehende Variablen. Darin ähneln Referenzen den Zeigern. Während jedoch ein Zeiger im Laufe des Programms auf verschiedene Variablen verweisen kann, kann eine Referenz immer nur auf eine einzige Variable verweisen. Mit dieser Variablen muss die Referenz bei der Deklaration initialisiert werden." (S. 489)
Da es in Java möglich ist einem "Reference Value" (eigene Definition von Sun sun-reference-value) zur Laufzeit unterschiedliche/verschiedene Objekte zuzuweisen, trifft die Definition von Referenz (die ebenfalls copy by reference voraussetzt) nicht zu. Es handelt sich folglich ganz eindeutig um Zeiger, die dem Programmierer durch ihre Eingeschränktheit wie Referenzen vorkommen, aber keine sind. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 12:40, 6. Nov. 2010 (CET)
Diese Definition/Einschränkung (Referenzen können nur auf eine einzige Variable/Objekt verweisen) trifft aber nur auf C++ zu (C kennt überhaupt keine Referenzen). Du versuchst hier die C++-Definition von Referenzen als allgemeinverbindlich zu deklarieren, was unzulässig ist. Auch ist es falsch, dass sich den Java-Referenzen unterschiedliche Objekte zuweisen lassen: Foo bla = new Foo(); Bar fasel = new Fasel(); bla = fasel schlägt fehl, wenn die Objekte untereinander inkompatibel sind, selbst mit einem cast lässt sich das nicht erzwingen. Bei Zeigern ist das kein Thema. Woran erinnert mich diese Diskussion nur? Achja, hier dran: Donauturm --Mark Nowiasz 17:57, 6. Nov. 2010 (CET)
Weil du dann Äpfel mit Birnen vergleichst. Aber Type bla = new Type(); Type fasel = new Type(); bla = fasel; funktioniert. Entsprechend ist eine Neuzuweisung möglich, was eine Referenz nicht erlaubt, egal ob jetzt auf C++ bezogen oder nicht. Das lernt man im ersten Semester von "Compilerbau". --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 18:43, 6. Nov. 2010 (CET) PS: Nicht ohne Grund spricht Sun in der Sprachdefinition selbst von Pointern und benennt diese dann in "Reference Values" um. Sun führte diese Bezeichnung nicht etwa ein um zum Ausdruck zu bringen das es Referenzen sind, sondern um nicht sagen zu müssen das es Pointer sind. (Pointer == Evil...)

Java References sind als Pointer auf Pointer implementiert, wie in anderen Sprachen mit Garbage Collection auch. Aber die Implementation ist überhaupt nicht der springende Punkt, sondern die Semantik. Und die C++ zu benutzen macht überhaupt keinen Sinn. --Pjacobi 20:01, 6. Nov. 2010 (CET)

Das ist aber der springende Punkt. Sie verhalten sich genau wie Pointer ohne Arithmetik. Wären es Referenzen, dann wäre es eben auch möglich swap() zu implementieren. Da es aber keine Referenzen sind, sondern kopierte Pointer, ist dies eben nicht möglich. Wenn man hier schon von Referenzen sprechen möchte, dann sollte hier auch eine klare Unterscheidung zu Referenzen im ursprünglichen Sinne genannt werden. Sun verweist ja explizit darauf, das sie die Pointer "Referece Values" genannt haben, was dann häufig zu Referenz abgekürzt wird. Eine Bezeichnung als Referenz und ein Verweis auf Referenz (Informatik) ist in diesem Falle irreführend. So stand/steht es aber im Artikel. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 20:21, 6. Nov. 2010 (CET)
Einer der ältesten Sprachkonstrukte ist ja die NullPointerException. Es gibt klare Gründe warum sie nicht NullReferenceException genannt wurde. Allein dadurch wird es doch sehr stark deutlich das Pointer auf "null" verweisen. Erst später, als die Sprache aber bereits in Stein gemeißelt war, hat sich Sun darum bemüht sie nicht als Pointer zu bezeichnen. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 20:32, 6. Nov. 2010 (CET)
Ich glaube, es ist am Einfachsten, einfach dem Sprachgebrauch in der Literatur zu folgen. Es ist insgesamt ein kompliziertes Thema und müsste zuerst einmal über die (verschieden) Semantik(en) von Zuweisungen und und über die Parameterübergabe sprechen.
Und: Arithmetiklose Zeiger und Referenzen sind dasselbe, wenn die Semantik von Parameterübergabe und Zuweisung sich nicht unterscheiden. Sehr schön wird das Thema in einem Klassiker der Informatik-Literatur, Bauer/Goos, "Informatik", (erste Auflage immerhin 1970) erklärt. Unter Berücksichtigung von Algol 68, das ja beliebig tief gestaffelte Referenzen, eben Pointer auf Pointer auf Pointer etc, zulässt.
--Pjacobi 20:43, 6. Nov. 2010 (CET)
Jetzt weiß ich, was Du sagen willst. Oder zumindest, was Du sagen solltest: Java hat kein Call by Reference (im Gegensazu z.B. von C# wo es vorhanden aber für Normalfälle discouraged ist). Das ist natürlich wahr. --Pjacobi 20:46, 6. Nov. 2010 (CET)
Eben - das ist ja eines der Probleme der Diskussion, dass hier munter zwei voneinander völlig unterschiedliche Sachen durcheinandergewürfelt werden: einmal Call by Reference und Referenzen als solches. C++ hat beides (wobei Referenzen praktisch nur bei Call by Reference und vergleichbaren Konstrukten wie Exceptionauslösungen/Rückgabewerte sinnvoll eingesetzt werden können), Java hat Referenzen aber kein Call by Reference und Pascal z.B. hat nur Call by Reference (aber keine Referenzen, dafür Zeiger). --Mark Nowiasz 20:51, 6. Nov. 2010 (CET)
Mir würde ja der Hinweis reichen, das "Referenzen in Java Zeiger sind, die per Call by Value übergeben werden". Es sind schließlich nur Zeiger, die aber wegen ihrer Einschränkungen Referenzen genannt werden, obwohl es eben kein Call by Reference gibt. Sun hat sich da aus marketingtechnischen Gründen so festgelegt, obwohl die Sprachdefinition eben selbst zugibt, das dem nicht der Fall ist. Streng genommen kennt Java keine Referenzen. Aber wenn es etwas nicht gibt, kann man eben clevererweise etwas anderes (kastrierte Pointer) als solches bezeichnen. Genau das hat Sun hier getan. Dennoch verhalten sich diese "Reference Values" eben genau wie Pointer (um nicht zu sagen, das es welche sind). --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 20:54, 6. Nov. 2010 (CET)
Ich habe immer noch nicht verstanden, was Referenzen mit Call by Reference zu tun haben, bzw. warum das eine das andere zwingend voraussetzt, siehe eins 'drüber (C++, Java, Pascal). --Mark Nowiasz 20:57, 6. Nov. 2010 (CET)
Da Referenzen ohne Call by Reference ein ziemlich sinnloses Konstrukt sind. Siehe dazu den oben von mir geschriebenen Vergleich zwischen C++ und Java und vollzieh ihn mal nach. Dann wirst du erkennen, das Referenzen, wie in Pascal, auch nur Sinn machen, wenn sie als Call by Reference übergeben werden. Ansonsten bleibt nichts weiter übrig, als das man im selben Block "a" auch "b" nennen kann. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 21:02, 6. Nov. 2010 (CET)
Referenzen sind Zeiger ohne Arithmetik, oder eine andere Implementation, die sich genauso verhält. Das ist schon seit 1970 oder länger der Fall. Es gibt keine Referenzen, die "etwas Besseres" sind. Aber alles kein Thema für einen Artikel über eine bestimmte Programmiersprache. --Pjacobi 21:05, 6. Nov. 2010 (CET)
Ja das sind sie. Darüber hinaus sind sie nicht änderbar. In Java sind sie aber änderbar. D.h. es ist möglich Reference Values neue Adressen/Objekte zuzuweisen. Folglich sind es keine Referenzen mehr, sondern Zeiger, auch wenn die Arithmetik entfallen ist. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 21:12, 6. Nov. 2010 (CET)
Ehrlich gesagt glaube ich, das Du in diesem Fall einem Irrtum in der Sache unterliegst.
Und auch in C++ können Variablen des Types Referenz auf T neu gebunden (zugewiesen) werden. Plus dem verwirrenden Verhalten von C++, bei der Übergabe von Referenzen by reference eine Referenzstufe wegzukürzen.
Ganz andere Baustelle: Es fehlt im Artikel, das Java keine Closures kann. Soll das erst reinkommen, wenn dieser Mangel abgstellt ist, was ja anscheinend in Kürze der Fall sein wird.
--Pjacobi 21:29, 6. Nov. 2010 (CET)
Was es nicht kann, braucht man wohl auch nicht erwähnen. Sonst gibt es noch tausend andere Dinge, die irgendeine Sprache kann, Java aber nicht.
In C++ ist es nicht möglich eine Referenz zu ändern. Da hüpft dir der Compiler aber mal ganz schnell und böse ins Gesicht. ^^ Referenzen müssen nämlich direkt bei der Deklaration initialisiert werden und sind danach nicht änderbar. (Es sei denn man nutzt Zeigerarithmetik um dies künstlich zu umgehen.) Aber wie bereits angedeutet hängt das sehr stark damit zusammen wie eine Referenz definiert ist. Die Definition einer Referenz in Java ist laut Sun ein Zeiger. Den Artikel Referenz (Informatik) will ich da gar nicht erst zu Rate ziehen, denn dieser ist Kauderwelsch^10, da er keine Definition gibt, sondern nur mit Worten grob versucht den eigentlichen Begriff zu umschwurbeln. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 21:49, 6. Nov. 2010 (CET)
Ja, Du hast Recht mit C++. Variablen Typs Referenz auf T können nur einmalig gebunden werden, alle anderen beliebig oft. Da ich war ich einen Moment verwirrt. Aber ich sehe immer noch nicht, was für Dich eine Referenz gegenüber einem Zeiger auszeichnet. Ein Zeiger ist halt jene besondere Referenz, die die tatsächliche Speicheraddresse enthält und für Arithmetik zur Verfügung stellt.
Wollen wir vielleicht sagen: "In Java könen Variablen nur durch den Zuweisungsoperator gebunden werden, da es keinen Call By Reference und keine Referenzen höhere Ordnung unterstützt"?
--Pjacobi 22:00, 6. Nov. 2010 (CET)
Dann sind wir aber genau bei Zeigern ohne Arithmetik gelandet. Zeiger heißt ja nicht, das sich dahinter eine physikalische Adresse verbergen muss. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 22:07, 6. Nov. 2010 (CET)

ich denke der artikel sollte (kurz!) darstellen, daß es hier eine begriffsverwirrung gibt. pointer/zeiger und pointerarithmetik sind ja recht endeutig definierte begriffe. wenn's nach mir ginge, würde referenz ausschließlich in niabot's sinne und wie z.B. in der C++-welt üblich benutzt, um sie vom pointer klar abzugrenzen. vor allem in der java-welt ist es aber sehr üblich, von referenzen zu sprechen, wenn man pointer ohne pointerarithmetik meint. "falsch" ist das imho nicht, aber ungeschickt.
insgesamt halte ich niabots vorschlag für den besseren ansatz, er gehört aber erstens entschärft, zweitens nicht in den abschnitt "einfachheit" und drittens hab ihr den abschnitt "Merkmale der Sprache" beim editwar übersehen (da ist auch von pointern die rede und daß referenzen flasch wäre) wo das ganze eigentlich behandelt werden sollte. mit "entschärft" meine ich oben angesprochene kurze aufklärung über die sprachverwirrung, und davon abzugehen den unter java-leuten üblichen gebrauch des wortes "referenz" als "falsch" zu bezeichnen. die kommunikation untereinander beeinträchtigt dieser gebrauch nämlich nur sehr begrenzt. -- ∂ 01:51, 7. Nov. 2010 (CET)

Ich hab' die Diskussion mal ein wenig überflogen, und stelle fest, dass ein (vielleicht ist es auch das) entscheidendes Kriterium nicht betrachtet wurde: Egal, ob man nun von Zeigern oder Referenzen spricht (aus meiner Sicht eigentlich ziemlich Wurscht): Kann eine aufgerufene Funktion über übergebene Referenzen (abgesehen von Referenzen auf Objekte, deren Methoden das für mich erledigen) den Inhalt von lokalen Variablen beim Aufrufer ändern? In C oder C++: Ja, In Java: Nöö. Das Konzept Referenz-auf-Variable existiert in Java halt nicht. --Daniel5Ko 02:27, 7. Nov. 2010 (CET)

Ich hab mal den oberen Abschnitt entschärft, indem ich sowohl Pointer als auch Referenz rausgenommen habe. Der Abschnitt spricht ohnedies nur von "beispielhaft". --Sebastian.Dietrich ✉ 09:49, 7. Nov. 2010 (CET)

Hier noch ein Punkt zur Diskussion. Lt. en:Reference (C++) gilt folgendes: "In the C++ programming language, a reference is a simple reference datatype that is less powerful but safer than the pointer type inherited from C. The name C++ reference may cause confusion, as in computer science a reference is a general concept datatype, with pointers and C++ references being specific reference datatype implementations." Bestätigt weiter das was ich oben gesagt habe: Referenz heisst das Konzept, C/C++ Pointer, C++ Referenzen und das was Java hat sind spezifische Implementierungen des Konzeptes. Nachdem die Java Implementierung des Konzeptes weit entfernt von der C/C++ Pointer Implementierung ist (kein Zugriff auf die physikalische Adresse, keine Zeigerarithmetik, kein Zeigen auf andere Typen/Methoden/Referenzen, keine Verwendung ohne Initialisierung), nennt man das in Java halt Referenz (auch wenn es mit der C++ Referenz nicht ident ist). Analoges gilt selbstverständlich auch für andere Programmiersprachen mit Referenzen. --Sebastian.Dietrich ✉ 10:02, 7. Nov. 2010 (CET)

Amen.
Wobei es mir trotzdem noch in den Fingern juckt, das viele Falsche hier nicht stehenzulassen. Denn ob zum Beispiel das abschnittseinleitende Beispiel die ursprünglichen Variableninhalte swapt, hängt davon ab mit welcher Semantik die *Zuweisungen* im Funktionsrumpf ausgeführt werden. Bei C# also, wo man es sich aussuchen kann, ob die Objekte als struct oder class definiert sind.
--Pjacobi 11:09, 7. Nov. 2010 (CET)
Den Wortlaut von Sebastian folgend ist es nun aber dennoch im Artikel falsch. Denn dort steht jetzt: "[...] Verwendung von Referenzen statt Pointern [...]". Dabei nannte Sebastian eben noch Referenzen als Übergeordneten Bergriff zu Pointern und Referenzen in C++. Es macht folglich keinen Sinn "Referenz statt Pointer" zu schreiben. Welcher Pointer (mit welcher Definition) soll das denn sein? Der von C/C++ ist nicht gemeint, obwohl wir wissen das sich die Referenz von Java in gewissen Teilen (auf Arithmetik verzichtend) wie ein Pointer aus C/C++ verhält. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 11:22, 7. Nov. 2010 (CET)
Das stimmt, darum hab ichs ausgebessert auf "Verzicht auf Zeigerarithmetik". Den Absatz in "Merkmale der Sprache" habe ich auch entsprechend verbessert. Was meint ihr - passt das jetzt so für alle? --Sebastian.Dietrich ✉ 13:32, 7. Nov. 2010 (CET)
Hättest du etwas degegen es in Merkmale der Sprache so zu formulieren?
Der Objektzugriff in Java ist über Referenzen implementiert, die in der Sprachdefinition als „Reference Values“ bezeichnet werden.[1] Sie sind mit den Zeigern von C/C++ vergleichbar, verzichten aber auf Zeigerarithmetik. An Methoden werden sie stets per Call by value weitergegeben und sind daher nicht mit den Referenzen anderer Sprachen (z.B. C/C++, Fortran oder Pascal) vergleichbar.[2]
Nachweise
  1. ↑ Types, Values, and Variables. In: Java Language Specification. Sun Microsystems, abgerufen am 6. November 2010 (englisch).
  2. ↑ Scott Stanchfield: Java is Pass-by-Value, Dammit! JavaDude.com, abgerufen am 5. November 2010 (englisch).
--Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 13:49, 7. Nov. 2010 (CET)
Wäre inkorrekt: C hat überhaupt keine Referenzen (nur Zeiger), Pascal ebenfalls nicht - nur Call by Reference, was hier leider häufiger mit Referenzen als solches in einen Topf geworden wird. --Mark Nowiasz 14:14, 7. Nov. 2010 (CET)
Da hast du recht. Dies war eine Nachlässigkeit von mir. Ich habe noch einen Satz ergänzt. Schau am besten mal nach, ob du dich mit diesem anfreunden kannst. --Niabot 4.png Nyabot :: Kujōshorigakari :: aaw 14:28, 7. Nov. 2010 (CET)

Zeiger sind Referenzen, die lediglich weitere Implementationsdetails offenlegen und oft zusätzliche Operationen zulassen. Die gesamte Benutzung von als "Referenzen" bezeichneten Referenzen in C++, zusätzlich zu den als "Zeigern" bezeichneten Referenzen, ist reiner syntactic sugar und könnte ohne Verlust in einem Präprozessor-Schritt eliminiert werden. --Pjacobi 14:42, 7. Nov. 2010 (CET)

@Änderungen im Artikel: Bin damit 100% einverstanden, denke da ist nach hitziger Diskussion wirklich was brauchbares rausgekommen. --Sebastian.Dietrich ✉ 11:27, 8. Nov. 2010 (CET)

Dem schliesse ich mich doch glatt an :-) --Mark Nowiasz 18:38, 8. Nov. 2010 (CET)

Gratis-eBook

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))

Anmerkung: Steht doch schon unter Literatur!

Ein weiterer sehr empfehlenswerter Weblink:

"Programmierkurs Java - Eine Einführung mit Videos, Folien und jede Menge Aufgaben" http://www.programmierkurs-java.de/ (nicht signierter Beitrag von 91.97.21.235 (Diskussion) 17:35, 13. Nov. 2007)

siehe nächsten Abschnitt --Sebastian.Dietrich 18:05, 23. Dez. 2009 (CET)

Beispiele

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))

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)

Dekonstruktor?

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))

da hast du wohl recht, danke. hab's geändert. -- ∂ 18:00, 22. Mai 2011 (CEST)

Interpretierbar

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)

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)
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)
Nicht ganz, siehe [18]. 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)

Aktualisierung auf die Übernahme durch Oracle

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))

Recht hat er! (nicht signierter Beitrag von 195.50.137.186 (Diskussion | Beiträge) 07:21, 10. Aug. 2011 (CEST))

Call by Value - Call by reference

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)

Es gibt kein Call by reference in Java. Vgl. z.B. ref-Parameter in C# als Kontrast. --Daniel5Ko 23:35, 10. Aug. 2011 (CEST)
Siehe auch Diskussion:Java (Programmiersprache)/Archiv#Referenzen vs. Zeiger --Zahnradzacken 01:04, 11. Aug. 2011 (CEST)

Neutralität

Als ich mir den Artikel eben durchlas, ist mir aufgefallen, dass dieser Abschnitt nicht besonders neutral klingt. Sowohl

Javas Klassenbibliothek bietet eine Reihe einfacher Möglichkeiten für Netzwerkkommunikation, von TCP/IP-Protokollen über Remote Method Invocation bis zu Webservices.

als auch

Java ist insbesondere auf Grund der dynamischen Optimierungen der Virtual Machine eine der effizientesten Programmiersprachen und liefert ähnliche Geschwindigkeiten wie C++- oder C#-Programme.

und

Java 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)

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)
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)

Abschnitt Vergleich zu c++: Die Formulierung "fehleranfällige Zeigerarithmetik" halte ich für sehr wertend und auch für falsch. Die Zeigerarithmetik hat sicherlich Nachteile, aber sie ist nicht fehleranfälliger, als andere Spracheigenschaften. Und sie hat auch viele Vorteile. Wie so oft gilt auch für die Zeigerarithmetik, man muss halt wissen, was man tut. Das ist genauso fehleranfällig wie autoboxing oder der Umgang mit ClassLoaders. Und wenn man sich an die Regeln hält, ist Zeigerarithmetik Dein Freund ;-) -- 83.97.72.14 21:35, 29. Sep. 2011 (CEST)

Absatz C#


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))

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)

Falscher erster Satz

"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))

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)

aktuelle Version

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))

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)
nope, 1.7.0 update 1, nicht 1.7.1. -- ∂ 20:15, 12. Nov. 2011 (CET)

Absatz C++

-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))

Redundanz mit Java (Technik) und OpenJDK

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)

Unterschiede zu ähnlichen Sprachen

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)

Entwicklungsumgebungen

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)

Roberta

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)

Android

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)

Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Java_(Programmiersprache)/Archiv/1&oldid=220725246“