Gibt es eigentlich Java Source Code Interpreter..?

Bitte aktiviere JavaScript!
Damit meine ich nicht den internen Interpreter der JVM der Bytecode abarbeitet und wo ab und zu der JIT uebernimmt. Auch meine ich nicht sowas:
https://openjdk.java.net/jeps/330 wo auch Bytecode generiert (in memory) und ausgefuehrt wird.

Nein, ich meine einen Interpreter in Java geschrieben dem man z.B. einen Snippet Java Code als String geben kann und wo dieser diesen dann ausfuehrt. Allerding nicht indem Bytecode erzeugt wird aus dem Snippet, sondern indem einfach die Befehle des Source codes dynamisch abgearbeitet werden.

Java:
        String s = new String("Hello World");
        System.out.println(s);
Der Interpreter wurde das Source-Snippet parsen und z.B. einen AST erzeugen. Danach wuerde er fuer die erste Zeile dynamisch ein String-Objekt erzeugen und danach die println Methode dynamisch aufrufen mit dem Objekt als Argument. Eventuell kann man damit nicht alle Faelle von validem Java Code abdecken, aber simple Faelle auf jeden Fall, oder?

Gibt es so ein Project, dass simple Java Ausdruecke ausfuehrt? Fuer mathematische Ausdruecke gibt es in Java solche Interpreter.
 
Ich glaube jshell fuehrt auch Bytecode aus. Also nein, nicht etwas wie jshell.

Theoretisch sollte es aber keinen Grund geben warum man nicht direkt Source code ausfuehren koennen sollte indem man die Statements und Expressions im Source code einfach "ausfuehrt". Wenn im source code ein String Objekt erzeugt wird, tust du das identisch in deinem Interpreter. Wenn das String Objekt via println im source code ausgegeben wird auf der Konsole kannst du dynamisch in deinem Interpreter println aufrufen und das vorher erzeugte Sting Objekt uebergeben.
 
Einen Java Quelltext-Interpreter in Java zu schreiben, hat keinen Use-Case. Erstens benötigst du sowieso eine JVM, um den Interpreter laufen zu lassen, und wenn du die Laufzeitumgebung sowieso hast/benötigst, kannst du auch gleich das eigentlich zu interpretierende Programm kompilieren und mit der Java-Laufzeitumgebung ausführen.
Es wäre also nichts weiter als eine riesengroße Zeitverschwendung ohne einen Anwendungsfall, einen Java Interpreter in Java zu bauen. Und genau deswegen hat es wohl auch noch niemand gemacht.
 
Nunja, es gibt z.B. BeanShell - da ist das aber noch erweitert worden um Script-Elemente ....
Und die BeanShell fuehrt source code aus? Da wird doch vorher auch auf Bytecode umgewandelt, oder?

Einen Java Quelltext-Interpreter in Java zu schreiben, hat keinen Use-Case. Erstens benötigst du sowieso eine JVM, um den Interpreter laufen zu lassen, und wenn du die Laufzeitumgebung sowieso hast/benötigst, kannst du auch gleich das eigentlich zu interpretierende Programm kompilieren und mit der Java-Laufzeitumgebung ausführen.
Es wäre also nichts weiter als eine riesengroße Zeitverschwendung ohne einen Anwendungsfall, einen Java Interpreter in Java zu bauen. Und genau deswegen hat es wohl auch noch niemand gemacht.
Fuer mich haette es einen Use-Case :)
 
Also BeanShell sagt unter https://beanshell.github.io/intro.html:
"In short, BeanShell is dynamically interpreted Java, plus a scripting language and flexible environment all rolled into one clean package."

In wie weit da aber an welcher Stelle eben ByteCode zum Einsatz kommt oder nicht: Was spielt das für eine Rolle? Wo ist denn der ausschlaggebende Punkt für Dich? Wo hängt es aus Deiner Sicht bei deinem Usecase?

Das kommt mir gerade extrem seltsam vor.
 
Na dann erzähl' mal? :)
In einem Wort: Kontrolle. Die JVM kann ich nicht kontrollieren (oder nur sehr schwierig) - oft wird in solchen Faellen Bytecode-Modification gemacht. Finde ich unschoen weil es eben auch sehr viel "Black Box" ist und man Kontrolle einbuesst.

Einen Source-Code Interpreter koennte man fuer Spezialfaelle (ich will jetzt nicht ins Detail gehen) eben zu 100% kontrollieren und es waere keine "Black Box".
 
Also BeanShell sagt unter https://beanshell.github.io/intro.html:
"In short, BeanShell is dynamically interpreted Java, plus a scripting language and flexible environment all rolled into one clean package."

In wie weit da aber an welcher Stelle eben ByteCode zum Einsatz kommt oder nicht: Was spielt das für eine Rolle? Wo ist denn der ausschlaggebende Punkt für Dich? Wo hängt es aus Deiner Sicht bei deinem Usecase?

Das kommt mir gerade extrem seltsam vor.
Danke. Ich schau es mir mal an. Wie gesagt, wuerde mich wundern wenn das nicht "in-memory" in Bytecode compiliert und das dann ausfuehrt. Ist ja sehr simpel.

Meine Gruende hab ich in meinem letzten Post ein bischen angerissen.
 
In einem Wort: Kontrolle. Die JVM kann ich nicht kontrollieren (oder nur sehr schwierig) - oft wird in solchen Faellen Bytecode-Modification gemacht. Finde ich unschoen weil es eben auch sehr viel "Black Box" ist und man Kontrolle einbuesst.

Einen Source-Code Interpreter koennte man fuer Spezialfaelle (ich will jetzt nicht ins Detail gehen) eben zu 100% kontrollieren und es waere keine "Black Box".
Und worauf läuft dein Interpreter selbst? Richtig: Auf einer JVM. Es sei denn natürlich, du lässt deinen Interpreter sich selbst wieder interpretieren. Dann liefe aber der Interpreter-Interpreter auf einer JVM. Also, irgendwo hast du in der Kette am Ende eine JVM...
Aber warum willst du eigentlich hier (bei Java) aufhören? Dem Prozessor würde ich am allerwenigsten vertrauen. Der macht ganz verrückte Sachen, siehe ja die ganzen Sicherheitslücken in letzter Zeit. Ich würde an deiner Stelle einen x86 Interpreter bauen. Das Problem aber auch hier: Der würde ja selbst auf einem echten Prozessor laufen...
 
Was für Kontrolle? Kannst Du den Usecase was Du machen willst und was evtl. nicht gehen könnte, einmal skizzieren?

Der Interpreter führt einen Befehl aus. Wie dieser exakt ausgeführt wird, kann Dir doch egal sein. Denn die Anforderung ist ja, dass z.B. "System.out.println("Hallo")" ausgeführt wird. Ob und wie er System findet, da die out Instanz um dann println aufzurufen ist ein Implementationsdetail, das doch gekapselt ist.
 
Wenn ich Dich richtig verstehe so möchtest Du alle Optimierungen deaktivieren:
-Djava.compiler=NONE

Das deaktiviert alle JIT Optimierungen... Und dieser Begriff BlackBox bezeichnet eigentlich etwas anderes, nämlich closed source, also nur ein Programm das ohne für Menschen lesbaren Quelltext... zu untersuchen ist.

Wikipedia gibt im Wesentlichen dazu zwei Begriffe:
- Black Box (Systemtheorie), ein geschlossenes System unter Vernachlässigung des inneren Aufbaus, siehe dort auch zur Wortherkunft
- und ein Flugdatenschreiber

Daher wäre auch meine Frage, wieso der ganze Firlefanz?
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben