Java vs. anderen plattformunabhängige Programmiersprachen

[unknown]

Hallo zusammen

Was hat Java (bzw. J2EE) sowohl technisch als auch businessmäßig gegenüber andernen plattformunabhängige Programmiersprachen (wie beispielsweise Node.JS) für den Backend Bereich für Vorteile?

Ich benötige viele aussagekräftige Argumente und bin deshalb über jede Antwort froh.

Besten Dank im Voraus.

 

[kneitzel]

Also hinter Node.js steckt JavaScript - die Sprache selbst hat einige Unterschiede, so dass ich hier Java bevorzugen würde. (Gibt es bei JavaScript einen Compiler, der alles genau prüft?)

Dann würde ich die Umgebung vergleichen - da hat man ein recht neues Node.js mit relativ eingeschränkten Möglichkeiten und auf der anderen Seite Java mit sehr weitgehenden Möglichkeiten. Application Server wie JBoss, Websphere, ... fallen mir da ein, Frameworks wie Spring, ....

Dann sollte es deutlich mehr Installationen auf Java Seite geben.

Also irgendwie ist das nicht wirklich vergleichbar würde ich sagen.

 

[Joose]

Ja teilweise wird JavaScript auch vorkompiliert (vor allem bei Node.js wenn ich das richtig in Erinnerung habe).

Es kommt auch darauf an. Was soll realisiert werden? Mit welcher Belastung wird gerechnet? Gibt es schon vorhandene Infrastruktur, wenn ja welche? Kosten (Lizenz, neue Entwickler welche mit entsprechenden Sprachen/Systemen umgehen können, Umschulungen für aktuelles Personal)
Solche Fragen so ohne genauere Informationen zu beantworten ist schwer. Alles hat seine Vor- und Nachteile und anhand der gegebenen Umstände kann man das eine oder andere ausschließen oder beiseite geben.

 

[nvidia]

Node.js ist eine eigenständige Plattform und keine Programmiersprache. Node.js verwendet JavaScript, weil man sich dann in einer sprachlichen Ebene für die Client/Serverwebentwicklung bewegt und nicht umdenken muss. Node.js bedient eine Nische und zwar die der "Datenraten" intensiven "Echtzeitanwendungen", d.h. wo schnell viel IO passieren muss[1]. Für CPU-intensive Geschichten taugt Node jedoch nicht wirklich etwas.

Als größten Nachteil empfinde ich aber die Verwendung von JavaScript. JavaScript ist nie für die Anwendung in solchen Maßstäben gedacht gewesen, es ist teilweise inkonsistent, nich typsicher, hat einen geringen Abstraktionsgrad dadurch schlechte Unterstützung von OO u./o. funktionalen Mustern, durch die Eigenschaft eine dynamische Sprache zu sein werden größere Refactorings erschwert uvm.

Das führt dann zu einem Haufen Wartungsaufwand aber für die Lebensdauer heutiger Webanwendungen die gefühlt zwischen 1-3 Jahren liegt ist das wohl auch nich so relevant. Um einige Probleme von JS in den Griff zu bekommen werden z.B. Sprachen die dann nach JS kompiliert werden entwickelt, bspw. PureScript, Elm sowie passende "Adapter" um von denen aus Node.js ansprechen zu können.

Node.js hat seine Nische, JavaScript sollte eigentlich in seiner Nische bleiben, es kommt im Endeffekt darauf an was das Ziel der Anwendung sein soll.

[1] Das ist bedingt durch die Architektur, es spricht jedoch nichts dagegen eine ähnliche Architektur in Java zu nachzubauen.

 

[unknown]

Node.js bedient eine Nische und zwar die der "Datenraten" intensiven "Echtzeitanwendungen", d.h. wo schnell viel IO passieren muss[1]. Für CPU-intensive Geschichten taugt Node jedoch nicht wirklich etwas.

Danke für die Antworten.

Kannst du etwas näher erklären, wieso Nod.js diese Nische gut bedienen kann und für die CPU-intensive Angelegenheiten nicht geeignet ist? Gibt es da genau wie bei native Javascript nur einen Thread?

 

[Tobse]

Ich glaube wir hatten das Thema hier schon mal. Die Forensuche könnet also ggf. auch noch ein paar Pro/Kontra Argumente bringen.

Ich persönlich denke, dass man Java und JavaScript+Node.js nicht vergleichen kann. Java war schon immer für umfangreiche, große Business-Projekte mit vielen Anforderungen gedacht. Node hingegen gelänzt darin, dass man damit einfache und kleine Projekte schneller umsetzen kann. Für alles, was dem Umfang eines Blogs (ggf. plus Chat o.ä.) übersteigt würde ich Node.js nie benutzen (wegen besagter JavaScript schwächen).

Die Frage war ja aber breiter gefasst (plattformunabhängig) und daher will ich noch ein paar andere Sprachen / Technologien beleuchten:

Für den Backend-Bereich (APIs, Datenverarbeitung ohne UI, etc.) würde ich, ginge es jetzt um ein neues Projekt, noch folgende Sprachen in Erwägung ziehen:

- D: native Sprache mit plattformunabhängiger, z.T. OO Library; kann fast so mächtig sein wie C, bietet aber noch mehr Sicherheiten und Features als Java (als die Sprache Java, nicht die Library. Die Java-Libraries sind deutlich umfangreicher als die von D). Link zur Webseite.
- HHVM/PHP7: IWenn man sich die neueren Entwicklungen ansieht (Dependency Management, Unit-Testing, ...) und was mit PHP7 demnächst dazu kommt (typisierung, JIT), kann es sich durchaus mit Java messen. Für Projekte mittlerer Größe wahrscheinlich die bessere Wahl.

Wie die anderen schon sagten, hängen die Vor- und Nachteile einzelner Technologien stark von den Anforderungen ab; deshalb kann man da keine Pauschal-Aussage machen. Aus meiner Sicht sprechen folgende Dinge im Backend für Java (aber nicht gegen andere Sprachen, weil die das zum Großteil auch können):

- Mächtige Libraries, neben den EE Libraries z.B. Apache Commons
- Mächtige Application-Server für die EE-Edition
- Strikte Typisierung
- Laufzeitgeschwindigkeit (mit JIT, etc)
- Plattformunabhängigkeit

P.S.: Die Auswahl für eine neues Projekt ist natürlich noch größer. Allerdings sieht es mit der Plattformunabhängigkeit bei den anderen Kandidaten (z.B. Ruby, C#) eher düster aus.

 

[kneitzel]

Nunja - c# deckt eigentlich alle großen Plattformen ab. Microsoft macht hier ja in Sache Open Source einiges! C# und viele Technologien wie z.B. ASP.Net sind da kein Thema mehr. Mono macht hier vieles möglich. Wenn man dann die Mobil-Geräte betrachten möchte, dann punktet c# mit Xamarin.

Die Möglichkeiten sind also mit c# prinzipiell auch gegeben. Aber ich würde, so es plattformunabhängig sein sollte, auch nicht zu c# greifen. Auch wenn es prinzipiell geht sehe ich da doch diverse Probleme. Gerade im Business-Bereich wäre z.B. WCF zu nennen und das ist bei Mono nur teilweise implementiert. Und ich sehe immer das Problem mit der Dokumentation - msdn ist genial aber deckt halt den Windows Bereich ab.

Konrad

 

[thecain]

Wir reden vom Backendbereich?

Ich verstehe nicht ganz den Zusammenhang: Backend und Plattformunabhängigkeit?

Für grössere Projekte, ist die Plattform doch vollkommen irrelevant. Wenn ich ASP.NET entwickeln will, stell ich nen Microsoft Server auf, wenn ich Java will halt nen Tomcat o.ä. Wichtig ist doch eher, wo das Know-How vorhanden ist.

Von den Features her unterscheiden sich die Grossen nicht sehr.

 

[nvidia]

Danke für die Antworten.

Kannst du etwas näher erklären, wieso Nod.js diese Nische gut bedienen kann und für die CPU-intensive Angelegenheiten nicht geeignet ist? Gibt es da genau wie bei native Javascript nur einen Thread?

Ja, es ist die Art der Architektur, die hat so gesehen nichts mit "Threading" zu tun. Dieses Modell existiert schon ewig, es gibt DEN Eventloop auf dem etwas zur Verarbeitung "gelegt" wird, seien das Ereignisse, ausführbare Aktionen etc. pp. und dann werden die nacheinander abgearbeitet. So ist auch die Architektur von Node.js in der Java-Welt ist das vergleichbar mit Swing. Hier haben wir den EDT (GUI-Thread) und legst du hier eine lang dauernde Aktion auf den GUI-Thread (EDT) friert das UI ein. Damit das nicht passiert musst du die lang laufende Aktion auslagern. Node tut etwas ähnliches im Bereich des IO, bei Datenzugriffen über Node.js auf eine DB werden diese asynchron angestoßen und es geht mit dem nächsten Ding im Eventqueue weiter. Was passieren soll wenn es fertig ist wird über die Callbacks geregelt. Leider führt das mit den exzessiven Callbacks, in meinen Augen, zu ziemlich wüsten Code, aber das lässt sich wohl mit extra APIs wie Async.js oder der konsequenten Verwendung von Promises abmildern.