Aversion gegen Java

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.

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.

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.

maximAL

*Rant geloescht*

volkard

[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".

Artchi

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?

hustbaer

Java ist sicher, weil so viele grosse Firmen es verwenden?
Echt jetzt? Das ist dein Argument?

EDIT: Typo

Wutz

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.

Wutz

- 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?

Wutz

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.

Andromeda

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.

Andromeda

NurZurNotCpp schrieb:

Mal ehrlich, wer heute ein größeres Projekt plant der wird doch C++ nur nehmen wenn es gar nicht anderes geht.

Der nimmt dann Java und spricht den C-Code über JNI an.

Shade Of Mine

Ethon_ schrieb:

Und du hast nichts bezüglich der Sicherheit von Java argumentiert, nur Metametaargumente.

Was soll man da Argumentieren?

Java ist nach Flash das größte Einfallstor für Angreifer.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=93&product_id=19117
bzw.
https://heimdalsecurity.com/blog/java-biggest-security-hole-your-computer/

So ein Unsinn, das mit der Lücke ist Jahre her. Wenn du wirklich unsicher sein willst, dann stell ein Linux-Server ins Netz am besten noch mit einem SSH-Server. Ach ne, das haben sie ja nach vielen Jahre erst entdeckt. Jaja, Opensource macht Software sicherer *lach

Das Java unsichere ist, ist genau so ein Unsinn wie dass Windows unsicherer ist als Linux.

Schau dir mal hier an wie viele Fehler pro Produkt gelistet sind. Da steht ja Windows echt gut da.
https://www.cvedetails.com/top-50-vendors.php

Bitte ein Bit

Was für eine Diskussion...

Javalove's Spruch "So gut wie jede C++ Software ist doch wie ein Schweizer Käse, bei dem man sich das Loch nur aussuchen muss." hat mich gestört und habe ihm deswegen gegen den Kopf geknallt dass das Java Plugin sich in Sachen Sicherheit auch nicht rühmlich gemacht hat.

Wir leben heute in einer Welt, in der das Internet nie weit von uns entfernt ist. Und in der sich Internetkriminalität noch nie so gelohnt hat. Ich vermute mal dass wir heute in einer Welt mit diversen Internet-Mafia's leben, welche es sich problemlos leisten können, Software-Entwickler einzustellen, welche Tag und Nacht nach Sicherheitslücken suchen. Daher würde ich jede mächtige Online-Sprache als potenziell unsicher bezeichnen. Einfach weil sie im Fokus stehen.

Aber Sicherheit nur an Sprachelementen einer Programmiersprache festmachen, halte ich für einen Fehler. Java wird nicht sicherer dadurch das Buffer-Overflows nicht funktionieren. Zum ersten kann man nachschauen wie gut der Schutz funktioniert und diesen ggf. umgehen (siehe Heap Spraying gegen Data Execution Prevention (DEP) und Adress Space Layout Randomisation (ASLR)). Oder man wirft einen Blick in die java.exe, überprüft ob die Funktionen innerhalb der Exe anfällig ist und weicht ggf. auf die von java.exe genutzten Betriebssystem-Funktionen aus. Ganz krass wird dies am Angler-Exploit Toolkit sichtbar, welche EMET Schutztechniken aushebeln kann.

Kurze Sache am Rande. Jedes neu geschriebene C Programm hat unter Visual Studio automatisch diverse Sicherheitstechniken implementiert, wie Data Execution Prevention, Address Space Layout Randomization, Safe Exception Handling, Überprüfung auf unsichere Funktionen,... Damit wird Sicherheit auch Sache des Programm-Alters, sofern man nicht EMET nutzt.

Sicherheit hat viele Facetten. Und viele Sicherheitslücken öffnen sich einfach dadurch, dass unsachgemäße Benutzung erstens möglich ist und zweitens diese weitreichenden Zugang ermöglichen:
1.) Geben Sie ihren Namen ein: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXX -> Buffer Overflow da Name ein char[16] ist und so den Instruction Pointer überschreibt. Warum darf er dass denn überhaupt?
2.) Geben Sie ihren Namen ein: * -> SQL Injection. Gibt Namen aller Personen aus.
3.) Passwortwiederherstellung bei EMail Account: Geben sie ihre Lieblingsfarbe ein:
-> Findet man einfach bei Facebook. Einfach eine falsche Identität einer 20 jährigen Frau mit dicken Brüsten annehmen, den Freund der Zielperson werden,
so auf seine private Facebook Seite kommen, wo alle sozialen Informationen stehen.
4.) Alex schickt Beate folgende Nachricht: AES("Hallo Beate. Kaufe noch bitte weitere 2000 Aktion der IchBinBaldPleite AG"). Mallory fängt die Nachricht ab,
leitet diese an Beate weiter und schickt ihr zusätzlich diese jeden Tag. Dadurch kauft Beate wesentlich mehr Aktion als gedacht und geht durch die
Pleite Bankrott.

Ich denke Sicherheit ist eine komplexe Sache. Und daher würde ich mit Sicherheit sicherheitstechnische Aspekte schon in Softwareentwicklung einbauen (siehe Microsoft Security Development Lifecycle oder ähnlichem).

PS:
Bei folgenden bin ich mir nicht ganz sicher. Setup Dateien dürften beim Starten diverse DLL's wie beispielsweise User32.dll laden. Wenn man nun eine gefakte User32.dll entwickelt, welche die Funktionen der Windows User32.dll wrappt, und zusätzlich eigenen Code enthält, und diese in den Ordner der Setup Exe Datei legt, dürfte die Setup Datei die gefakte DLL laden s.d. man zum Nulltarif zu Admin Rechten kommen.