Wikipedia

Diskussion:Java (Programmiersprache)

Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 23. November 2005 um 22:17 Uhr durch Royd (Diskussion | Beiträge) (→java deutschsprachig ?). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Letzter Kommentar: vor 20 Jahren von Herr Schroeder in Abschnitt Memo: Vollständige Weblinks

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)

Entschuldigung

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

Letzter Kommentar: vor 21 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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.
  • 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, USCD Pascal,...)

Wenn ich dazukomme, das in vernünftige Sätze zu packen, mache ich das. OliD 20:53, 19. Mai 2003 (CEST)Beantworten

Rhein objektorientiert?

Letzter Kommentar: vor 21 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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 :Beantworten

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

Letzter Kommentar: vor 21 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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

der ganz große Wurf wars noch nicht

Letzter Kommentar: vor 21 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

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

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

kundig gemacht

Letzter Kommentar: vor 21 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

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.htmBeantworten


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

Ich hab ein Problem mit Patrick Naughton: [1] [2] [3]

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

Vaterfigur

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

Letzter Kommentar: vor 21 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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

moven

Letzter Kommentar: vor 21 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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


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

Go ahead!

jonelo 5. Juni 2003 (CEST)


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)

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)


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

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)

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)

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)

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)

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

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)

Ich habe etwas zu dieser Problematik unter Finalisierung verfasst. Kommentare willkommen. Poldi 18:15, 10. Okt 2004 (CEST)

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

Wikipedia:Kandidaten für exzellente Artikel

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.

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)

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? [www.wikibooks.de 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 [[4]] - 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)
Letzter Kommentar: vor 20 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt

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

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 [5] sagen? --Herr Schroeder 11:19, 2. Mai 2005 (CEST)Beantworten
BTW nach welchen Kriterien hast Du die Links eigentlich aussortiert? --Herr Schroeder 11:20, 2. Mai 2005 (CEST)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
Letzter Kommentar: vor 20 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

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

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)

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 [[6]]. --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)

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)

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)
  • Kontra - 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)
  • Kontra zu wenig Geschichte, Unterschiede zwischen den Versionen wären wünschenswert. --Bricktop 22:34, 21. Okt 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)
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Diskussion:Java_(Programmiersprache)&oldid=11034872“