Java
- Froggerprogger
- Badmin
- Beiträge: 855
- Registriert: 08.09.2004 20:02
Zunächst musste ich Java im Studium lernen und bin mittlerweile ein
absoluter Fan davon. Hier eine Lobeshymne in Form von Gründen :
* die Objektorierentierung ist gut durchdacht, konsequent und an
sinnvollen Stellen restriktiv (z.B. keine Mehrfachvererbung). Dies erlaubt einen
gut strukturierten Weg von der Modellierung des Problems hin zum
Implementationscode. Außer der Klassenhierachie ist gerade die Package-Struktur
ist ein wichtiges Mittel, aber selbst darüber gibt es noch .jars als Ebene.
* wenn ein Programm kompiliert, so zeigt es immer das beabsichtigte
Verhalten (sofern man keine logischen Fehler einbaut), da alle
Blödsinnsfehler vom Kompiler abgefangen werden können und gut
verständlich ausgegeben werden
* Seit JIT-Compilern (Just In Time Compiler) ist Java
geschwindigkeitsmäßig mit Maschinencode gleichauf, könnte sogar
theoretisch schneller sein, da bspw. lange nicht veränderte Variablen als
Konstante kompiliert werden können.
* Auch komplexeste GUIs lassen sich eventgesteuert erstellen. Die blöden
Applets nutzen dafür meist AWT-Funktionen, Swing ist da schon
wesentlich besser (wenn man auch mehr Sachen beachten muss, um
performant zu bleiben) und wenns ne richtig komplexe Anwendung werden
soll nimm SWT, das nutzt die Betriebssystem-GUI-Funktionen.
* Multithreading ist in Java wunderbar zu nutzen. Insbesondere die
Monitorfunktionen und mit Semaphoren gesicherten
synchronize-Abschnitte sind direkt in der Sprache integiert, keine blöden
API-Aufrufe, etc. dafür nötig.
* Verteilte Anwendungen lassen sich einfach realisieren: Nachladen von
optionalen Programmfunktionen aus beliebigen Teilen des lokalen Netzes
oder Internets. Auch z.B. transparente Anbindung von Klassen auf
verschiedenen Rechnern mittels RMI.
* Kompilieren von zur Laufzeit erstellter Klassen möglich, z.B. um
komplexe mathematische Operationen zur Laufzeit zu konstruieren, dann
aber als Kompilat auszuführen.
* Sehr gute Anbindung an JavaScript, um bspw. Kunden komplexe
Programmfunktionen eigenständig programmieren und ins Programm
einbinden zu lassen. Auch eigene Sprachdefinitionen lassen sich mittels
formaler Grammatiken erzeugen. Die Ergebnisse können wiederum zur
Laufzeit kompiliert werden.
* Mittels JNI lassen sich DLLs/SOs ohne Probleme anbinden, wenn man
denn möchte.
* Es gibt so gut wie alle denkbaren Datenstrukturen und Funktionalitäten
bereits von Haus aus mitgeliefert. Zig zig weitere spezielle und
umfangreiche Bibliotheken gibt es (oft sogar als OpenSource) im Netz.
* Sehr gute Anbindung an Testtools, um z.B. Überdeckungstests des
Codes zu dokumentieren.
* Mit z.B. Eclipse eine geniale IDE, die eine eigene Lobeshymne verdiente
und bspw. direkt die javadoc-Anbindung einbaut (die Kommentare eigener
Funktionen erscheinen dann an gegebener Stelle, ähnlich
wie rudimentär in PB mit dem Semikolon hinter einer Procedure)
* Umfangreiche Analyse-Tools zum Profilen und zur
Programmstrukturanalyse um anhand gewisser Metriken wie Lokalität die
Güte des Programms und seiner Teile zu beurteilen
* Wenn man möchte kann man sein sonstwie komplexes Programm
als Applet bereitstellen.
* Es gibt (!) Pointer - jede Referenz ist eine. Ein Pointer kann auch auf
andere Objekte gesetzt werden, aber nicht (und das ist die
Einschränkung) mit arithmetischen Operationen modifiziert werden, wie +
*, etc. Denn dies ist eine böse und architekturabhängige Fehlerquelle, die
zudem nicht zur Kompilezeit gecheckt werden kann, dafür aber nirgendwo
wirklich notwendig ist, außer für handgemachte
(hardwareabhängige) Optimierungen, die nicht vom Kompiler als solche
erkannt werden. Dann könnte eine solche Funktion aber auch per JNI
eingebunden werden.
Alles in allem ist Java äußerst geeignet gerade für komplexe
Anwendungen, die später flexibel erweitert werden sollen und ggf.
dezentral laufen. Ich habe (wie auch zur Zeit) bereits an mehreren
Projekten mit > 100.000 LOC mitgearbeitet (gute Teamarbeit mit einem
CMS wie SVN möglich) und nutze auch privat mittlerweile sehr viel Java.
Und nochmal: Java ist kein JavaScript und die
Applets sind nur ein optionales Bonbon.
Aber keine Sorge, PB macht mir auch Spaß, auch wenn ich wohl nie
wieder ein komplexes Projekt damit realisieren werde... (Ein Versuch
reichte, der zwar gelungen ist, aber um nachträgliche Kundenwünsche für
Erweiterungen zu realisieren muss ich mich jedesmal in die strikte
Struktur von Includes und DLLs, etc. einarbeiten, um keine bösen Fehler
z.B. ins Multithreading einzubauen. OOP ist einfach ein 'Muss').
P.S.: Ich bin auch C/C++-Fan (gcc mit eclipse cdt) für spezielle
hardwareabhängige Programme oder assembleroptimierte Teile.
absoluter Fan davon. Hier eine Lobeshymne in Form von Gründen :
* die Objektorierentierung ist gut durchdacht, konsequent und an
sinnvollen Stellen restriktiv (z.B. keine Mehrfachvererbung). Dies erlaubt einen
gut strukturierten Weg von der Modellierung des Problems hin zum
Implementationscode. Außer der Klassenhierachie ist gerade die Package-Struktur
ist ein wichtiges Mittel, aber selbst darüber gibt es noch .jars als Ebene.
* wenn ein Programm kompiliert, so zeigt es immer das beabsichtigte
Verhalten (sofern man keine logischen Fehler einbaut), da alle
Blödsinnsfehler vom Kompiler abgefangen werden können und gut
verständlich ausgegeben werden
* Seit JIT-Compilern (Just In Time Compiler) ist Java
geschwindigkeitsmäßig mit Maschinencode gleichauf, könnte sogar
theoretisch schneller sein, da bspw. lange nicht veränderte Variablen als
Konstante kompiliert werden können.
* Auch komplexeste GUIs lassen sich eventgesteuert erstellen. Die blöden
Applets nutzen dafür meist AWT-Funktionen, Swing ist da schon
wesentlich besser (wenn man auch mehr Sachen beachten muss, um
performant zu bleiben) und wenns ne richtig komplexe Anwendung werden
soll nimm SWT, das nutzt die Betriebssystem-GUI-Funktionen.
* Multithreading ist in Java wunderbar zu nutzen. Insbesondere die
Monitorfunktionen und mit Semaphoren gesicherten
synchronize-Abschnitte sind direkt in der Sprache integiert, keine blöden
API-Aufrufe, etc. dafür nötig.
* Verteilte Anwendungen lassen sich einfach realisieren: Nachladen von
optionalen Programmfunktionen aus beliebigen Teilen des lokalen Netzes
oder Internets. Auch z.B. transparente Anbindung von Klassen auf
verschiedenen Rechnern mittels RMI.
* Kompilieren von zur Laufzeit erstellter Klassen möglich, z.B. um
komplexe mathematische Operationen zur Laufzeit zu konstruieren, dann
aber als Kompilat auszuführen.
* Sehr gute Anbindung an JavaScript, um bspw. Kunden komplexe
Programmfunktionen eigenständig programmieren und ins Programm
einbinden zu lassen. Auch eigene Sprachdefinitionen lassen sich mittels
formaler Grammatiken erzeugen. Die Ergebnisse können wiederum zur
Laufzeit kompiliert werden.
* Mittels JNI lassen sich DLLs/SOs ohne Probleme anbinden, wenn man
denn möchte.
* Es gibt so gut wie alle denkbaren Datenstrukturen und Funktionalitäten
bereits von Haus aus mitgeliefert. Zig zig weitere spezielle und
umfangreiche Bibliotheken gibt es (oft sogar als OpenSource) im Netz.
* Sehr gute Anbindung an Testtools, um z.B. Überdeckungstests des
Codes zu dokumentieren.
* Mit z.B. Eclipse eine geniale IDE, die eine eigene Lobeshymne verdiente
und bspw. direkt die javadoc-Anbindung einbaut (die Kommentare eigener
Funktionen erscheinen dann an gegebener Stelle, ähnlich
wie rudimentär in PB mit dem Semikolon hinter einer Procedure)
* Umfangreiche Analyse-Tools zum Profilen und zur
Programmstrukturanalyse um anhand gewisser Metriken wie Lokalität die
Güte des Programms und seiner Teile zu beurteilen
* Wenn man möchte kann man sein sonstwie komplexes Programm
als Applet bereitstellen.
* Es gibt (!) Pointer - jede Referenz ist eine. Ein Pointer kann auch auf
andere Objekte gesetzt werden, aber nicht (und das ist die
Einschränkung) mit arithmetischen Operationen modifiziert werden, wie +
*, etc. Denn dies ist eine böse und architekturabhängige Fehlerquelle, die
zudem nicht zur Kompilezeit gecheckt werden kann, dafür aber nirgendwo
wirklich notwendig ist, außer für handgemachte
(hardwareabhängige) Optimierungen, die nicht vom Kompiler als solche
erkannt werden. Dann könnte eine solche Funktion aber auch per JNI
eingebunden werden.
Alles in allem ist Java äußerst geeignet gerade für komplexe
Anwendungen, die später flexibel erweitert werden sollen und ggf.
dezentral laufen. Ich habe (wie auch zur Zeit) bereits an mehreren
Projekten mit > 100.000 LOC mitgearbeitet (gute Teamarbeit mit einem
CMS wie SVN möglich) und nutze auch privat mittlerweile sehr viel Java.
Und nochmal: Java ist kein JavaScript und die
Applets sind nur ein optionales Bonbon.
Aber keine Sorge, PB macht mir auch Spaß, auch wenn ich wohl nie
wieder ein komplexes Projekt damit realisieren werde... (Ein Versuch
reichte, der zwar gelungen ist, aber um nachträgliche Kundenwünsche für
Erweiterungen zu realisieren muss ich mich jedesmal in die strikte
Struktur von Includes und DLLs, etc. einarbeiten, um keine bösen Fehler
z.B. ins Multithreading einzubauen. OOP ist einfach ein 'Muss').
P.S.: Ich bin auch C/C++-Fan (gcc mit eclipse cdt) für spezielle
hardwareabhängige Programme oder assembleroptimierte Teile.
Zuletzt geändert von Froggerprogger am 18.04.2008 14:54, insgesamt 1-mal geändert.
!UD2
Auch wenn ich Java zum Teil noch kritisch beäuge, den Punkten von Froggerprogger stimme ich zum größten Teil zu.
Auch gerade die Packages und der Zwang, pro Klasse eine eigene Datei anzulegen. Anfangs denkt man "was soll der Scheiß", aber das sind einfach vorschnelle Urteile. Wenn man es erstmal 'ne Weile verwendet hat, fängt man in anderen Sprachen an, das so gut es geht "nachzubauen"
weil es einfach auf lange Sicht besser ist.
Oft merkt man solche Dinge auch erst bei wirklich großen Projekten. Wer in PB immer nur 1000-Zeilen-Programme in einer einzigen Datei geschrieben hat, wird solche Dinge erstmal total umständlich und unnütz finden, und das kann ich auch gut verstehen. Aber genau deshalb habe ich mir abgewöhnt, Urteile zu fällen über Dinge, die ich noch gar nicht richtig ausprobiert habe.
Auch gerade die Packages und der Zwang, pro Klasse eine eigene Datei anzulegen. Anfangs denkt man "was soll der Scheiß", aber das sind einfach vorschnelle Urteile. Wenn man es erstmal 'ne Weile verwendet hat, fängt man in anderen Sprachen an, das so gut es geht "nachzubauen"

Oft merkt man solche Dinge auch erst bei wirklich großen Projekten. Wer in PB immer nur 1000-Zeilen-Programme in einer einzigen Datei geschrieben hat, wird solche Dinge erstmal total umständlich und unnütz finden, und das kann ich auch gut verstehen. Aber genau deshalb habe ich mir abgewöhnt, Urteile zu fällen über Dinge, die ich noch gar nicht richtig ausprobiert habe.


ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
-
- Beiträge: 6291
- Registriert: 29.08.2004 08:37
- Computerausstattung: Hoffentlich bald keine mehr
- Kontaktdaten:
Polymorphismus geht doch in Java:Froggerprogger hat geschrieben:* die Objektorierentierung ist gut durchdacht, konsequent und an
sinnvollen Stellen restriktiv (z.B. keine Polymorphie).
Abstrakte Klasse Tür mit Operation oeffnen()http://de.wikipedia.org/wiki/Polymorphie_%28Programmierung%29#Polymorphie_der_Objektorientierten_Programmierung hat geschrieben:Die Polymorphie der Objektorientierten Programmierung ist eine Eigenschaft, die immer im Zusammenhang mit Vererbung auftritt. Eine Methode ist polymorph, wenn sie in verschiedenen Klassen die gleiche Signatur hat, jedoch erneut implementiert ist.
Klasse DrehTüre erbt von Tür und implementiert oeffnen() als drehen um 180° in der Mitte der Türe
Klasse NormaleTüre erbt von Tür und implementiert oeffnen() als drehen um 90° an der Kante der Türe

Angenommen es gäbe einen Algorithmus mit imaginärer Laufzeit O(i * n), dann gilt O((i * n)^2) = O(-1 * n^2) d.h. wenn man diesen Algorithmus verschachtelt ist er fertig, bevor er angefangen hat.
Pointer sind ja direkte Adresse im Speicher, Referenzen sind für mich* Es gibt (!) Pointer - jede Referenz ist eine. Ein Pointer kann auch auf
andere Objekte gesetzt werden, aber nicht (und das ist die
Einschränkung) mit arithmetischen Operationen modifiziert werden, wie +
*, etc. Denn dies ist eine böse und architekturabhängige Fehlerquelle, die
zudem nicht zur Kompilezeit gecheckt werden kann, dafür aber nirgendwo
wirklich notwendig ist, außer für handgemachte
hingegen nur feste IDs von Objekten. Hat für mich nichts von Pointern.
@ZeHa
Java erlaubt das erstellen mehrerer Klassen in einer Datei. Die IDEs wie
Eclipse und Netbeans markieren das lediglich. Compilieren ist trotzdem kein
Problem.
@Polymorphismus
Was ist darann so schlecht? Methodenüberladung kann man sehr sinnvoll
verwenden, aber muss man wirklich nicht. Nur bei Nutzung von Interfaces
ist es doch perfekt.

Ansonnsten ... wie schon gesagt, Java ist nicht schlecht. Ich mags
trotzdem nicht besonders

- Froggerprogger
- Badmin
- Beiträge: 855
- Registriert: 08.09.2004 20:02
Sorry, ich meinte nicht Polymorphismus (immer diese ** Fremdwörter) sondern Mehrfachvererbung (ich hatte Polymorphie als korrektes Fremdwort dafür in Erinnerung).
@PMV Nennen wir es so: Java und C unterstützen Zeiger auf Objekte. In C heißen sie Pointer und können auch durch arithmetische Operationen beliebig verändert werden und zwischen beliebigen Typen gecastet, in Java heißen sie Referenzen und können nur auf existierende Objekte (oder null) zeigen und nur entlang der Vererbungshierachie gecastet werden.
@PMV Nennen wir es so: Java und C unterstützen Zeiger auf Objekte. In C heißen sie Pointer und können auch durch arithmetische Operationen beliebig verändert werden und zwischen beliebigen Typen gecastet, in Java heißen sie Referenzen und können nur auf existierende Objekte (oder null) zeigen und nur entlang der Vererbungshierachie gecastet werden.
!UD2
-
- Beiträge: 6291
- Registriert: 29.08.2004 08:37
- Computerausstattung: Hoffentlich bald keine mehr
- Kontaktdaten:
Stimmt, das finde ich aber auch gut, dass das nicht geht. Aus nem Motorrad und nem Auto entsteht in Wirklichkeit auch kein Trike, egal wie man es zusammenwirft.Froggerprogger hat geschrieben:Sorry, ich meinte nicht Polymorphismus (immer diese ** Fremdwörter) sondern Mehrfachvererbung (ich hatte Polymorphie als korrektes Fremdwort dafür in Erinnerung).
Angenommen es gäbe einen Algorithmus mit imaginärer Laufzeit O(i * n), dann gilt O((i * n)^2) = O(-1 * n^2) d.h. wenn man diesen Algorithmus verschachtelt ist er fertig, bevor er angefangen hat.
@ PMV: Du meinst glaube ich "innere Klassen", das funktioniert, aber das meinte ich jetzt nicht, ich meinte schon "richtige Klassen" 
Habe gerade mal getestet ob man zwei "richtige Klassen" in einer einzigen Datei haben kann, javac gibt da einen Fehler aus.
Zum Thema Pointer in Java: Wenn's in Java keine Pointer gibt, warum gibt es dann eine NullPointerException?

Habe gerade mal getestet ob man zwei "richtige Klassen" in einer einzigen Datei haben kann, javac gibt da einen Fehler aus.
Zum Thema Pointer in Java: Wenn's in Java keine Pointer gibt, warum gibt es dann eine NullPointerException?



ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
Java ist plattformunabhängig, das ist mir sehr wichtig, und bringt hierzu auch die überall verwendbare GUI mit (im Gegensatz zu C++, wo ich mir noch wxWidget oder so dazunehmen muss).
Man sollte allerdings nicht immer in der neuseten Sprachversion arbeiten, wenn man das Ergebnis weitergeben will. Viele sind noch mit der JRE 1.4.6 unterwegs. Da sind C++ und auch PB im Vorteil.
Man sollte allerdings nicht immer in der neuseten Sprachversion arbeiten, wenn man das Ergebnis weitergeben will. Viele sind noch mit der JRE 1.4.6 unterwegs. Da sind C++ und auch PB im Vorteil.

PB4.3
Ach so ... naja ob das ein vorteil ist ... ich glaub da sind viele andererFroggerprogger hat geschrieben:Sorry, ich meinte nicht Polymorphismus (immer diese ** Fremdwörter) sondern Mehrfachvererbung (ich hatte Polymorphie als korrektes Fremdwort dafür in Erinnerung).
Meinung.

... aber Interfaces kann man zum glück beliebig viele nutzen.
Joa, das stimmt schon so, aber genau das macht für mich einen@PMV Nennen wir es so: Java und C unterstützen Zeiger auf Objekte. In C heißen sie Pointer und können auch durch arithmetische Operationen beliebig verändert werden und zwischen beliebigen Typen gecastet, in Java heißen sie Referenzen und können nur auf existierende Objekte (oder null) zeigen und nur entlang der Vererbungshierachie gecastet werden.
"richtigen" Zeiger aus, man kann mit ihm rechnen. Ein Pointer ist für mich
ein (eigenständiger) Datentyp, mit dem man rechnen kann. Die Referenzen
in Java werden von der JVM bestimmt und können vom Programmierer nicht
so verändert werden. Natürlich hat das auch seine Vorteile, wie du schon
geschrieben hast.

@ZeHa
Öhm ... ah, mach mal das "public" vor dem "class" weg

Nur bei öffentlichen Klassen wird anscheinend gemekert.

@NonFreak
Warum 1.4.6? Warum Updaten die nicht einfach? Kein Internet? Wie
kommen die dann an Programme? CD? Da passt auch das aktuellste JRE
drauf

... mir fällt grad ein Negativpunkt von Java ein, der mich einiges an Zeit
gekostet hat

zwei Short-Werte zu addieren

Code: Alles auswählen
short value1 = -1;
short value2 = -100;
short value = value1 + value2;

Code: Alles auswählen
short value1 = -1;
short value2 = -100;
short value = (short) (value1 + value2);
Bevor noch jemand meint, Java wäre perfekt

MFG PMV
Jo, was mich auch tierisch nervt, ist, daß es keine unsigned-Variablen gibt. Das hat mich schon unzählige Stunden und Nerven gekostet. Gerade wenn man binäre Daten ausliest, ist unsigned oft extrem wichtig.
@ PMV: Ich hab halt mal "private" versucht, da sagte er dann "illegal Modifier".
@ PMV: Ich hab halt mal "private" versucht, da sagte er dann "illegal Modifier".


ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.