Diskussion:Java (Programmiersprache)

Archiv
Zum Archiv

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 120 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten.

Absatz C++

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

Redundanz mit Java (Technik) und OpenJDK

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

Unterschiede zu ähnlichen Sprachen

Smalltalk

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

Entwicklungsumgebungen

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

Roberta

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

Android

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

Entstehungsjahr von JAVA?

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

Kritik

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

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

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

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

Einfach?

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

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

+1

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

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

Native Compiler

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