Aversion gegen Java
-
DocShoe schrieb:
Als C++ Programmierer kann ich die Sicherheitslöcher selber stopfen, wenn welche gefunden werden. Auch kann ich entscheiden, wie dringend ein Loch gestopft werden muss. Wenn bei Java die VM Sicherheitslöcher hat kann ich das nicht mehr und bin auf ein Update angewiesen, das dieses Loch stopft. Und je nach Anforderung muss ich mit einer neuen VM vielleicht größere Funktionstests machen, um das Verhalten bestehenden Codes unter der neuen VM zu prüfen.
Nach meinem Verstaendnis sind die Sicherheitsluecken in Java nicht in der Art, dass eigene Programme unsicher werden, weil sie in einer VM laufen, sondern, dass fremde Programme, die innerhalb der VM in einer Sandbox laufen sollen, aus dieser ausbrechen koennen.
Fuer eigene Programme erhoeht Java eher die Sicherheit, weil Arraygrenzen usw. eben immer getestet werden.
-
DocShoe schrieb:
Als C++ Programmierer kann ich die Sicherheitslöcher selber stopfen, wenn welche gefunden werden. Auch kann ich entscheiden, wie dringend ein Loch gestopft werden muss. Wenn bei Java die VM Sicherheitslöcher hat kann ich das nicht mehr und bin auf ein Update angewiesen, das dieses Loch stopft.
Die fiesesten Sicherheitslöcher sind im Betriebssystem.
Aber du hast natürlich Recht, als C-Progger baust du mal eben schnell irgendwelche System-DLLs nach.
-
Andromeda schrieb:
Aber du hast natürlich Recht, als C-Progger baust du mal eben schnell irgendwelche System-DLLs nach.
Nö, ich baue meistens Sachen, die das System nicht bietet, weil die Programmierer des Systems dicht sind, während ein anderes System diese Sachen meistens hat.
"Das System" ist hierbei meistens Windows, und "ein anderes System" Linux und/oder BSD.
-
JGuest schrieb:
Wie wäre es mit
? ..
Bricht auch nicht bei 2^88 ab
Danke!
(bricht bei mir erst bei 2^98 ab. Na, immerhin)*
(wäre online-Interpretertechnisch gesehen eigentlich ein Punkt für Java)*edit: nach Wiederholung/Zahlenumstellung kein Abbruch (mehr))
-
dachschaden schrieb:
Nö, ich baue meistens Sachen, die das System nicht bietet, weil die Programmierer des Systems dicht sind, während ein anderes System diese Sachen meistens hat.
Was denn zum Beispiel?
-
ich würde einmal sagen, dass jemand, der C++ gut beherrscht, sehr leicht auf java umsteigen kann, aber jemand, der java gut beherrscht, sich mit einem umstieg auf C++ sehr schwer tun würde.
das impliziert, dass ich eher jemanden einstellen würde, der guten C++ code kann, wenn er vorher java gelernt hat, weil (qed) sehr viel mehr leisten musste.
-
dove schrieb:
ich würde einmal sagen, dass jemand, der C++ gut beherrscht, sehr leicht auf java umsteigen kann, aber jemand, der java gut beherrscht, sich mit einem umstieg auf C++ sehr schwer tun würde.
Also nein, dazu existieren in beiden Sprachen einfach viel zu viele unterschiedliche Konzepte. Mein Betrieb (bin einer der 6 Inhaber) sucht hauptsächlich hardwarenahe Coder. Wir haben mit Java als auch C++ Programmierern gute wie auch schlechte Erfahrungen gemacht. Das nimmt sich nichts.
-
*Rant geloescht*
-
[quote="Andromeda"]
dove schrieb:
ich würde einmal sagen, dass jemand, der C++ gut beherrscht, sehr leicht auf java umsteigen kann, aber jemand, der java gut beherrscht, sich mit einem umstieg auf C++ sehr schwer tun würde.
Der Geist von C++ ist "Fehler bleiben auf dem Schreibtisch!". Man vernudelt die Sprache ein wenig, um mit der statischen Typprüfung im Voraus seine späteren Denkfehler (und Tippfehler eh) rauszukloppen. Dieses Vernudeln hat sich als ebenso komplex herausgestellt wie die Anwendungsprogrammierung selbst. In C++ ist Programmierung und Typen-Vernudeln das selbe. *zack*, ich hab nicht aus Absicht gemacht, daß es geht. Aber die C++-Progger müssen eine Mindestvoraussetzungen erfüllen: Auf Anfrage vom Vorgesetzten zur Arbeitszeit ein Buch lesen können.
Der Geist von Java ist "Unsere Leute können kein Buch lesen".
-
Ich weiß nicht ob ich bei der Überheblichkeit und Einbildung weinen oder lachen soll...
-
Wo ist Java bitte "unsicher"?
Das Java-Plugin für den Browser? Bitte, das verwendet kein Mensch mehr und ist auch vollkommen irrelevant.
Java ist halt die Technologie der Wahl für große Enterprise-Systeme. Applicationserver wie IBM WebSphere, die auf geclusterten Serversystemen oder Mainframes laufen. Große Unternehmen haben davon teilweise tausende am Laufen.
Neben dem offiziellen Sun/Oracle Java gibt es übrigens noch zahlreiche andere Implementierungen, wie beispielsweise JRockIt, IBM, SAP, OpenJDK und weitere.
Woher willst du wissen, dass die alle unsicher sind bzw. Sicherheitsprobleme leisten? Denkst du, man entwickelt millionen- bis milliardenschwere Systeme mit einer "unsicheren" Sprache?
-
Java ist sicher, weil so viele grosse Firmen es verwenden?
Echt jetzt? Das ist dein Argument?EDIT: Typo
-
Richtig erkannt.
Weil die sogenannten "Entscheider" keine Ahnung haben und lieber irgendwelchen Einflüsterungen aus Computerwoche und einschlägig bekannten "Berater"firmen & Co auf den Leim gehen anstatt ihren (meistens doch vorhandenen) eigenen Experten zu vertrauen, übrigens mit dem naiv-dümmlichen Argument aller Ahnungsloser, das auch du hier angeführt hast: "die anderen machen es doch auch so".
Diese "Entscheider" müssen sich nämlich meist auch selbst höheren Ebenen gegenüber rechtfertigen, und da tut sich ein Manager eben sehr schwer, eigenen Leuten zu vertrauen und sehr viel leichter mit Powerpoints irgendwelcher (natürlich nur an ihrem eigenen Stundensatz und keinesfalls an Technik oder Technologie interessierten) "Beratern".
-
Bitte ein einziges Argument, warum Java unsicher sein sollte. Danke.
Gerne auch ein Argument, warum eine andere Sprache besser für den Enterprise Bereich geeignet sein sollte. Das lasse ich höchstens bei .NET durchgehen, was den Windows-Nachteil hat, ist halt nicht gerade ideal für die Linuxkisten.Des weiteren würde mich interessieren, wie man auf die Idee kommt, kompetenter zu sein als diverse Softwarespezialisten in großen IT-Firmen wie beispielsweise IBM.
-
- weil in großen Firmen im Gegensatz zu deinem dir bekannten privaten Umfeld VPN massenweise eingesetzt wird, und zwar nahezu ausschließlich mit deinem Java-Gedöns und zwar für Mitarbeiter und Kunden
- "too big to fail" ist Computerwoche/Berater-Dummschwätz, was sich spätestens nach 2008 auch in nicht Finanzmarkt-affinen Kreisen rumgesprochen haben sollte und dient ausschließlich der möglichst langfristigen/vieljährigen Generierung von abrechenbaren Stunden bei Großkunden für dort eingesetztes eigenes Personal
- und das lässt sich eben schneller von der Straße/Uni holen, wenn man es auf die Allerweltssprache Java getrimmt hat, als wenn man wirkliche Spezialisten einsetzen würde (deren Ausbildung würde nämlich viel länger+teurer sein)
- die "Entscheider" (also mittl.Management) müssen sich nach oben rechtfertigen und da klingt es (teilweise sogar verständlich) besser im Managerjargon wenn man berichtet:"ich haben eine Gruppe von Spezialisten eines international bekannten Beratungshauses beauftragt (natürlich mit obszönen Stundensätzen vergütet) und die sind zum Ergebnis gekommen, dass..."
statt
"ich habe unseren Technikchef gefragt und der ist der Meinung ..."
"Software von der Stange","automatische Codegenerierung" oder gar "automatische Softwaremigration" ist Computerwoche/Berater-Dummschwätz, vorzugsweise mit Java als Basis, hat nie funktioniert, wird nie funktionieren, ist immer teuer/dauert länger als geplant und dient ausschließlich der Kundenverdummung und Geldgenerierung
- Unternehmenssoftware ist immer firmenspezifisch, abhängig von der Größe/Alter sehr inhomogen, was die ahnungslosen "Entscheider" aber nicht davon abhält, weil sie über die Vorzüge von Cloud,Mobil,Docker,DevOps & Co bei Amazon,Netflix,Spotify & Co gelesen haben, in ihrer eigene Firma sowas zu machen: und da kommen dann die Berater ins Spiel, die alles versprechen nur um den Zuschlag zu erhalten
- das Geschrei geht dann los, wenn deine Allerweltssoftware Java an der Firmen-IT scheitert, sowohl fachlich wie auch technisch und erst recht bei Performanz, weil deine Java-Studenten keine Ahnung von Fachlichkeit und bestehender Firmenhard/software haben (haben können); dann kommen solche überforderten Leute dann auf die Idee, doch noch per JNI auf die Bestandssoft/hardware zuzugreifen, und wer einmal gesehen hat, was dabei rauskommt, wenn ein Berater eines IT-Globalplayers versucht, über JNI C zu programmieren, der dürfte sich eigentlich nie mehr wissentlich in Abhängigkeit von solcher Java-Software begeben
- das "Design" von Java ist grundsätzlich verkorkst, die Anspruch "eine Sprache für alle Themen" ist gescheitert;
> ständig ein neuer Oberflächen"standard"
> boxed Typen
> AppServer Gedöns
> Klassenablage dateiorientiert, grundsätzlich sinnfrei
> jdbc/Hibernate Gedöns, inperformanter Schwachsinn
> OOP-Design ist grundsätzlich Schrott
> ...
Deine Javadesigner hatten doch versprochen, ohne Pointer auszukommen: wie heißt doch nochmal die häufigste Fehlermeldung bei Java? ich glaub, irgendwas mit Nullpointerexception
-
Wie viele Sicherheitslücken sind denn bei Java bekannt, die allein auf die Sprache zurückzuführen sind? Und wie viele Pitfalls kennt man bei C++ die allein der Sprache zuzuschreiben sind?
Das wohl die weite Mehrheit nicht mit C oder C++ umgehen kann, beweisen die ganzen Lücken in diversen Produkten die allein auf die Missstände der Sprache zurückzuführen sind.
Meine Güte wir sind im Jahre 2016 angekommen, da muss man doch nicht für jeden Scheiß gleich C++ nehmen. Für ein C++-Projekt Leute zu finden die sicher in der Sprache sind ist wohl um einiges schwieriger als ein Java-Entwickler aufzutreiben.
Gibt es überhaupt ein sicheres C++ Projekt, in Bezug auf Fehler die durch die Benutzung der Sprache gemacht wurden?
Mal ehrlich, wer heute ein größeres Projekt plant der wird doch C++ nur nehmen wenn es gar nicht anderes geht.
-
Danke Wutz, kein einziges Argument - qed, Java ist geil.
Und weil AppServer so scheiße sind: Was ist besser?
-
Depp, du kannst nicht lesen, nichts verstehen und hast keine Ahnung.
Ja, bleib bei deinesgleichen Javadeppen.
-
Ach, was heißt da Javadeppen. Ich entwickle beides, schätze beides im jeweils angemessenen Bereich. Der ist halt häufiger Java als C++, kann man nichts machen.
Und du hast nichts bezüglich der Sicherheit von Java argumentiert, nur Metametaargumente.
-
Ethon_ schrieb:
Bitte ein einziges Argument, warum Java unsicher sein sollte. Danke.
Es gab doch da vor Jahren mal ein Sicherheitsloch bei Applets, das IMHO einige Browserhersteller dazu veranlasst hat, Java gar nicht mehr zu unterstützen.
