# Script mit Java ausführen



## Nico05 (2. Sep 2018)

Hi,
Ich habe vor ein Multiplayer-Spiel mit einem Server zu programmieren. Damit der Server gestartet wird, muss eine JavaScript-Datei ausgeführt werden. Ich habe mir gedacht es wäre ganz interessant wenn der Spieler, der einen "privaten Raum" in seinem Spiel eröffnet, den Server auf seinem Gerät startet, was wiederum erfordert, dass das Spiel (in Java geschrieben) die vorher bereits genannte JavaScript-Datei ausführt. Jetzt stellt sich mir die Frage, ob das mit Java überhaupt möglich ist. Ich bedanke mich im Voraus bereits für Antworten.


----------



## Thallius (2. Sep 2018)

Dazu muss der Spieler dann ja auch einen kompletten Webserver installiert haben...


----------



## Nico05 (2. Sep 2018)

Der Spieler installiert ja den Webserver über das Script. Es geht mir nur darum, wie man Script Dateien in Java ausführt. Ich habe bereits recherchiert, und es soll angeblich mit einem "Runtime" Objekt funktionieren aber wie genau funktioniert das?


----------



## mrBrown (2. Sep 2018)

Thallius hat gesagt.:


> Dazu muss der Spieler dann ja auch einen kompletten Webserver installiert haben...


Niemand muss heutzutage noch nen Webserver installieren, das gibts als Embedded-Variante in jeder Sprache in zig Varianten...




Nico05 hat gesagt.:


> Ich habe vor ein Multiplayer-Spiel mit einem Server zu programmieren. Damit der Server gestartet wird, muss eine JavaScript-Datei ausgeführt werden. Ich habe mir gedacht es wäre ganz interessant wenn der Spieler, der einen "privaten Raum" in seinem Spiel eröffnet, den Server auf seinem Gerät startet, was wiederum erfordert, dass das Spiel (in Java geschrieben) die vorher bereits genannte JavaScript-Datei ausführt. Jetzt stellt sich mir die Frage, ob das mit Java überhaupt möglich ist. Ich bedanke mich im Voraus bereits für Antworten.


Also, du hast eine in Java geschriebene Client-Anwendung und einen dazu gehörenden in Javascript geschriebenen Server?
Und zum Spielen muss der Javascript-Server gestartet werden und dann kann sich der Java-Client damit verbinden?


----------



## CodeCrack (5. Sep 2018)

Ich bin nicht sicher, ob das so, wie es mrBrown beschrieben hat, funktioniert. Ich glaube nicht. Meines Erachtens brauchst du einen Applikationsserver, wie z.B. GlassFish, WildFly oder Apache Geronimo.


----------



## dzim (5. Sep 2018)

Bahnhof...


----------



## CodeCrack (5. Sep 2018)

Sorry, die Antwort war vielleicht etwas kurz/wenig ausführlich.

Clients kommunizieren normalerweise mit eine zentralen Instanz, dem Server. Dafür gibt es Software. So weit ich weiß, gibt es keine Software auf JavaScript-basis, die mit einem Client kommunizieren kann. Dafür ist JS einfach nicht gemacht. Die genannten Server (tatsächlich wird nicht nur die Hardware selbst als Server bezeichnet, sondern auch die Programme, die Serverdienstleistungen bereitstellen) sind nach einer notwendigen Konfiguration und dem Deploymente der Clientsoftware in der Lage, Anfragen der Clients zu verarbeiten. Korrigiert mich, wenn ich mich irre.

Aber wie wäre es mit einer konkreten Frage, statt "Bahnhof", was genauso nichtssagend ist.


----------



## mrBrown (5. Sep 2018)

CodeCrack hat gesagt.:


> So weit ich weiß, gibt es keine Software auf JavaScript-basis, die mit einem Client kommunizieren kann. Dafür ist JS einfach nicht gemacht.


Doch, gibt es.



CodeCrack hat gesagt.:


> Die genannten Server sind nach einer notwendigen Konfiguration und dem Deploymente der Clientsoftware in der Lage, Anfragen der Clients zu verarbeiten. Korrigiert mich, wenn ich mich irre.


Nicht gänzlich falsch, die großen App-Server braucht man aber immer weniger. 
So gut wie immer reichen Embedded-Server.


Ob der TO allerdings wirklich einen JavaScript-Server meint oder das nur schlecht beschrieben/falsch verstanden hat, kann ich nicht beurteilen. Deshalb hab ich ihn gefragt.


----------



## dzim (6. Sep 2018)

Microframeworks for the win! https://www.e4developer.com/2018/06/02/the-rise-of-java-microframeworks/

Aber davon mal abgesehen bezog sich mein "Bahnhof" auf die Fragestellung, nicht auf den Versuch einer Antwort.


----------



## RalleYTN (10. Sep 2018)

Wird das JavaScript normalerweise im Browser ausgeführt oder geht es hier um einfaches Sandbox JavaScript?
Für zweiteres solltest du dir Nashorn und Rhino ansehen.


----------



## dzim (10. Sep 2018)

Nashorn und Rhino sind tot. Wenn du auf JDK 11+ setzt, müsstest du dir dazu erst die Migration zu GraalVM antun. Das könnte etwas zu heftig für den Einstieg werden.
Wäre Oracle aber gerade nicht auf diesem Ego-Trip, was das Java-Umfeld angeht, würde ich dir - @RalleYTN - aber zustimmen.


----------



## mihe7 (10. Sep 2018)

Es ist ja nichts gegen Entschlackung einzuwenden, aber dieses hin und her von Oracle nervt allmählich... in einem Jahr Erweiterung, im nächsten Deprecation.


----------



## Flown (10. Sep 2018)

mihe7 hat gesagt.:


> in einem Jahr


Made my day


----------



## dzim (10. Sep 2018)

Kurze Java-Versions-Geschichte: Rhino ist seit Java 6 (!) Teil von Java SE. *Also seit 2006*. Es wurde von Nashorn abgelöst (ich finde den JEP gerade nicht dazu, sorry) und wahrscheinlich mit den EA- (Early Access) Versionen von Java 8 vorgestellt (getestet z.B. von Heise Developer am *8.8.2013*; *2014* war es dann GA, also verfügbar für alle).
Also ist nicht mal eben erst reingekommen.

Der JEP zum Entfernen von Nashorn gibt klar zu, dass sie nie so recht mit den anderen Engines konkurrieren konnten. Also z.B. V8 im Node.js, etc. Mit der GraalVM soll sich das ändern (polyglotte und domänenspezifische Programmierung soll möglich werden).

Es gibt aber noch eine alternative, jedoch habe keine Ahnung wie gut sie ist: J2V8


> J2V8 is a set of Java bindings for V8. J2V8 focuses on performance and tight integration with V8. It also takes a 'primitive first' approach, meaning that if a value can be accessed as a primitive, then it should be. This forces a more static type system between the JS and Java code, but it also improves the performance since intermediate Objects are not created.
> 
> We developed J2V8 as a high performance engine for our multi-platform mobile toolkit tabris.js and it is a great choice for executing JavaScript on Android devices.


Etwas Hilfe dazu hier: https://eclipsesource.com/?s=j2v8

Also damit könnte man schon "mal eben schnell" etwas einbinden, um JavaScript von Java aus auszuführen. Aber man erkauft es sich halt mit einem grösseren Executable am Ende, weil J2V8 am Ende ja nichts weiter ist, als der native Blob plus einer JNI-API drum herum um damit zu sprechen.


----------



## mihe7 (10. Sep 2018)

@dzim 2017 wurde Java 9 mit der Erweiterung von Nashorn um ES6-Support veröffentlicht. 2018 deprecated. Das ist für mich ein Jahr.


----------



## dzim (10. Sep 2018)

@mihe7 Ah, so meinst du das, schreib das doch gleich! 
Du darfst nicht vergessen, dass das vermutlich von einem anderen Team gemacht wurde, das mit der Entscheidung "freigestellt" wurde. Oracle hat - unabhängig der Fortschritte verschiedener Teams - einige Bereiche trotz gewissen Erfolgs beendet. Dazu gehört neben Nashorn auch eines der GUI-Tools zum betrachten der aktiven Prozesse, Netbeans, Java EE, JavaFX (mehr oder weniger)... Oracle schaut gerade, wie sie die meiste Kohle aus Java quetschen können, alles, was eher anderen als ihnen selbst nutzt, wird geaxt. Leider.
Oracle hat nach seiner Übernahme von Sun in Bezug auf Java so ziemlich das Bild bestätigt, was ich von ihnen zu der Zeit hatte.


----------



## Flown (10. Sep 2018)

Ich bin jetzt zwar auch kein großer Fan von manch Firmenpolitik Oracle's, aber geaxt wurde hier mal zum Auslichten des Waldes.
Oracle hat sozusagen den Vorsitz des JCP geerbt und es wird ihnen immer vorgeworfen, dass alles zu langsam gemacht wurde. Warum? Weil die anderen Großfirmen wie RedHat oder Intel mit dem einen oder anderen nicht einverstanden waren. Das hat Jigsaw's Entwicklung erheblich von 3 auf knappe 6 Jahre erhöht. Dann die Idee: Schnellere Releasezyklen! Jetzt drehen alle durch weil man so "schnell" migrieren müsste. Passt also auch nicht.

Jahrelanges: Ihr müsst OpenSource werden. Gesagt getan. JakartaEE wurde geboren. Vorwurf: Oracle verlässt das sinkende Schiff im EE Bereich.
Andere Sachen: Java müsste modularer/schlanker werden. Ergo: Alte und seltene APIs - die gut von Alternativen abgedeckt sind - werden rausgenommen. Community: So ein geiles Feature einfach weg (siehe Nashorn -> ich hab das in meinen 15 Jahren SE/EE Entwicklung (Medizin, Automotive, Logistik, etc.) nur aus Jucks und Tollerei gebraucht, aber nicht ernsthaft).

Aber Nashorn könnte gerettet werden, wenn sich dafür Entwickler finden die das aktiv Maintainen, denn EcmaScript ist verdammt schnell in der Entwicklung und die ganzen Bindings dazu ... eine Mammutaufgabe (http://openjdk.java.net/jeps/335 - unter Alternativen). Also nicht meckern, einfach übernehmen.

Jetzt mal zu Java Desktop: 
- Swing/AWT nur aus Altlasten - weil eben soviel Anwendungen noch existieren - in der JDK. 
- JavaFx ausgegliedert, damit es eigene Releasezyklen haben kann - jeder kann es als Dependency hinzufügen, die Technologie ist nicht tot! Aber wer baut noch DesktopClients wenn es fancy WebApps gibt.

Also wurde größtenteils die Community bedient und jetzt regt sich jeder auf, dass das so nicht passt. Also was nun?

TL;DR: solange noch Brian Goetz und Stuart Marks hier mitmischen sieht die Zukunft rosig aus und wenn jetzt Graal auch noch zum Einsatz kommt, dann ist das mit den Interpretierten Sprachzusätzen, DSLs, etc. auch ein piece-of-cake.


----------



## mihe7 (12. Sep 2018)

Flown hat gesagt.:


> Jetzt drehen alle durch weil man so "schnell" migrieren müsste. Passt also auch nicht.


Das Problem dabei ist nicht, dass die Versionen so schnell kommen, sondern dass praktisch mit jeder Version nachgearbeitet werden muss. Das gab es in der Form bislang nicht. 

Ich finde es prinzipiell gut, wenn alter Ballast weg kommt. Dann muss es Alternativen geben und die müssen auch kommuniziert werden. Nehmen wir mal APIs: Methoden, die über Jahre deprecated waren entfernen -> super Sache; nicht offizielle Dinge wie sun.misc.Base64Encoder ins offizielle API übernehmen -> super Sache. Das sind Kleinigkeiten, die man schrittweise angehen kann.

Nicht gut finde ich, wenn praktisch gleichzeitig an jeder Ecke rumgeändert wird, Projekte herumgeschoben werden, die Informationspolitik nicht gut ist, und man sich jeden Mist zusammensuchen muss, weil alte Seiten nicht mehr erreichbar sind oder man nicht auf den ersten Blick erkennt, dass sich etwas tut.

Dabei geht es nicht nur um den Code selbst, sondern auch um die Tools wie maven etc. NetBeans 9 ist im Juli erschienen, ich habe es mir noch nicht richtig angesehen, aber beim kurzen Überflieger fehlen die Plugins für die EE-Entwicklung. Das maven JAX-WS-Plugin geht auch noch nicht. Und so geht es jetzt sein einem Jahr: irgendwas fehlt immer :-(


----------



## Flown (12. Sep 2018)

mihe7 hat gesagt.:


> Das Problem dabei ist nicht, dass die Versionen so schnell kommen, sondern dass praktisch mit jeder Version nachgearbeitet werden muss. Das gab es in der Form bislang nicht.


Klar weil nie etwas weggekommen ist. In Java 8 ist viel deprecated worden und es ist oft genug gesagt worden: "Hey Leute es wird jetzt einiges Umgebaut und Weggeworfen" und jetzt nach 4 Jahren wundern warum man das jetzt machen muss? Das passiert auch Schrittweise und die Corefeatures - die von 98% aller Entwickler genutzt werden - blieben ohnehin unberührt.


mihe7 hat gesagt.:


> Dabei geht es nicht nur um den Code selbst, sondern auch um die Tools wie maven etc. NetBeans 9 ist im Juli erschienen, ich habe es mir noch nicht richtig angesehen, aber beim kurzen Überflieger fehlen die Plugins für die EE-Entwicklung. Das maven JAX-WS-Plugin geht auch noch nicht. Und so geht es jetzt sein einem Jahr: irgendwas fehlt immer :-(


Also das ist wirklich das Problem der Toolinghersteller. Die Specs/Previews gibt es schon lange bevor Rampdown, dass sollte keine Ausrede sein. 

Aber das schöne ist ja, man muss nicht migrieren, man kann einfach auf Java 8 bleiben und fertig. Wieso etwas erzwingen? Erstmal etwas reifen lassen und dann mit den dazugehörigen Tooling arbeiten.


----------



## dzim (12. Sep 2018)

Ich finde es ja gut, dass man schneller released, aber mich stört hauptsächlich der grundlegend umgestaltete Lizenz-Kram. Es sitzen zwar Alternativen in den Startlöchern, aber noch ist nicht zu hundert Prozent klar, wie das laufen wird.
Auf Java 8 bleiben ist mittelfristig eher dumm, da es ja auch nur noch bis 2019 supportet wird (also der kostenlose Support, so weit ich weiss). Aber eigentlich hab ich daran ja nicht gekrittelt.

JavaEE ist mir relativ "egal", da ich eh ein Spring-Nutzer bin. Ich finde es nicht per se schlimm, wenn sie etwas outsourcen. 
JavaFX werde ich weiterhin verwenden - ich entwickle sogar von Arbeitswegen damit, auch für Mobile...

*Aber wir weichen jetzt so was von vom eigentlichen Thema ab, der TO wollte wissen, wie man JavaScript von Java aus evaluieren kann. Ich denke, die Fragen wurden doch eigentlich beantwortet, oder?*


----------



## mrBrown (12. Sep 2018)

dzim hat gesagt.:


> Ich finde es ja gut, dass man schneller released, aber mich stört hauptsächlich der grundlegend umgestaltete Lizenz-Kram. Es sitzen zwar Alternativen in den Startlöchern, aber noch ist nicht zu hundert Prozent klar, wie das laufen wird.


Da ändert sich doch kaum was: 
braucht man viel Support -> Oracle, Azul oder wen auch immer dafür bezahlen
braucht man keinen Support -> OpenJDK aus einer der beliebigen Quellen



dzim hat gesagt.:


> *Aber wir weichen jetzt so was von vom eigentlichen Thema ab, der TO wollte wissen, wie man JavaScript von Java aus evaluieren kann. Ich denke, die Fragen wurden doch eigentlich beantwortet, oder?*


ich frag mich immer noch, was er eigentlich meinte


----------



## dzim (12. Sep 2018)

@mrBrown hast recht. Hab mir die Frage noch mal durchgelesen - und bin mir nun auch nicht mehr sicher, was er möchte. Wenn es aber um die Frage geht "Wie kann ich JavaScript in Java einbetten?", dann sollten wir genügend geliefert haben.


----------

