1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Java: Nicht die Bohne…

Die Gründe für Java

Am 17. Juli erscheint Ghost of Tsushima; Assassin's Creed Valhalla und Watch Dogs Legions konnten wir auch gerade länger anspielen - Anlass genug, um über Actionspiele, neue Games und die Next-Gen-Konsolen zu sprechen! Unser Chef-Abenteurer Peter Steinlechner stellt sich einer neuen Challenge: euren Fragen.
Er wird sie am 16. Juli von 14 Uhr bis 16 Uhr beantworten.
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Die Gründe für Java

    Autor: twothe 26.05.20 - 14:20

    Einer der Kerngründe warum Java gerade in Unternehmen so erfolgreich ist wird gerne mal übersehen bzw. nicht verstanden.

    Ja, Java ist Plattformunabhängig und erlaubt damit Unternehmen Software sehr sehr lange einzusetzen. Ich habe beispielsweise bei der Telekom noch Software gewartet, die mit Java 1.3 geschrieben wurde und immer noch im Einsatz ist, auch wenn sich die Hardware öfters gewechselt haben dürfte.

    Ein vielfach übersehener Vorteil ist aber ein ganz anderer: die Standardbibliothek ist nicht nur sehr umfangreich, sie ist außerdem in nahezu jeder Hinsicht absolut brilliant, zuverlässig und erstklassig dokumentiert. Arbeiten mit Java ist daher wie Porsche fahren: alles klappt, nichts klappert, und man kommt zügig da an wo man hin will.

    Nimmt man die ConcurrentHashMap als Beispiel, dann offenbart sich die Qualität der Algorithmen in der Bibliothek sehr offensichtlich. Nicht nur das die HashMap "mal eben so" dem Programmierer erlaubt ohne das irgendwelche Verrenkungen notwendig wären mit mehreren Threads auf diese Datenklasse zuzugreifen, intern werkeln zudem Algorithmen, die eine maximale Parallelität erlauben. Da ist nicht einfach ein Lock um die Funktionen geklatscht wie man das aus anderen Bibliotheken kennt, tatsächlich arbeitet die Map so lock-frei wie möglich, und kann damit parallele Zugriffe im Regelfall ohne nennenswerte Verzögerungen bedienen.

    In anderen Programmiersprachen muss man für so ein Feature lange Bibliotheken mit fragwürdigem Support durchforsten, bei Java gibt es so etwas direkt frei Haus. Dadurch macht das Arbeiten nicht nur Spaß, sondern es ist auch hochgradig effizient. Projekte lassen sich zügig umsetzen, da man sich nicht um die Sprache, den Compiler oder die Hardware kümmern muss, und das spart bares Geld. Bei Projekten die 10 Jahre oder mehr im Einsatz sein sollen kann man eben nicht riskieren die Bibliothek von Hinz und Kunz einzusetzen, denn wer weiß ob da in 5 Jahren noch Bugs dran gefixed werden?

    Natürlich gibt es auch mit Java immer noch Leute die erst mal 20 andere Bibliotheken installieren, die die Standardfunktionen nachbilden, nur schlechter. Auf die Frage warum hört man dann im Regelfall so aussagen wie "Der Standardbibliothek trau ich nicht." Die beste Sprache kann eben auch nichts gegen zu viel Dummheit vor dem Bildschirm ausrichten.

  2. Re: Die Gründe für Java

    Autor: Serenity 26.05.20 - 15:10

    Dafür sind alle Programme in Java ein grauß und extrem langsam.
    Es gibt nur wenige Programme, die ich nutze und in Java programmiert sind, aber gerade bei denen merk ich einfach, wie langsam und träge diese ist.
    Es kann sein, dass du Spaß hast, in Java zu programmieren, nur die Nutzer haben kein Spaß daran, die Programme zu nutzen. Ich nutze Java-Programme auch nur, weil es funktionell keine bessere Alternative gibt.
    Mal ein Beispiel: Eclipse ist (bzw. war) sehr umfangreich was Plugins und Funktionen angeht. Mittlerweile nutze ich lieber für alles zum Programmieren den Qt Creator, auch wenn ich nicht in Qt programmiere. Dieser ist von der UI einfach deutlich angenehmer.

  3. Re: Die Gründe für Java

    Autor: nachgefragt 26.05.20 - 15:33

    Also erstmal glaube ich dir nicht das du sehr wenig Java Programme nutzt.
    Es sei denn du besitzt kein Smartphone, dann glaube ich dir das natürlich, hätte dann aber daran anknüpfende Fragen.

    Zweitens glaube ich, dass dir bei dem Großteil der Java Programme nicht mal auffällt dass Sie in Java erstellt wurden.

    Drittens ist das mit den "langsamen Java" eine alte Mär. Ein JIT Compile kommt (ordentlich programmiert) fast an C++ ran.

    Aber ja, beim Bedienen des SAP Clients oder Google Chrome haben wohl nur wenigsten Leute Spaß, wobei da wohl was anderes schnarchen langsam ist.
    Und warum der Dependency-Urwald NodeJS so populär geworden ist, habe ich auch nie wirklich verstanden.



    4 mal bearbeitet, zuletzt am 26.05.20 15:38 durch nachgefragt.

  4. Re: Die Gründe für Java

    Autor: Winny 26.05.20 - 16:03

    Serenity schrieb:
    --------------------------------------------------------------------------------
    > Es gibt nur wenige Programme, die ich nutze und in Java programmiert sind,
    Da wäre ich mir nicht so sicher. Wer Services wie Netflix, eBay, Google, Amazon benutzt oder gar ein Android Smartphone besitzt, benutzt Java.

  5. Re: Die Gründe für Java

    Autor: zilti 26.05.20 - 16:18

    Serenity schrieb:
    --------------------------------------------------------------------------------
    > Mal ein Beispiel: Eclipse ist (bzw. war) sehr umfangreich was Plugins und
    > Funktionen angeht. Mittlerweile nutze ich lieber für alles zum
    > Programmieren den Qt Creator, auch wenn ich nicht in Qt programmiere.
    > Dieser ist von der UI einfach deutlich angenehmer.

    Eclipse ist (bzw. war) wahrscheinlich auch das einzige Java-Programm, das du je verwendet hast. Es nutzt weder die Java-eigene GUI-Bibliothek noch ist es auch nur im Entferntesten anständig programmiert. Das Ding ist ein Monster. Lahm, mühsam, grässlich. Warum es immer noch so viele gibt die darauf schwören, wo es doch IDEs wie IntelliJ gibt, ist mir ein Rätsel.

  6. Re: Die Gründe für Java

    Autor: Dino13 26.05.20 - 16:22

    zilti schrieb:
    --------------------------------------------------------------------------------
    > Serenity schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Mal ein Beispiel: Eclipse ist (bzw. war) sehr umfangreich was Plugins
    > und
    > > Funktionen angeht. Mittlerweile nutze ich lieber für alles zum
    > > Programmieren den Qt Creator, auch wenn ich nicht in Qt programmiere.
    > > Dieser ist von der UI einfach deutlich angenehmer.
    >
    > Eclipse ist (bzw. war) wahrscheinlich auch das einzige Java-Programm, das
    > du je verwendet hast. Es nutzt weder die Java-eigene GUI-Bibliothek noch
    > ist es auch nur im Entferntesten anständig programmiert. Das Ding ist ein
    > Monster. Lahm, mühsam, grässlich. Warum es immer noch so viele gibt die
    > darauf schwören, wo es doch IDEs wie IntelliJ gibt, ist mir ein Rätsel.

    Eclipse wurde anhand von EMF (Eclipse Modelling Framework) aufgebaut, und das ist wahrlich kein Vergnügen. Man muss sich nur auf StackOverflow ansehen wie viele Topics es zum Thema EMF, Ecore etc gibt.

  7. Re: Die Gründe für Java

    Autor: captain_spaulding 26.05.20 - 16:36

    Eclipse ist nunmal das am weitesten verbreitete Java-Programm unter Entwicklern.
    Dass Java theoretisch eigentlich schon recht performant ist im Vergleich zu anderen VM-Sprachen fällt da nicht auf.
    Mir sind auf dem Desktop auch keine guten Java-Programme bekannt. Worauf irgendwelche Webseiten laufen sieht man nicht. Einige Entwicklungstools wie Jira, Bitbucket, Jenkins sind auch Java und sind arschlahm. Android-Apps sind im Vergleich zu iOS-Apps unperformant.

    Immerhin sind Electron-Apps genauso lahm, das lässt Java immerhin in besserem Licht erscheinen.:)

  8. Re: Die Gründe für Java

    Autor: twothe 26.05.20 - 18:01

    Java ist von der Performance her im Mittel bei 1.8 C (laut Benchmarkgame). D.h. ein vergleichbares C-Programm läuft rund doppelt so schnell. Spiele damit zu programmieren ist daher nicht sonderlich sinnvoll, aber bei einem Programm wo man 99% der Zeit aber auf Nutzereingaben wartet ist das völlig egal.

    Das Problem mit Java sitzt fast immer vor dem Bildschirm. Ich sehe das häufig bei meiner täglichen Arbeit, dass bei neuen Java-Projekten erst mal 20 Bibliotheken rein geladen werden und selbst simpelste Aufgaben maximal abstrahiert werden, ohne Sinn und Verstand. Das beste Beispiel dürfte der Tomcat sein, der nicht nur vor Bugs strahlt, sondern auch unglaublich träge ist. Ich habe damals mit Tomcat 8 Performance-Messungen gemacht, und es dauert allein 20ms bis eine eingehende Anfrage sich durch den Tomcat-Code geschlichen hat und beim eigentlichen Programm ankommt.

    Tomcat, Eclipse und Hibernate sind leider aber auch die Vorzeige-Projekte von Java, eines überladener und überfrachteter als das nächste, und im Regelfall völlig unnötig. Dann noch ein bisschen Spring mit XML-Abstraction drüber und man bekommt auch den schnellsten Prozessor auf das Niveau eines 486. Der Punkt dabei ist: das wäre mit C++ genau so lahm, nur sind die C++-Entwickler von Natur aus eher auf Performance getrimmt und machen so einen Mist nicht. Und auch in java ist das völlig unnötig.

  9. Re: Die Gründe für Java

    Autor: Dino13 26.05.20 - 18:06

    captain_spaulding schrieb:
    --------------------------------------------------------------------------------
    > Eclipse ist nunmal das am weitesten verbreitete Java-Programm unter
    > Entwicklern.
    > Dass Java theoretisch eigentlich schon recht performant ist im Vergleich zu
    > anderen VM-Sprachen fällt da nicht auf.
    > Mir sind auf dem Desktop auch keine guten Java-Programme bekannt. Worauf
    > irgendwelche Webseiten laufen sieht man nicht. Einige Entwicklungstools wie
    > Jira, Bitbucket, Jenkins sind auch Java und sind arschlahm. Android-Apps
    > sind im Vergleich zu iOS-Apps unperformant.
    >
    > Immerhin sind Electron-Apps genauso lahm, das lässt Java immerhin in
    > besserem Licht erscheinen.:)

    Eclipse ist nicht wirklich in Java entwickelt, sondern mit EMF / OSGi welches dann Java Code erzeugt, wie effektiv solche Sachen sind kann man sich ausmalen, aber die Idee von Eclipse war dass diese auch beliebig anpassbar und verwendbar ist. Wenn wir von Performance reden kann man da gut und gerne mal IntelliJ (oder PhpStorm, WebStorm, PyCharm) mit VisualStudio vergeleichen.

  10. Re: Die Gründe für Java

    Autor: Dino13 26.05.20 - 18:10

    twothe schrieb:
    --------------------------------------------------------------------------------
    > Java ist von der Performance her im Mittel bei 1.8 C (laut Benchmarkgame).
    > D.h. ein vergleichbares C-Programm läuft rund doppelt so schnell. Spiele
    > damit zu programmieren ist daher nicht sonderlich sinnvoll, aber bei einem
    > Programm wo man 99% der Zeit aber auf Nutzereingaben wartet ist das völlig
    > egal.
    >
    > Das Problem mit Java sitzt fast immer vor dem Bildschirm. Ich sehe das
    > häufig bei meiner täglichen Arbeit, dass bei neuen Java-Projekten erst mal
    > 20 Bibliotheken rein geladen werden und selbst simpelste Aufgaben maximal
    > abstrahiert werden, ohne Sinn und Verstand. Das beste Beispiel dürfte der
    > Tomcat sein, der nicht nur vor Bugs strahlt, sondern auch unglaublich träge
    > ist. Ich habe damals mit Tomcat 8 Performance-Messungen gemacht, und es
    > dauert allein 20ms bis eine eingehende Anfrage sich durch den Tomcat-Code
    > geschlichen hat und beim eigentlichen Programm ankommt.
    >
    > Tomcat, Eclipse und Hibernate sind leider aber auch die Vorzeige-Projekte
    > von Java, eines überladener und überfrachteter als das nächste, und im
    > Regelfall völlig unnötig. Dann noch ein bisschen Spring mit XML-Abstraction
    > drüber und man bekommt auch den schnellsten Prozessor auf das Niveau eines
    > 486. Der Punkt dabei ist: das wäre mit C++ genau so lahm, nur sind die
    > C++-Entwickler von Natur aus eher auf Performance getrimmt und machen so
    > einen Mist nicht. Und auch in java ist das völlig unnötig.

    Hibernate ist halt wunderbar weil man über nichts nachdenken muss. Da wird dann einfach eine Tabelle aus der Datenbank geholt und mittels Hibernate gemappt. Ein riesen großer Spaß das ganze.

  11. Re: Die Gründe für Java

    Autor: lestard 26.05.20 - 20:16

    Das Argument finde ich nicht sehr überzeugend. Die Doku für das, was in der Standard-Lib drin ist, mag ja gut sein aber, dass die Standard-Lib alles umfasst, "was man so braucht" stimmt doch nicht. Sonst gäbe es ja nicht diese riesige Anzahl an Frameworks und Dritt-Bibliotheken. Die gibt es doch nur, weil es eben sehr wohl große Lücken im SDK gibt.
    Und wenn du da jetzt eine Klasse als Beispiel rausziehst, sagt das doch nichts über den Rest aus.

  12. Re: Die Gründe für Java

    Autor: slax 26.05.20 - 21:33

    twothe schrieb:
    --------------------------------------------------------------------------------
    > Nimmt man die ConcurrentHashMap als Beispiel, dann offenbart sich die
    > Qualität der Algorithmen in der Bibliothek sehr offensichtlich. Nicht nur
    > das die HashMap "mal eben so" dem Programmierer erlaubt ohne das
    > irgendwelche Verrenkungen notwendig wären mit mehreren Threads auf diese
    > Datenklasse zuzugreifen, intern werkeln zudem Algorithmen, die eine
    > maximale Parallelität erlauben. Da ist nicht einfach ein Lock um die
    > Funktionen geklatscht wie man das aus anderen Bibliotheken kennt,
    > tatsächlich arbeitet die Map so lock-frei wie möglich, und kann damit
    > parallele Zugriffe im Regelfall ohne nennenswerte Verzögerungen bedienen.

    Ja, in irgendeinem 100 Zeilen Benchmark wird man auch compilierte Programmiersprachen schlagen können.
    Ansonsten würde wahrscheinlich jede single threaded Anwendung in einer brauchbaren Sprache Kreise um Java ziehen.


    nachgefragt schrieb:
    --------------------------------------------------------------------------------
    > Also erstmal glaube ich dir nicht das du sehr wenig Java Programme nutzt.
    > Es sei denn du besitzt kein Smartphone, dann glaube ich dir das natürlich,
    > hätte dann aber daran anknüpfende Fragen.
    >
    > Zweitens glaube ich, dass dir bei dem Großteil der Java Programme nicht mal
    > auffällt dass Sie in Java erstellt wurden.
    >
    > Drittens ist das mit den "langsamen Java" eine alte Mär. Ein JIT Compile
    > kommt (ordentlich programmiert) fast an C++ ran.
    >
    > Aber ja, beim Bedienen des SAP Clients oder Google Chrome haben wohl nur
    > wenigsten Leute Spaß, wobei da wohl was anderes schnarchen langsam ist.
    > Und warum der Dependency-Urwald NodeJS so populär geworden ist, habe ich
    > auch nie wirklich verstanden.

    Dieses Gerücht, das Java an C++ rankommt hält sich auch schon seit 10 Jahren hartnäckig.
    Am Ende des Tages geht das da um 100 Zeilen Benchmark Code der durch glücklichen Zufall schneller ausgeführt wird. In Real-world Applikationen ist Java nie schneller als was compiliertes, das kann man in einer compilierten Sprache nicht so verkacken das es langsamer ist.

    Im Übrigen fällt die miese Performance beim "Großteil" der Java Programme nicht auf, weil dort alles was auch nur den Hauch von Performance in einer compilierten Sprache geschrieben wird. Java ist dann nur noch Glue Code um das auszuführen.


    Dino13 schrieb:
    --------------------------------------------------------------------------------
    > captain_spaulding schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Eclipse ist nunmal das am weitesten verbreitete Java-Programm unter
    > > Entwicklern.
    > > Dass Java theoretisch eigentlich schon recht performant ist im Vergleich
    > zu
    > > anderen VM-Sprachen fällt da nicht auf.
    > > Mir sind auf dem Desktop auch keine guten Java-Programme bekannt. Worauf
    > > irgendwelche Webseiten laufen sieht man nicht. Einige Entwicklungstools
    > wie
    > > Jira, Bitbucket, Jenkins sind auch Java und sind arschlahm. Android-Apps
    > > sind im Vergleich zu iOS-Apps unperformant.
    > >
    > > Immerhin sind Electron-Apps genauso lahm, das lässt Java immerhin in
    > > besserem Licht erscheinen.:)
    >
    > Eclipse ist nicht wirklich in Java entwickelt, sondern mit EMF / OSGi
    > welches dann Java Code erzeugt, wie effektiv solche Sachen sind kann man
    > sich ausmalen, aber die Idee von Eclipse war dass diese auch beliebig
    > anpassbar und verwendbar ist. Wenn wir von Performance reden kann man da
    > gut und gerne mal IntelliJ (oder PhpStorm, WebStorm, PyCharm) mit
    > VisualStudio vergeleichen.

    Kenne Intellij nicht, ich nutze CLion, da das von der gleichen Firma kommt denke ich mal das dass ähnliche Codebasis hat. Die Performance von CLion ist auch dermaßen unterirdisch, das lässt sich mit was compilierten so nicht verkacken.
    Und der Vergleich mit Visual Studio ist auch Quatsch. Nimm Visual Studio 2008, das war das letzte VS welches in einer compilierten Sprache erstellt wurde. Dort war die Performance ziemlich gut, dafür dass die Hardware damals deutlich langsamer war. Ab 2010 ist es (sukzessive) auf .net umgestellt worden. Ist halt nicht so lahm wie Java aber näher an Java als an C++. Alle Versionen seit 2010 haben auch eine unterirdische Performance.


    Serenity schrieb:
    --------------------------------------------------------------------------------
    > Dafür sind alle Programme in Java ein grauß und extrem langsam.
    > Es gibt nur wenige Programme, die ich nutze und in Java programmiert sind,
    > aber gerade bei denen merk ich einfach, wie langsam und träge diese ist.
    > Es kann sein, dass du Spaß hast, in Java zu programmieren, nur die Nutzer
    > haben kein Spaß daran, die Programme zu nutzen. Ich nutze Java-Programme
    > auch nur, weil es funktionell keine bessere Alternative gibt.
    > Mal ein Beispiel: Eclipse ist (bzw. war) sehr umfangreich was Plugins und
    > Funktionen angeht. Mittlerweile nutze ich lieber für alles zum
    > Programmieren den Qt Creator, auch wenn ich nicht in Qt programmiere.
    > Dieser ist von der UI einfach deutlich angenehmer.

    Qt Creator ist von der Performance her Benchmark, was C++ IDEs angeht.
    Leider hat er viele Features nicht die z.B. CLion hat.

  13. Re: Die Gründe für Java

    Autor: Trockenobst 26.05.20 - 23:02

    zilti schrieb:
    --------------------------------------------------------------------------------
    > Das Ding ist ein Monster. Lahm, mühsam, grässlich.

    Dann lässt du es nicht mit Java 8+ laufen und hast zu viele sinnfreie Plugins aktiv.
    Ich gebe dem Ding 8GB Mem in der VM und das Ding fliegt. Wenn ich den "." Punkt
    drücke, sehe ich genauso schnell wie in Visual Studio TypeAssist.

    Am Anfang eines Projekts muss Eclipse viel cachen, später wenn die aufgefüllt sind,
    geht alles rasend schnell. Compilieren geht in der Konsole nicht schneller!

    Eclipse macht viel parallel, wer natürlich nur früher einen Intel Prozessor hatte, haben
    sich zwei oder vier Kerne um 100te von Aufgaben geprügelt. Seit dem Ryzen 2600
    mit 12 Threads habe ich keine Probleme mehr. IntelliJ ist anders, aber nicht schneller.
    Dafür macht es mir zu viel hinter den Kulissen. Das gefällt mir bei Visual Studio auch nicht.

  14. Re: Die Gründe für Java

    Autor: Serenity 27.05.20 - 10:31

    nachgefragt schrieb:
    --------------------------------------------------------------------------------
    > Also erstmal glaube ich dir nicht das du sehr wenig Java Programme nutzt.
    > Es sei denn du besitzt kein Smartphone, dann glaube ich dir das natürlich,
    > hätte dann aber daran anknüpfende Fragen.

    iPhone?
    Hab hier auch noch ein Windows Phone, Meego Handy und ein BB10 Smartphone. Alle "Java-frei".

    > Zweitens glaube ich, dass dir bei dem Großteil der Java Programme nicht mal
    > auffällt dass Sie in Java erstellt wurden.

    Doch, weil diese dann sehr träge wären. Das merkt man sofort.
    Nenn doch mal populäre Java Programme, die ein 0815 Nutzer haben könnte.

    > Drittens ist das mit den "langsamen Java" eine alte Mär. Ein JIT Compile
    > kommt (ordentlich programmiert) fast an C++ ran.

    Stimmt nicht, es gibt sogar wissenschaftliche Studien dazu. Habe ich ein Paper rumliegen, dass die Performance von Java, C und Fortran in Bezug auf numerische Operationen vergleicht. Java scheidet da super schlecht ab. Danach widmet sich der Autor darüber, wie man sehr müheselig die Performance einer einfachen Matrizenmultiplikation in Java verbessern kann, damit es an C rankommen kann.

    > Aber ja, beim Bedienen des SAP Clients oder Google Chrome haben wohl nur
    > wenigsten Leute Spaß, wobei da wohl was anderes schnarchen langsam ist.
    > Und warum der Dependency-Urwald NodeJS so populär geworden ist, habe ich
    > auch nie wirklich verstanden.

    Ich nutze übrigens kein Google Chrome und finde SAP auch ziemlich lahm und träge, Ist das in Java geschrieben? Das würde einiges erklären. Ich kenne auch keinen, der gerne mit SAP arbeitet.

    Winny schrieb:
    --------------------------------------------------------------------------------
    > Serenity schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Es gibt nur wenige Programme, die ich nutze und in Java programmiert
    > sind,
    > Da wäre ich mir nicht so sicher. Wer Services wie Netflix, eBay, Google,
    > Amazon benutzt oder gar ein Android Smartphone besitzt, benutzt Java.

    Ich hätte schreiben sollen "am PC". Bei Android kommt man leider nicht herum, weshalb ich Meego, Windows Phone und BB10 auch vermisse. Doch kann ich auch ein iPhone haben, dann wäre ich Java-Frei. Und Android ist auch auf dem Smartphone sehr träge. Ich dachte immer, dass durch die neuen Smartphones und besserer Hardware alles besser wird. Leider tut es das nicht, weil Java einfach so ein sch***** ist.
    Außerdem glaube (und teilweise weiß ich es auch) ich nicht, dass Amazon, ebay oder Netflix Java nutzen... zumindest wird es nicht auf meinem Rechner genutzt.



    1 mal bearbeitet, zuletzt am 27.05.20 10:32 durch Serenity.

  15. Re: Die Gründe für Java

    Autor: twothe 27.05.20 - 12:32

    lestard schrieb:
    --------------------------------------------------------------------------------
    > Sonst gäbe es ja nicht diese riesige Anzahl an Frameworks und Dritt-Bibliotheken. Die gibt es doch nur, weil es eben sehr wohl große Lücken im SDK gibt.

    Dazu fällt mir ein gutes Beispiel von einer Firma ein, die ein teures Cache-Framework eingekauft hatte um Daten zu cachen. Ich hatte als ich dazu kam dann die Frage wofür das eigentlich gebraucht wird. Es kam die üblichen Erklärungen, dass die Java-Libs so was ja nicht hergeben und man brauch das ja. Ich hab dann sämtliche genutzte Funktionalitäten dieser 5mb Caching Library in 20 Zeilen Java Code nur mit Standard-Lib nachprogrammiert. Und das war - völlig überraschend - auch erheblich schneller und hat viele Performance-Probleme gelöst. Da ist bei einigen Kollegen erst mal die Kinnlade runter geklappt.

    In einem Projekt für die Bundeswehr war die Vorgabe nur die Standard-Lib zu nutzen, es sei denn es geht absolut nicht anders. Datenbankzugriffe nur mit Standard-Lib... "Das kann ja was werden" hab ich am Anfang gedacht. Als ich fertig war, und gelernt habe wie unglaublich einfach das ist, hab ich mich gefragt warum ich eigentlich jemals Hibernate eingesetzt habe.

    Der Grund warum viele Leute Libs in ihre Projekte kippen ist im Regelfall weil sie keine Ahnung haben, dass die Standard-Lib das auch alles kann.

    > Ansonsten würde wahrscheinlich jede single threaded Anwendung in einer brauchbaren Sprache Kreise um Java ziehen.

    Ich habe mal einen Programmierwettbewerb wo es nur um Performance ging gewonnen, weil mein Java-Programm die Aufgabe rund 100x schneller gelöst hat als das beste C-Programm. ;)
    Der Grund dafür war, dass ich einen sehr komplexen Algorithmus problemlos einsetzen konnte, da mir Java mit der Standard-Lib alles an die Hand gegeben hat was ich brauchte. 3 Zeilen und die Sache war fertig. Das selbe in C nach zu programmieren hätte Monate gedauert.

    > In Real-world Applikationen ist Java nie schneller als was compiliertes, das kann man in einer compilierten Sprache nicht so verkacken das es langsamer ist.

    Also ich kenne da einige Kollegen, die könnten dir gerade im 2. Teil deines Satzes noch viel Neues zeigen. :D
    Übrigens heißt JIT-Compile just-in-time compiling. D.h. Java wird tatsächlich zu lokalem Maschinencode gewandelt. Bei entsprechenden Programmen bzw. JVM Settings gibt es also keinen Unterschied zwischen Java und "was compiliertem." Der einzige Grund warum hochoptimierter C-Code dennoch schneller ist, ist weil man sich in C problemlos über die Sprachbarrieren von Java hinwegsetzen und willkürlich im Speicher rumfummeln kann. Das mag für Profis eine gute Sache sein, Java verbietet das aber aus einem sehr guten Grund: die meisten Programmierer sind leider das Gegenteil von Profis.

    Wenn ich als Projektleiter abwägen muss ob das fertige Programm 20% der Ressourcen auslastet aber ich noch mehrere Monate Bugfixing einplanen muss, oder ob das Programm 40% der Ressourcen auslastet und ich nur 1 Monat Bugfixing einplanen muss, dann nehme ich sehr gerne letzteres.

  16. Re: Die Gründe für Java

    Autor: Serenity 27.05.20 - 13:24

    twothe schrieb:
    --------------------------------------------------------------------------------
    > Ich habe mal einen Programmierwettbewerb wo es nur um Performance ging
    > gewonnen, weil mein Java-Programm die Aufgabe rund 100x schneller gelöst
    > hat als das beste C-Programm. ;)
    > Der Grund dafür war, dass ich einen sehr komplexen Algorithmus problemlos
    > einsetzen konnte, da mir Java mit der Standard-Lib alles an die Hand
    > gegeben hat was ich brauchte. 3 Zeilen und die Sache war fertig. Das selbe
    > in C nach zu programmieren hätte Monate gedauert.

    Das ist so eine pauschale und sinnlose Aussage, die einfach kein Hand und Fuß hat. In deinem Satz kannst du Java und C austauschen und es passt immer.
    Außerdem glaube ich das nicht.

    Belege dafür, dass Java DEUTLICH langsamer als C ist, findest du hier: https://ieeexplore.ieee.org/document/736311

  17. Re: Die Gründe für Java

    Autor: twothe 27.05.20 - 13:59

    Serenity schrieb:
    --------------------------------------------------------------------------------
    > Belege dafür, dass Java DEUTLICH langsamer als C ist, findest du hier: ieeexplore.ieee.org

    "Oct. 1998"
    Du meinst also ernsthaft, dass eine Analyse von 1998 22 Jahre später noch gültig ist, weil sich in der Zwischenzeit bestimmt gar nichts geändert hat?

  18. Re: Die Gründe für Java

    Autor: Serenity 27.05.20 - 14:49

    twothe schrieb:
    --------------------------------------------------------------------------------
    > Serenity schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Belege dafür, dass Java DEUTLICH langsamer als C ist, findest du hier:
    > ieeexplore.ieee.org
    >
    > "Oct. 1998"
    > Du meinst also ernsthaft, dass eine Analyse von 1998 22 Jahre später noch
    > gültig ist, weil sich in der Zwischenzeit bestimmt gar nichts geändert hat?

    Immer noch eine besserer Beleg als irgendein "Programmierwettberwerb". Das es keine weiteren (neueren) Publikationen gibt, könnte daran liegen, dass sich kaum bis gar nichts an der annahme geändert hat.
    Hast du die eigentlich gelesen? Lies es mal, dann ändert sich auch deine Meinung. Die Argumentation da drin ist immer noch valid für die heutige Zeit.
    Bei C/C++ hat sich auch einiges geändert, spielt aber keine Rolle.

  19. Re: Die Gründe für Java

    Autor: lestard 27.05.20 - 16:22

    twothe schrieb:
    --------------------------------------------------------------------------------
    > lestard schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Sonst gäbe es ja nicht diese riesige Anzahl an Frameworks und
    > Dritt-Bibliotheken. Die gibt es doch nur, weil es eben sehr wohl große
    > Lücken im SDK gibt.
    >
    > Dazu fällt mir ein gutes Beispiel von einer Firma ein, die ein teures
    > Cache-Framework eingekauft hatte um Daten zu cachen. Ich hatte als ich dazu
    > kam dann die Frage wofür das eigentlich gebraucht wird. Es kam die üblichen
    > Erklärungen, dass die Java-Libs so was ja nicht hergeben und man brauch das
    > ja. Ich hab dann sämtliche genutzte Funktionalitäten dieser 5mb Caching
    > Library in 20 Zeilen Java Code nur mit Standard-Lib nachprogrammiert. Und
    > das war - völlig überraschend - auch erheblich schneller und hat viele
    > Performance-Probleme gelöst. Da ist bei einigen Kollegen erst mal die
    > Kinnlade runter geklappt.
    >
    > In einem Projekt für die Bundeswehr war die Vorgabe nur die Standard-Lib zu
    > nutzen, es sei denn es geht absolut nicht anders. Datenbankzugriffe nur mit
    > Standard-Lib... "Das kann ja was werden" hab ich am Anfang gedacht. Als ich
    > fertig war, und gelernt habe wie unglaublich einfach das ist, hab ich mich
    > gefragt warum ich eigentlich jemals Hibernate eingesetzt habe.
    >
    > Der Grund warum viele Leute Libs in ihre Projekte kippen ist im Regelfall
    > weil sie keine Ahnung haben, dass die Standard-Lib das auch alles kann.

    Ich halte das nicht für verallgemeinerbar. Mag schon sein, dass mit der Standard-Lib vieles geht aber zum Einen musst du es dann auch genauso machen, wie die Standard-Lib es vorsieht - unabhängig davon, ob es für den eigenen Fall vielleicht bessere Patterns und Vorgehensweisen gäbe. Und du musst zum Anderen auch auf die ein oder andere Vereinfachung verzichten, die Frameworks oder Libraries manchmal bieten. Die Aufgaben sind eben schlicht verschieden: Die Standard-Lib soll eine solide Basis bereitstellen. Frameworks und Dritt-Bibliotheken bauen darauf auf und stellen gezielt Abstraktionen für bestimmte Use-Cases bereit. Dabei können auch bestimmte kontroverse Design-Entscheidungen getroffen werden. Wer diese Entscheidungen nicht mag, nimmt dann halt ein alternatives Framework (oder baut es halt selbst). Aber wer die Design-Entscheidung teilt, der kann mit weniger Code seine eigenen Sachen umsetzen weil vieles wiederverwendet werden kann.
    Das ist meiner Ansicht nach einfach ein Ziel-Konflikt: Die Standard-Lib soll möglichst Low-Level sein um darauf aufsetzenden Frameworks nicht im Weg zu stehen. Die darf gerne auch zusätzlich eigene Abstraktionen als Vorschlag mitbringen aber es muss für Entwickler auch möglich sein, sich dagegen zu entscheiden weil es beim Programmieren ja nie nur den einen richtigen Weg gibt.

  20. Re: Die Gründe für Java

    Autor: mnementh 27.05.20 - 18:42

    lestard schrieb:
    --------------------------------------------------------------------------------
    > Das Argument finde ich nicht sehr überzeugend. Die Doku für das, was in der
    > Standard-Lib drin ist, mag ja gut sein aber, dass die Standard-Lib alles
    > umfasst, "was man so braucht" stimmt doch nicht. Sonst gäbe es ja nicht
    > diese riesige Anzahl an Frameworks und Dritt-Bibliotheken. Die gibt es doch
    > nur, weil es eben sehr wohl große Lücken im SDK gibt.
    > Und wenn du da jetzt eine Klasse als Beispiel rausziehst, sagt das doch
    > nichts über den Rest aus.
    Hmm, zu ihrer Zeit war die Java-Standardbibliothek exzeptionell. Und sie wurde mit den Releases immer wieder erweitert. Es gab regelmäßig Bedarf der noch nicht in die stdlib eingeflossen war, oder man ist gezwungen ältere Versionen zu benutzen (weil man beispielsweise auf einem Debian-Server sitzt und auf das eingebaute Java setzt), diese Lücken haben andere Bibliotheken geschlossen. Aber im Vergleich mit anderen Sprachen wüsste ich nicht, wo eine so große stdlib dabei ist. C oder C++ mal definitiv nicht. R und Perl haben extra Systeme um die ganzen Drittbibliotheken zu verwalten. Vielleicht haben Python und Ruby vergleichbare Standardbibliotheken, das weiß ich nicht. Aber im Sprachenvergleich sieht die stdlib von Java nicht schlecht aus. Nicht perfekt, aber auch nicht schlecht.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Hays AG, Niedersachsen
  2. über duerenhoff GmbH, Raum Düsseldorf
  3. Westernacher Solutions GmbH, Berlin, Heidelberg
  4. Forschungszentrum Jülich GmbH, Jülich

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de