Diskussion:Java (Programmiersprache)/Archiv/1

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

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

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

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

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's_mir! 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:

• Javac ist der wohl bekannteste Bytecode-Compiler bzw. Interpreter von der Firma Sun Microsystems. Er ist ein Bestandteil des JDK.
• Jikes ist die schnellere Alternative von IBM. Jikes ist kein Interpreter wie javac sondern ein JIT-Compiler.

Dass die VM Bytecode interpretiert, ist mir ja klar, aber was genau an Javac ist ein Interpreter? Korrigiert mich, wenn ich mich irre: Javac ist ein Compiler, kein Interpreter.

Umgekehrt: ein JIT-Compiler kann doch eigentlich nur Teil einer Laufzeitumgebung (z.B. der VM) sein - bei Jikes konnte ich aber keine Hinweise darauf finden, ganz im Gegenteil: Auf den Jikes-Webseiten wird besonders betont dass es sich lediglich um einen Command-Line-Compiler handelt...

Ich denke, die entsprechenden Aussagen zu den beiden Compilern sollten entfernt werden. Besteht der Unterschied nicht vielmehr darin, dass Javac in Java geschrieben ist und Jikes in C(++)?

--Asarion 11:39, 23. Okt 2004 (CEST)

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:

• Einstieg Java (Programmiersprache) als Überblick über die Technologien,

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

• Java (Technologie)
• Java Programmiersprache
• Java (Plattform)

aufgesplittet.

Ich bitte darum sich diese Aufteilung anzuschauen. Wenn die Aufteilung hier auf Zuspruch stößt können wir die Artikel in den Wikipedia Namensraum verschieben.

Herr Schroeder 10:57, 1. Jun 2005 (CEST)

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:

• Das 'free' hätte ich mir auch sparen können.
• Habe jetzt ein bischen gesucht, und bei http://forum.java.sun.com/thread.jspa?threadID=591738&messageID=3087303 die Aussage gefunden: Java is always call by value. Was ist nun richtig?

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)

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) jpp ?! 12:23, 14. Jun 2006 (CEST))

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) jpp ?! 09:20, 10. Aug 2006 (CEST))

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