Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

25 Jahre Java: Wie ein Werkzeug fürs Kabelfernsehen zur führenden Sprache wurde

Objective-C, C#, Basic und Python: Programmiersprachen gibt es wie Sand am Meer. Seit Jahren jedoch steht ein Werkzeug zur Softwareerstellung im Popularitätsranking unangefochten ganz oben auf dem Treppchen: Java. Als die Plattform vor 25 Jahren erstmals der Öffentlichkeit präsentiert wurde, rechneten allerdings nicht einmal ihre Schöpfer mit einem derartigen Erfolg.


Java: Plattformunabhängig und robust
Performant sollte Java sein, vor allem aber einfach und objektorientiert sowie robust und plattformunabhängig. Das waren die Vorstellungen von James Gosling, Mike Sheridan, and Patrick Naughton, als sie 1991 mit der Entwicklung von Java begannen. Ihr ursprüngliches Ziel war die Schaffung eines Werkzeugs für interaktives Kabelfernsehen. Ziemlich schnell stellte sich jedoch heraus, dass dies mit den damaligen technischen Möglichkeiten der Geräte und der analogen Verbreitung von TV-Signalen nicht zu erreichen war. Also schwenkte man um und entwarf eine universelle Programmiersprache, mit der sich vielfältige Anwendungssoftware erstellen ließ.

Erste Java-Präsentation am 23. Mai 1995
Nach der ersten Präsentation am 23. Mai 1995 dauerte es noch ein Jahr, bis Java 1.0 fertig war und veröffentlicht werden konnte. Hinsichtlich der Syntax lehnte sich Java an C an, damit wollte man Software-Entwicklern den Umstieg von ihrer gewohnten Programmiersprache erleichtern und schmackhaft machen. Gleichzeitig stellte Sun Microsystems kostenlose Laufzeitumgebungen für zahlreiche Betriebssysteme und Plattformen zur Verfügung, so dass einmal geschriebene Programme auf Geräten vieler verschiedener Hersteller eingesetzt werden konnten. Heute laufen Java-Programme nicht nur auf Computern, sondern auch auf Milliarden anderer Devices wie Druckern und Routern, auf Smartphones und E-Readern, aber auch auf Kreditkarten - und in Fernsehern. Das zumindest behauptet der heutige Java-Anbieter Oracle, der Sun Microsystems und damit die Programmiersprache im Jahr 2009 übernahm.

Seit fünf Jahren Platz eins im TIOBE-Index
Mittlerweile liegt Java in Version 14 vor. Seit fünf Jahren belegt sie im TIOBE-Index der populärsten Programmiersprachen ununterbrochen den ersten Platz, dicht gefolgt von C. Die Ränge drei bis fünf behaupten Python, C++ und C#. Zum Vergleich: Apples Sprache Swift landete Ende 2019 auf Platz zehn, Objective-C lag auf Rang 13. Beide reihten sich damit noch hinter Visual Basic .NET ein, das Platz sechs belegte, gefolgt von JavaScript auf Rang sieben.

Java und Apple
Apple unterstützte Java lange Zeit ab Werk. Bis OS X 10.6 Snow Leopard war die Laufzeitumgebung fester Bestandteil des Betriebssystems. Das änderte sich mit OS X 10.7 Lion, seither muss die Runtime vom Anwender selbst bei Oracle heruntergeladen und auf dem Mac installiert werden. Auf iPhone und iPad laufen Java-Programme nicht, da es für die iDevices keine Runtime gibt. JavaScript ist hingegen natürlich in Safari verfügbar, lässt sich aber in den Einstellungen deaktivieren.

Kommentare

maculi
maculi06.05.20 11:44
Wenn hier schon JavaScript erwähnt wird, dann sollte aber auch ausdrücklich darauf hingewiesen werden, das ausser der Namensähnlichkeit keinerlei Gemeinsamkeiten bestehen. Das sind zwei voneinander völlig unabhängige Technologien.
Davon abgesehen hat Oracle vor einiger Zeit die Lizenzbestimmungen geändert. Es bleibt abzuwarten, wie sich das längerfristig auswirkt.
+7
Steffen Stellen06.05.20 11:52
MacTechNews
Auf iPhone und iPad laufen Java-Programme nicht, da es für die iDevices keine Runtime gibt.
Das ist jetzt aber nicht die ganze Wahrheit:
-4
Retrax06.05.20 12:01
"JavaScript deaktivieren" - den Hintergrund dieser Einstellung in Safari (iOS + macOS) verstehe ich ehrlich gesagt nicht.

Wieso sollte man als Nutzer JavaScript im Browser deaktivieren - es wird doch von fast jeder Webseite benötigt....?
-1
Mecki
Mecki06.05.20 12:24
Retrax
Wieso sollte man als Nutzer JavaScript im Browser deaktivieren - es wird doch von fast jeder Webseite benötigt....?
Und meistens für nichts sinnvolles genutzt. Ohne JS ist halt irgend ein Inhalt nicht animiert, so what? Ohne JS wird halt ein Formular vor dem Absenden nicht geprüft, dafür eben vom Server. Ohne JS erscheint die Werbung halt nicht, macht auch nichts. Ohne JS wird die Seite eben nicht für dein Endgerät angepasst, was oft gar keine Verbesserung sondern eher eine Verschlechterung darstellt. Ohne JS spielen eben keine eingebetteten Videos. Aber die Seiten selber werden auch ohne JS meistens korrekt dargestellt (HTML + CSS braucht kein JS). Selbst solche, die sich weigern ohne JS irgendwas anzuzeigen (gaukelt man denen JS vor, erhält man trotzdem eine lesbare Seite, der eben nur unnötiger Schnickschnack fehlt). Lediglich bei Seiten, die mehr eine Online App als eine Webseite darstellen ist JS wirklich erforderlich, weil hier jeglicher Inhalt dynamisch ist. Das betrifft aber vielleicht eine von zehn Seiten, wenn nicht weniger.
-3
R-Waves
R-Waves06.05.20 13:15
Retrax
Ohne JS wird halt ein Formular vor dem Absenden nicht geprüft, dafür eben vom Server.

Ohne JS wird dann aber auch bei sehr vielen Seiten der "Senden"-Button nicht freigegeben (und verbleibt auf disabled=true). Somit lässt sich die Seite nicht verwenden.
+4
n0x06.05.20 13:51
Java und JavaScript haben so viel miteinander zu tun wie iOS und Android... JavaScript müsste noch LiveScript heißen aber es kam anders.

VG
n0x
+4
Peter Eckel06.05.20 14:39
R-Waves
Ohne JS wird dann aber auch bei sehr vielen Seiten der "Senden"-Button nicht freigegeben (und verbleibt auf disabled=true). Somit lässt sich die Seite nicht verwenden.
Das gibt dem Nutzer dann eine schöne Gelegenheit, nochmal darüber nachzudenken, ob er den Betreiber dieser Seite wirklich mit seinen Daten und ggf. seinem Geschäftsumsatz beglücken will.

Wenn ja, kann man es ja temporär einschalten. Wenn nein ... Pech für die Kuh Elsa.

Im großen und ganzen gebe ich Mecki vollkommen Recht: JavaScript wird oft für Dinge verwendet, auf die man auch ganz gut verzichten kann. Und für ziemlich viele Dinge, auf die man auch unbedingt verzichten will.
Ceterum censeo librum facierum esse delendum.
+1
LoCal
LoCal06.05.20 14:43
Steffen Stellen
MacTechNews
Auf iPhone und iPad laufen Java-Programme nicht, da es für die iDevices keine Runtime gibt.
Das ist jetzt aber nicht die ganze Wahrheit:
Wenn man es ganz genau nimmt, dann läuft Java sogar werkseitig auf dem iPhone, denn ohne Java würde ApplePay nicht funktionieren.
Apple muss mit Apple Pay der Java Card Spezifikation folgen und kommt damit ohne JVM nicht aus. ()
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
0
Peter Eckel06.05.20 14:47
Zum eigentlichen Thema:

Was gern vergessen wird und auch zum guten Teil zur Konfusion Java/JavaScript beiträgt ist, daß Java in den Anfangszeiten oft eingesetzt wurde, indem Java-Code in sogenannten "Java Applets" auf dem Client im Browser ausgeführt wurde. Das war aus verschiedenen Gründen der blanke Horror: Versionsinkonsistenzen allerorten, meist in der Form, daß Web-Applikation A unbedingt Java 1.4 wollte, während Web-Applikation B auf 1.6 bestand und so weiter.

Daß das ganze dann auch noch alles andere als performant war und nebenbei auch noch komplett am UI-Design des Client-Betriebssystems vorbeiging trug auch zum verdienden Scheitern dieser Spielart bei. Java findet man heute eigentlich fast nur noch bei Serverapplikationen. Für andere Einsatzzwecke ist die Startzeit von Java-Applikationen auch schlicht zu lang - es muß immer erst eine JVM hochgefahren werden, in der dann das eigentliche Programm läuft.

Mir persönlich hat sich der Reiz von Java immer entzogen - ich hatte mal eine Weile das Vergnügen, Tools in Java entwickeln zu müssen und war froh, damit irgendwann nichts mehr zu tun zu haben. Eine durch und durch schreckliche Sprache für meinen Geschmack - aber da gibt es auch durchaus andere Meinungen.
Ceterum censeo librum facierum esse delendum.
+2
gfhfkgfhfk06.05.20 15:06
maculi
Davon abgesehen hat Oracle vor einiger Zeit die Lizenzbestimmungen geändert. Es bleibt abzuwarten, wie sich das längerfristig auswirkt.
Das betrifft nur die JRE und JDK von Oracle selbst, OpenJDK und andere Java Implementationen sind davon nicht betroffen und OpenJDK bleibt frei verfügbar.
Peter Eckel
Java findet man heute eigentlich fast nur noch bei Serverapplikationen. Für andere Einsatzzwecke ist die Startzeit von Java-Applikationen auch schlicht zu lang - es muß immer erst eine JVM hochgefahren werden, in der dann das eigentliche Programm läuft.
Das ist auch nicht zutreffend. Viele Fachanwendungen sind in Java geschrieben, und starten auf anderen Plattformen auch deutlich schneller als auf dem Mac. Ich sehe bei einigen großen Java Programmen kaum Unterschiede in der Startzeit zu Cocoa Apps.
+3
Peter Eckel06.05.20 15:20
gfhfkgfhfk
Peter Eckel
Java findet man heute eigentlich fast nur noch bei Serverapplikationen. Für andere Einsatzzwecke ist die Startzeit von Java-Applikationen auch schlicht zu lang - es muß immer erst eine JVM hochgefahren werden, in der dann das eigentliche Programm läuft.
Das ist auch nicht zutreffend. Viele Fachanwendungen sind in Java geschrieben, und starten auf anderen Plattformen auch deutlich schneller als auf dem Mac. Ich sehe bei einigen großen Java Programmen kaum Unterschiede in der Startzeit zu Cocoa Apps.
Ich beziehe mich hier auch gar nicht auf den Mac, mein Haupt-Arbeitssystem ist dieser Tage Linux.

Du hat mit Deinem Einwand natürlich in gewisser Weise Recht, aber das ist nicht das, was ich meinte: Es geht mir nicht um große Anwendungen, die man einmal startet und dann längere Zeit darin arbeitet (für die gilt sinngemäß das gleiche wie für Serveranwendungen - die Startzeit ist in Relation zur Laufzeit kurz). Mir geht es in erster Linie um kurzlebige Tools wie Kommandozeilenprogramme.

Eine Weile hatte ich mit einem Monitoring-Tool zu tun, das (unsinnigerweise, wie ich immer noch finde) in Java implementiert war und dessen Toolset auch komplett in Java geschrieben war. Da brauchte man dann zur Änderung einer Konfiguration oder zur Abfrage eines Status per CLI 1-2 Sekunden pro Aufruf. Was einem Einsatz in irgendwelchen automatisierten Tools komplett zuwiderlief.

Erfreulicherweise gab es ein REST-API, so daß sich der ganze Kram mit moderatem Aufwand in einer dafür geeigneten Sprache (also nicht in Java) reimplementieren ließ.

Die gute Nachricht ist, daß es das Monitoring-Tool mittlerweile nicht mehr gibt und ich von weiteren Projekten dieser Art verschont bleibe
Ceterum censeo librum facierum esse delendum.
-1
LoCal
LoCal06.05.20 15:49
gfhfkgfhfk
Das ist auch nicht zutreffend. Viele Fachanwendungen sind in Java geschrieben,
Das stimmt. Ich stolpere heute noch oft über Java-Anwendungen und leider merkt man das sehr.
gfhfkgfhfk
und starten auf anderen Plattformen auch deutlich schneller als auf dem Mac. Ich sehe bei einigen großen Java Programmen kaum Unterschiede in der Startzeit zu Cocoa Apps.

Das kann ich so nicht bestätigen. Ich habe sehr lange Java-Anwendungen mit GUI (sowohl AWT als auch Swing) als auch CLI-Anwendungen geschrieben.
Die "echte" Startzeit einer Java-Anwendung konnte auf keiner Plattform (AS400/System i, Mac, FreeBSD, Windows) mit den nativen Anwendungen mithalten. Anders sah es aber aus, wenn man die reine Performance der Anwendung betrachtet. Besonders auf der AS400 fand ich die Performance von Java-Anwendungen ziemlich beeindruckend.
Am Mac und unter Windows habe ich keine Anwendung gesehen, die mit nativen Anwendungen mithalten konnte.
Das nervigste an Java finde ich die Garbage Collection. Mag sein, dass die mittlerweile etwas verbessert wurde, aber Performance-technisch war die GC jahrelang eine Katastrophe. Und JNI kann sich auch ein ziemlicher Show-Stopper sein.

Die CD gabs übrigens damals, als SUN Java vorgestellt hatte und auf WorldTour war.



Ich hatte damals eine Einladung für München … und hatte damals null Ahnung, wie sehr mich Java ein paar Jahre später beeinflussen wird.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
0
andreasm06.05.20 16:53
Peter Eckel
Im großen und ganzen gebe ich Mecki vollkommen Recht: JavaScript wird oft für Dinge verwendet, auf die man auch ganz gut verzichten kann. Und für ziemlich viele Dinge, auf die man auch unbedingt verzichten will.

Viele Seiten verwenden JavaScript für irgendwelche tollen Animationen oder andere Webseitenfunktionen und greifen dafür auf fertige Bibliotheken zurück. Welche dann noch nichtmal auf dem eigenen Server liegen sondern extern, z.B. bei Google. Was dann zur Folge hat dass beim Aufruf der Seite teilweise mehrere Megabyte JS Skripte von extern geladen werden, über deren Inhalt und Funktionen der eigentliche Webseitenbetreiber vermutlich in 9 von 10 Fällen keinerlei Ahnung hat. Von Kontrolle ganz zu schweigen.

Ich finde das hinsichtlich Ressourcenverbrauch und aus Sicherheitsaspekten grundsätzlich mehr als problematisch.
+2
rmayergfx
rmayergfx06.05.20 17:00
Dafür gibt es so tolle Tools wie NoScript, damit bleibt man von solchen Dingen verschont.
Der Computer soll die Arbeit des Menschen erleichtern, nicht umgekehrt !
+3
AE-3506.05.20 17:38
Ein paar Zeilen Javascript für ein Hamburger-Menü oder smooth scrolling richtet ja keinen Schaden an, aber wenn dafür ganze Biliotheken geladen werden und gleich alles in React gemacht wird, hört auch für den user der Spaß auf.

Zu Java:

Basiert Android/ Kotlin nicht auf Java? Muss ja nen Grund haben, warum Google sich dafür entscheiden hatte. Weiss Jemand was darüber?
+2
ratti
ratti06.05.20 18:59
JavaScript ist eine essentielle Webtechnologie. Das beginnt bei Gridsystemen, die das gesamte Layout nach JS auslagern bis hin zu Progressive Web Apps, die gar kein klassisches Seitenorientiertes System mehr kennen, sondern wie Desktop-Programme halt nur den Kasten austauschen, der sich gerade ändert.

Keine der Websites, an denen ich in den letzten 7-8 Jahren beteiligt war, stellt ohne JavaScript noch irgendwas sinnvolles dar. Suchmaschinen kann man z.B. über prerender.io abfrühstücken, und der Anteil Nutzer, der bewusst JS deaktiviert, liegt irgendwo bei 0,0egal%

Was wollt ihr als nächstes herdiskutieren? Das manche Anwender ja Monochrom-Monitore benutzen könnten, oder Nur-Text-fähige Hercules Grafikkarten?
Lass mich kurz überlegen, welchen fiinanziellen Gewinn oder Verlust wir machen, wenn wir WAHLWEISE nicht mehr unterstützen…:
- stylische, schicke neu Technologien
- Alte Motzbüddel
+4
ratti
ratti06.05.20 20:21
Lustig, dass 3 Leute meinen Beitrag über die Unverzichtbarkeit von JavaScript downgevoted haben. Schauen wir mal in den Code des Forums, wie das Downvoting funktioniert:
<span class="IconSet ThumbDown" onclick="ScriptUtility.refreshHtmlWithUrl(this.parentNode,'/ News/CommentVote.x',{Down:1454139});" title="3 negative Stimmen"></span>
Oooooooh, man kann also nur downvoten, wenn man JavaScript aktiviert hat…!!!

Kannst Du dir gar nicht ausdenken, sowas.
+4
sillert06.05.20 21:18
ratti
JavaScript ist eine essentielle Webtechnologie. Das beginnt bei Gridsystemen, die das gesamte Layout nach JS auslagern bis hin zu Progressive Web Apps, die gar kein klassisches Seitenorientiertes System mehr kennen, sondern wie Desktop-Programme halt nur den Kasten austauschen, der sich gerade ändert.
Das geht heutzutage auch wunderbar mit CSS, ohne dass man mit Javascript rumfrickeln muss. Z-Index und ":target" schon mal gehört? Grid-Layouts? Wenn, dann ist CSS essentiell, JavaScript nur für ScriptKiddies.
ratti
Keine der Websites, an denen ich in den letzten 7-8 Jahren beteiligt war, stellt ohne JavaScript noch irgendwas sinnvolles dar. Suchmaschinen kann man z.B. über prerender.io abfrühstücken, und der Anteil Nutzer, der bewusst JS deaktiviert, liegt irgendwo bei 0,0egal%
Oh, ratti, der Nabel der Webdev-Welt…

Ganz ehrlich, Javascript ist weder nutzlos, noch essentiell. Wenn man es sinnvoll einsetzen kann, gerne. Aber es wird zu oft als fauler Ausweg genutzt, wenn man CSS nicht beherrscht und es wird viel zu viel Mist damit angestellt.
+2
ratti
ratti06.05.20 21:35
Oh, ratti, der Nabel der Webdev-Welt…

Ich will ja nicht unfair sein — wir gucken jetzt nicht bei einem Online-Office oder so. Wir gucken einfach mal nur ein paar Seiten an, die ich so normalerweise absurfe. Nur eben ohne JS:

spiegel.de: Keine Bilder ab 30% der Seite.
Facebook: „Bitte installiere einen anderen Browser“
Diese Site: Kein Voting, kein Forumseditor
ndr.de: Extrem pixelige Bilder, keine Filme, kein Voting, kein Forum
standard.at: Fehlende Bilder, Forum leer
youtube.com: Nur graue Klötze, keine Inhalte, kein Text
taz.de: „Das neue taz.de hat ein dynamischeres Layout und setzt dafür viel Javascript ein.”

Fazit: ALLE mehr oder weniger kaputt, und deutlicher reduziert als hier behauptet „dann fehlt ein Effekt“ oder „dann prüft halt erst das Backend das Formular“.

Ich warte auf den Beweis des Gegenteils: Das man noch normal surfen kann ohne JS. Aber ich ahne schon, es gibt 8 Downvotes und keinen Gegenbeweis.

Übrigens haben wir nicht mehr 2005. GERADE Animationen macht man schon lange nicht mehr mit JS, sondern mit CSS, während umgekehrt JS über Gridsysteme klassische Layoutformatierung übernommen hat.
+2
LoCal
LoCal06.05.20 23:57
ratti
des Gegenteils: Das man noch normal surfen kann ohne JS. Aber ich ahne schon, es gibt 8 Downvotes und keinen Gegenbeweis.

Apple.com, google.com, blog.fefe.de, daringfireball.net, golem.de, br.de, mbasic.facebook.com
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
+1
AE-3507.05.20 01:11
@ratti
„Gridsysteme“? Nach JS auslagern?
0
ratti
ratti07.05.20 06:31
LoCal
ratti
des Gegenteils: Das man noch normal surfen kann ohne JS. Aber ich ahne schon, es gibt 8 Downvotes und keinen Gegenbeweis.

Apple.com, google.com, blog.fefe.de, daringfireball.net, golem.de, br.de, mbasic.facebook.com

Apple.com: Sprachauswahl im Header verschwindet, ob ich nach DE wechseln will. Der Kaufversuch eines iPhone läuft nur noch im Kreis und ist nicht möglich.

google.com: Das App-Menü wird dargestellt, funktioniert aber nicht mehr und wird zum Link auf den Assistenten. Nach einer Google-Suche sind die gesamten Filtermenüs verschwunden und führen auf eigene Unterseiten. Funktionen wie „Im Archiv anzeigen“ sind komplett weg.

Fefe, daringfireball: Na toll, Sites ohne irgendwelche Funktionalität und ohne Bilder… wenn von vornherein keine Funktion da ist, kann natürlich auch nix fehlen. Vierzig Mark Strafe für Fußgänger, weil: Kein Licht, keine Bremse, nicht angeschnallt,…

golem: Ja, stimmt.

br.de : Erse Meldung angeklickt, steht da groß „Hinweis: Um alle Funktionen unserer Seiten nutzen zu können, wird JavaScript empfohlen.“. Auf den ersten Blick: Diskussionsforum weg, eingebettetes Forum weg.

mbasic.facebook.com ist halt nicht facebook.com, alles was dort geht, ist da entfernt.
+2
ratti
ratti07.05.20 06:41
AE-35
@ratti
„Gridsysteme“? Nach JS auslagern?
Der Kollege hatte ja br.de vorgeschlagen, da siehst Du's ganz gut, wenn Du an der Fenstergröße ziehst. Ohne JavaScript hast Du starre Breakpoints, mit JavaScript ein elastisches Layout.

So kenne ich das eigentlich nur noch, dass man weg ist von CSS und Kombinationen aus prozentualen Breiten mit festen Abständen, sondern das einfach von JS onResize berechnen lässt.

Da man aktuell eine Site ohnehin auf React & Co aufsetzt, macht das auch deutlich mehr Sinn.
-3
ExMacRabbitPro07.05.20 07:15
Es gibt keine großen Java Desktop Anwendungen....?
Nutzt jemand Eclipse?
+3
jgraux07.05.20 09:36
Peter Eckel
Für andere Einsatzzwecke ist die Startzeit von Java-Applikationen auch schlicht zu lang - es muß immer erst eine JVM hochgefahren werden, in der dann das eigentliche Programm läuft.
Peter Eckel
Eine Weile hatte ich mit einem Monitoring-Tool zu tun, das (unsinnigerweise, wie ich immer noch finde) in Java implementiert war und dessen Toolset auch komplett in Java geschrieben war. Da brauchte man dann zur Änderung einer Konfiguration oder zur Abfrage eines Status per CLI 1-2 Sekunden pro Aufruf. Was einem Einsatz in irgendwelchen automatisierten Tools komplett zuwiderlief.

Das mit den 1-2 Sekunden mag ja sein, aber mit Java hat das nix zu tun. Ein aktuelles OpenJDK 14 braucht (auf meinem MBP) so um die 100ms um ein "Hello World" abzusetzen. Und ja, auch dazu muss die JVM hochgefahren werden. Und selbst ein älteres Oracle Java 8 ist nur ca. 10% langsamer...
0
Peter Eckel07.05.20 10:13
jgraux
Das mit den 1-2 Sekunden mag ja sein, aber mit Java hat das nix zu tun. Ein aktuelles OpenJDK 14 braucht (auf meinem MBP) so um die 100ms um ein "Hello World" abzusetzen. Und ja, auch dazu muss die JVM hochgefahren werden. Und selbst ein älteres Oracle Java 8 ist nur ca. 10% langsamer...
Mit einem einfachen "Hello World" hatte das auch nicht so viel zu tun.

Zum einen ist der Aufruf des entsprechenden jar dermaßen lang, daß man das natürlich nicht manuell machen konnte, sondern in ein Shellscript verpackt hat. Zum anderen kommt zur Ladezeit für die JVM die des eigentlichen jar, das aufgrund diverser Abhängigkeiten nicht unbeträchtlich groß war.

Und ja, schlecht geschrieben war's auch noch. Aber das hat dann auch nicht mehr so viel ausgemacht.

Wer das Zeug verwenden mag und einen geeigneten Anwendungszweck hat, mag sich gern damit abgeben. Ich kenne sogar Leute, denen das Spaß macht. Aber ich werde Java, wenn Oracle es dereinst hinbekommen hat, es mit Lizenzbedingungen und anderen Winkelzügen kaputtzubekommen, keine Träne nachweinen.
Ceterum censeo librum facierum esse delendum.
-2
gfhfkgfhfk07.05.20 10:44
Peter Eckel
Du hat mit Deinem Einwand natürlich in gewisser Weise Recht, aber das ist nicht das, was ich meinte: Es geht mir nicht um große Anwendungen, die man einmal startet und dann längere Zeit darin arbeitet (für die gilt sinngemäß das gleiche wie für Serveranwendungen - die Startzeit ist in Relation zur Laufzeit kurz). Mir geht es in erster Linie um kurzlebige Tools wie Kommandozeilenprogramme.
Ja, dafür war Java noch nie eine sinnvolle Umgebung, aber wer nur einen Hammer kennt, der nutzt ihn auch für Schrauben.
LoCal
gfhfkgfhfk
und starten auf anderen Plattformen auch deutlich schneller als auf dem Mac. Ich sehe bei einigen großen Java Programmen kaum Unterschiede in der Startzeit zu Cocoa Apps.

Das kann ich so nicht bestätigen. Ich habe sehr lange Java-Anwendungen mit GUI (sowohl AWT als auch Swing) als auch CLI-Anwendungen geschrieben.
Ich bezog mich darauf, dass unter Linux Java Anwendungen ähnlich schnell starten wie Cocoa Anwendungen unter macOS. macOS ist nicht gerade schnell, was das Starten von Applikationen betrifft.
LoCal
Besonders auf der AS400 fand ich die Performance von Java-Anwendungen ziemlich beeindruckend.
Auf einer AS/400 läuft gar keine Anwendung nativ, sondern wird in einen speziellen Bytecode übersetzt, den die Plattform ausführt.
LoCal
Am Mac und unter Windows habe ich keine Anwendung gesehen, die mit nativen Anwendungen mithalten konnte.
Von der Performance? Das mag daran liegen, dass SUN Java für Solaris entwickelt hatte, und daher Java auf *I*X Plattformen mit X11 schneller läuft. macOS ist als *I*X Plattform eher träge und langsam. Ich erinnere mich noch daran, wie die erste OpenOffice Version nur für X11 auf dem Mac verfügbar war. Diese Version scrollte schneller als jede native Mac Applikation. Die erste OpenOffice Version mit Mac Oberfläche war eine Offenbarung – in Langsamkeit.
+2
LoCal
LoCal07.05.20 12:24
gfhfkgfhfk
Ja, dafür war Java noch nie eine sinnvolle Umgebung, aber wer nur einen Hammer kennt, der nutzt ihn auch für Schrauben.

Was nicht richtig ist, im Sinne der Wiederverwertbarkeit kann es durchaus sinnvoll sein.
Und warum sollte man
  • für eine UI, die auf andere Libraries aufsetzt
  • für 2 - 3 GUI-Apps vs. 100 ServerSide-Apps
  • einem Büro voller Java-Entwickler (der Rest RPG und CL)
auf eine andere Programmiersprache setzen?

gfhfkgfhfk
LoCal
Besonders auf der AS400 fand ich die Performance von Java-Anwendungen ziemlich beeindruckend.
Auf einer AS/400 läuft gar keine Anwendung nativ, sondern wird in einen speziellen Bytecode übersetzt, den die Plattform ausführt.

Trotzdem ist RPG voll auf die Plattform optimiert, was Java nicht ist.
LoCal
Am Mac und unter Windows habe ich keine Anwendung gesehen, die mit nativen Anwendungen mithalten konnte.
Von der Performance? Das mag daran liegen, dass SUN Java für Solaris entwickelt hatte, und daher Java auf *I*X Plattformen mit X11 schneller läuft. macOS ist als *I*X Plattform eher träge und langsam. Ich erinnere mich noch daran, wie die erste OpenOffice Version nur für X11 auf dem Mac verfügbar war. Diese Version scrollte schneller als jede native Mac Applikation. Die erste OpenOffice Version mit Mac Oberfläche war eine Offenbarung – in Langsamkeit.
[/quote]

Was hat OpenOffice und X11 mit Java zu tun? Besonders die ersten Versionen von OpenOffice waren auf allen Plattformen eine Katastrophe!
Weiter war/ist OS X/macOS nie eine primäre Plattform für X11-Anwendungen, das war eher ein Kr/Brücke.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
-2
Mecki
Mecki07.05.20 13:59
R-Waves
Ohne JS wird dann aber auch bei sehr vielen Seiten der "Senden"-Button nicht freigegeben
Ja, aber auch dort meistens zu unrecht. Gibst du den manuell frei, dann lässt sich das Formular auch ohne JS korrekt absenden. Und auch dann werden die Eingaben vom Server geprüft, denn wäre das nicht der Fall, dann kann jeder Hacker diesen Server in Minuten zerlegen, denn der umgeht jeden JS Test einfach (alles was clientseitig ist, kann ein Hacker umgehen, echter Schutz ist nur serverseitig realisierbar). Und wie gesagt, mit JS wird viel leider unnützes und auch unsinniges Zeugs fabriziert. Daher sollte JS eigentlich die Ausnahme und nicht die Regel sein. Bei den meisten Seiten gibt es überhaupt keinen nachvollziehbaren Grund, warum die auf JS bestehen oder bestehen müssten.
+3
Mecki
Mecki07.05.20 14:47
Zu Java:

Die Sprache ist zu verbose, zu unflexibel, zu inkonsequent, viele wichtige Features kamen viel zu spät und die Standard API ist ein gigantisches eierlegende Wollmilchsau-Monster.

Und die Runtime krankt seit 20 Jahren an den selben Problemen herum: zu groß (wegen der Monster-Standard-API), zu langsamer Start, viel zu hoher Speicherverbrauch, schlechter GC, zu zaghaftes JIT Compiling und zu komplexer nativer Code.

Und Write-Once-Run-Everywhere ist ein Versprechen, das nie erfüllt wurde und heute weniger gilt als jemals zuvor. Obwohl JavaScript eine sogar noch viel furchtbarere Sprache ist (vor allem konzeptionell), kommt man heute mit JavaScript weiter, wenn man crossplatform Apps schreiben möchte, die sich möglichst nativ anfühlt und mit vernünftiger Performance auf allen wichtigen Plattformen laufen sollen; die App wird sogar viel kleiner und verbraucht weniger Speicher als mit Java. Die Performance ist zwar etwas schlechter, aber fast immer ausreichend und dazu konstant und nicht massiv schwankend.
-1
Weitere News-Kommentare anzeigen

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.