-
Welche Technik?
Autor: thomas001le 06.01.16 - 15:32
Geht es nur mir so, oder ist noch jemandem nicht ganz klar was diese "Technik" nun eigentlich ist? Die eigentliche VM hat Google ja selbst implementiert in (inzwischen) ART.
Dann bleiben wohl noch die Massen an APIs der J2SE die man für eine Java-Implementierung implementieren muss. Wobei das sicherlich eine langwierige Aufgabe ist, sehe ich nicht wirklich wie das "Technik" ist, die werden ja die Hashmap nicht neu erfunden haben und auch der Code Socketoperationen oder ähnlichem ist ja nun kein Hexenwerk... -
Re: Welche Technik?
Autor: tingelchen 06.01.16 - 16:42
Es geht neben der Runtime selbst, auch eben um die API. Die Java API ist hoffnungslos mit etlichen Klassen überfrachtet. In einem Konstrukt das es Einsteigern praktisch unmöglich macht sich darin schnell ein zu arbeiten. Ein Grund warum ich Java nicht mag ;) Zu Faul für die Konstrukte.
In der API steckt dennoch eine Menge Arbeit und wurde ja ebenfalls von Google übernommen. Die Reimplementierung der Runtime alleine reicht daher nicht um sich Oracle zu entziehen.
Ob man nun eine API als "Technik" bezeichnen kann. Nun das ist eine Frage der Formulierung. -
Re: Welche Technik?
Autor: bstea 06.01.16 - 17:48
Lol, du bist wahrscheinlich der einzige der Probleme mit einer so wohldurchdachten API hat.
--
Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann! -
Re: Welche Technik?
Autor: tingelchen 06.01.16 - 18:33
Ich bin nicht der einzige der die Std Java API als überfrachtet und viel zu verschachtelt ansieht. Das sagt praktisch jeder. Es haben nur nicht alle Lust sich das an zu tun. Von Problemen hat hier niemand gesprochen.
-
Re: Welche Technik?
Autor: freebyte 06.01.16 - 23:00
bstea schrieb:
--------------------------------------------------------------------------------
> Lol, du bist wahrscheinlich der einzige der Probleme mit einer so
> wohldurchdachten API hat.
Ich bin da ganz bei tingelchen - die API ist zu sehr überfrachtet und an vielen Ecken merkt man den Interfaces an, dass im Designprozess zu viel "nice to have" statt "need to know" im Spiel war.
Beispiele:
javax.servlet.* enthält viel Kram den ich noch nie wirklich funktionsfähig implementiert gesehen habe (gerade im Bereich Request-Forwarding). Ok, die API ist schon älter :-)
javax.mail.* Wollte das mal "ordentlich" machen indem die Mailbodies komplett als Disk-Stream verarbeitet werden. Geht nicht - an bestimmten Stellen muss die Message als byte[] vorliegen und das ist ein no-go wenn man bisserl mehr Mails transportieren möchte. Man kann also theoretisch die Referenzimplementierung austauschen, in der Praxis macht es aber keinen Sinn.
java.util.concurrent hat mehr Verwirrung als Hilfe gebracht, manchmal hat man den Eindruck dass bei gewissen Leuten fürchterliche Langeweile herrscht :-)
fb -
Re: Welche Technik?
Autor: Graveangel 07.01.16 - 08:48
tingelchen schrieb:
--------------------------------------------------------------------------------
> Ich bin nicht der einzige der die Std Java API als überfrachtet und viel zu
> verschachtelt ansieht. Das sagt praktisch jeder. Es haben nur nicht alle
> Lust sich das an zu tun. Von Problemen hat hier niemand gesprochen.
Mich nervt es auch!
Die syntax ist in Ordnung und würde mich wenig stören, aber alleine die Entscheidung, wo man anfängt geht mir auf den Sack -
Re: Welche Technik?
Autor: bofhl 07.01.16 - 15:16
Man braucht sich ja nur die zig Variationen des I/O-Supports ansehen - sehr oft stellt sich da die Frage, warum das nicht gleich in der Basisklasse gemacht wurde (entweder handelt es sich um blos einen "Proxy" oder es wird nur ein weiterer Konstruktor hinzugefügt und ein paar weitere Methoden angefügt oder endlich richtig behandelt)
An anderen Stellen werden einfachste Dinge schlicht ignoriert - Encoding bei Properties (Laden aus Dateien). Nett ist immer wieder wenn Klassen&Interfaces aus "Art-fremden"-Packages zweckentfremdet benutzt werden (müssen) - z.B. alles rund um Events, die kommen meist aus java.awt!



