.java-Dateitext Compile zur Laufzeit ohne File

J90

Aktives Mitglied
Hallo,

ich möchte wissen, ob es möglich ist eine einen .java Code wie z.B.
Code:
import package Beispiel.Klasse;

public class Test{

   private Klasse K = new Klasse();

   public Test(){

    }

}
zur Laufzeit als String in eine class zu kompilieren ohne eine File auszugeben?
D.h. dass ein Code als String vorhanden ist und die class dynamisch geladen wird
ohne das eine .class-Datei angelegt wird?
Nach dem Motto:
Code:
String Code = "Codeklasse von oben";
JarFile Jar = new JarFile("fuer Importe");
Class Class = loadClass(Code,Jar);
 
Danke für die Infos. Eine Frage zur jOOR API:
Sie funktioniert bei mir im NetBeans Editor und auch in einer kompilierten AOT-Anwendung.
Allerdings habe ich das Problem, wenn ich von dieser AOT-Anwendung einen Installer erstelle und diese
Anwendung installiere, dass die Klasse Compile eine Exception wirft:
"Error while compiling 'className' ". Der Pfad stimmt, allerdings scheint die Lib in diesem Fall nicht
die Klasse compilieren zu können.
"ClassLoader cl = lookup.lookupClass().getClassLoader();
cl.loadClass(className);" schlägt fehl
Hat jemand eine allgemeine Idee woran dies liegen könnte?
Die entscheidende Methode der Klasse Compile sieht wie folgt aus:
Code:
 static Class<?> compile(String className, String content, CompileOptions compileOptions) {
        Lookup lookup = MethodHandles.lookup();
        ClassLoader cl = lookup.lookupClass().getClassLoader();

        try {
            return cl.loadClass(className);
        } catch (ClassNotFoundException ignore) {
            System.err.println("Compile.compile('"+className+"'): " + ignore.getMessage());
            JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();

            try {
                ClassFileManager fileManager = new ClassFileManager(compiler.getStandardFileManager(null, null, null));

                List<CharSequenceJavaFileObject> files = new ArrayList<CharSequenceJavaFileObject>();
                files.add(new CharSequenceJavaFileObject(className, content));
                StringWriter out = new StringWriter();

                List<String> options = new ArrayList<String>();
                StringBuilder classpath = new StringBuilder();
                String separator = System.getProperty("path.separator");
                String prop = System.getProperty("java.class.path");

                if (prop != null && !"".equals(prop)) {
                    classpath.append(prop);
                }

                if (cl instanceof URLClassLoader) {
                    for (URL url : ((URLClassLoader) cl).getURLs()) {
                        if (classpath.length() > 0) {
                            classpath.append(separator);
                        }

                        if ("file".equals(url.getProtocol())) {
                            classpath.append(new File(url.getFile()));
                        }
                    }
                }

                options.addAll(Arrays.asList("-classpath", classpath.toString()));
                CompilationTask task = compiler.getTask(out, fileManager, null, options, null, files);

                if (!compileOptions.processors.isEmpty()) {
                    task.setProcessors(compileOptions.processors);
                }

                task.call();

                if (fileManager.isEmpty()) {
                    throw new ReflectException("Compilation error: " + out);
                }

                Class<?> result = null;

                // This works if we have private-access to the interfaces in the class hierarchy
                if (Reflect.CACHED_LOOKUP_CONSTRUCTOR != null) {
                    result = fileManager.loadAndReturnMainClass(className,
                            (name, bytes) -> Reflect.on(cl).call("defineClass", name, bytes, 0, bytes.length).get());
                }

                return result;
            } catch (ReflectException e) {
                throw e;
            } catch (Exception e) {
                throw new ReflectException("Error while compiling " + className, e);
            }
        }
    }
 
Ich würde drauf tippen, dass javac nicht verfügbar ist.

(Warum brauchst du denn zwingend AOT? Wenn du sowieso ein ganzes JDK brauchst, seh ich nicht so den großen Nutzen davon...)
 
Ist javac für die Verwendung der Lib notwendig bzw. läuft die Kompilierung im Hintergrund nur über Javac?
Dann wäre meine Verwendung nicht mehr sehr sinnvoll in einer fertigen Anwendung oder lässt sich beispielsweise eine Javac.jar integrieren?
Die AOT-Anwendung ist für mich notwendig wegen Geschwindigkeit und einer schnelleren Installationsmöglichkeit auf einem Server.
Andere Frage: Gibt es auch eine Möglichkeit einen compilierten class-Code (als String) zu laden auf die Weise wie mit
einer .java-Datei? Auf diese Weise hätte ich nicht das Problem der Kompilierung..
(Vermutlich ist ein Umbau in JOOR möglich)

Das ganze dient der Möglichkeit eine Klasse, welche über Reflection geladen wird und jederzeit austauschbar/anbindbar
an eine richtige Anwendung sein muss, zu verschluesseln. Moeglich wird dies mit einer AOT-Anwendung,
bei welcher der native Code geschützt ist. Ich verschlüssele diesen "Reflection-Code" und dekodiere ihn in
der AOT Anwendung, wodurch dieser geschützt ist (zumindest grundlegend verglichen mit Obfuscation). Eine ähnliche Anwendung wäre beispielsweise die
Software "Meta Trader 4", welche für die Ausführung einer "Reflection Anbindung" nicht (einfach) decompilierbaren Code (C++) erzeugt.
 
Zuletzt bearbeitet:
Du benötigst eine Abhängigkeit zu dem jdk.compiler Modul. Dort ist das Tool implementiert, welches dann per ToolProvider.getSystemJavaCompiler() erzeugt wird.
 
Die AOT-Anwendung ist für mich notwendig wegen Geschwindigkeit und einer schnelleren Installationsmöglichkeit auf einem Server.
Grad bei nem Server würde ich von AOT am wenigsten Vorteil erwarten, mal getestet? Würde mich interessieren, wie da der Unterschied zu JIT ist.


Das ganze dient der Möglichkeit eine Klasse, welche über Reflection geladen wird und jederzeit austauschbar/anbindbar
an eine richtige Anwendung sein muss, zu verschluesseln. Moeglich wird dies mit einer AOT-Anwendung,
bei welcher der native Code geschützt ist. Ich verschlüssele diesen "Reflection-Code" und dekodiere ihn in
der AOT Anwendung, wodurch dieser geschützt ist (zumindest grundlegend verglichen mit Obfuscation). Eine ähnliche Anwendung wäre beispielsweise die
Software "Meta Trader 4", welche für die Ausführung einer "Reflection Anbindung" nicht (einfach) decompilierbaren Code (C++) erzeugt.
Da ich davon nur die Hälfte verstanden habe: Welcher Code ist verschlüsselt, der schon kompilierte oder der, welcher neu geladen werden soll?
Und vor wem willst du das Serverseitig schützen? uU gibts da bessere Wege...


Du kannst natürlich auch den schon kompilierten Code nachladen, dann musst du Serverseitig nichts kompilieren. (Wenn du AOT aus Performancegründen nutzt, klingt zur Laufzeit kompilieren zumindest nicht sehr sinnvoll...)
 
Im Nachhinein bin ich nun auch schlauer.. Die Frage hätte vermutlich eher lauten sollen
eine .class als String oder als byte[]-array dynamisch laden zur Laufzeit.

Die Verschlüsselung hat nichts mit meiner Frage zu tun, Ich möchte eine externe class via Reflection ausführen,
was ich bisher mit der (nicht unbedingt sinnvollen) .java zu .class Kompilierung durchgeführt habe.

Mein Ziel ist:

Verschluesselter Text (.class oder .java)-->Dekodierung zur Laufzeit ohne Files-->LoadClass dynamisch von der
dekodierung (String, byte[] oder etc.).

Auf den Vorgang der Compilierung von .java zur .class Datei kann ich gerne verzichten, sofern sich dadurch das Problem des Compilierens in der AOT Anwendung erübrigt. Eine Methode habe ich bereits gefunden, wie sich das ganze verhält mit
Code mit mehr Abhängigkeiten wird sich zeigen..

Zu den Performanceunterschieden:
Es macht wirklich sehr viel Sinn mit AOT. Die Performance Unterschiede sind
in meinem Fall sehr stark zu JIT. Ich hatte auch schon eine JIT am laufen auf
dem Server, allerdings mit einer sehr höheren Auslastung (insb. CPU).
Die Anwendung basiert auf einer Netzwerkverbindung zu einem Börsen-Broker
und hat sehr viele Jar-Importe (40-50 Jars).
Durch das das Verwenden eines AOT-Compilers ist der gesamte Code nativ,
was die Ausführung sehr stabilisiert hat.
 
Zuletzt bearbeitet:
Im Nachhinein bin ich nun auch schlauer.. Die Frage hätte vermutlich eher lauten sollen
eine .class als String oder als byte[]-array dynamisch laden zur Laufzeit.
Ganz grob sowas wie:

Java:
class ByteArrayClassLoader extends ClassLoader {
 
  public ByteArrayClassLoader(final ClassLoader parent) {
    super(parent);
  }

  Class<?> load(String className, byte[] data) throws ClassNotFoundException {
    defineClass(className, data, 0, data.length);
    return loadClass(className);
  }

}

Und dann Class<?> clazz = byteArrayClassLoader.load("...", bytes);
 
Nach verschiedenen Versuchen fällt diese Variante ersteinmal aus dem Raster:
Das Verschlüsseln des Bytecodes und die Dekodierung sind fehlerhaft (AES128).
Zudem funktioniert nicht das Ausführen der Klasse an einem externen Standort (wegen folgender Frage?):

Ich versuche nun die Variante mit der Java-Code Konvertierung durchzugehen. Ist es richtig, dass
alle Jar-Imports in der Klasse beim Compile Vorgang als VM-Option "-classpath" angefügt werden müssen?
Dies würde nämlich zu meiner Erkenntnis führen, das es eigentlich nicht geht, außer ich integriere
irgendwie die Jar-Dateien in meiner Anwendung, welche allerdings AOT-Compiliert werden soll/ist?

Momentan stoppt meine installierte Anwendung noch davor bei diesem Punkt
(und kommt garnicht erst zu der classpath Stelle):

Code:
  Lookup lookup = MethodHandles.lookup();
        ClassLoader cl = lookup.lookupClass().getClassLoader();

        try {
            return cl.loadClass(className);
        } catch (ClassNotFoundException ignore) {
            System.err.println("Compile.compile('" + className + "'): " + ignore.getMessage());
            JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();

Ich habe rt.jar (java) nun auch in meine Anwendung integriert, ohne Erfolg.

Wenn jemand eine Info hätte, wie ich den JavaCompiler in einer AOT-Anwendung
geladen bekommen, wäre das sehr hilfreich, in diesem Gebiet habe ich nämlich keine Ahnung..
 
Zuletzt bearbeitet:
Nach verschiedenen Versuchen fällt diese Variante ersteinmal aus dem Raster:
Das Verschlüsseln des Bytecodes und die Dekodierung sind fehlerhaft (AES128).

Dann ist irgendwas beim Verschlüsseln falsch, und wird vermutlich auch scheitern, wenn man den Java-Code verschlüsselt.

Zudem funktioniert nicht das Ausführen der Klasse an einem externen Standort (wegen folgender Frage?):

Ich versuche nun die Variante mit der Java-Code Konvertierung durchzugehen. Ist es richtig, dass
alle Jar-Imports in der Klasse beim Compile Vorgang als VM-Option "-classpath" angefügt werden müssen?
Dies würde nämlich zu meiner Erkenntnis führen, das es eigentlich nicht geht, außer ich integriere
irgendwie die Jar-Dateien in meiner Anwendung, welche allerdings AOT-Compiliert werden soll/ist?
Ja, alle Klassen, die deine neue Klasse braucht, müssen auch im Classpath liegen. Du kannst deren gesamten Abhängigkeiten mitladen.
Ich halte AOT für den ganzen Anwendungsfall aber auch generell nicht für das sinnvollste...
 
Mit anderen Worten ich sollte am besten einfach meine Anwendung nicht verschlüsseln durch nativen Code
und stattdessen die Verschlüsselung des Codes ermöglichen durch eine JIT-Anwendung?

Da habe ich aktuell kein sehr großes Verlangen danach, mein komplettes Konstrukt über den Haufen zu Werfen,
weil die Anwendung an einer kritischen Stelle nicht funktioniert..Ist mit Java an diesem Punkt schon sehr ärgerlich, bei C++ würde überhaupt keine Arbeit anfallen
für nativen Code..
 
Mit anderen Worten ich sollte am besten einfach meine Anwendung nicht verschlüsseln durch nativen Code
und stattdessen die Verschlüsselung des Codes ermöglichen durch eine JIT-Anwendung?
Erstmal solltest du klären, ob und welche Teile warum verschlüsselt sein müssen.
(Bei mir wäre zb das letzte, woran ich bei einer Server-Anwendung denken würde Verschlüsselung...)

weil die Anwendung an einer kritischen Stelle nicht funktioniert
Wenn die kritische Stelle ist, dass der gesamte Code nativ kompiliert sein muss: ja dann ist Java die falsche Wahl gewesen.
Die Fälle, in denen das nötig ist, sind aber wirklich absolute Randfälle, die man fast immer anders lösen kann.
 
Es macht insgesamt auch nur einen minimalen Anteil an meiner Arbeit an meiner Anwendung aus, allerdings
wollte ich mich mit diesem Teil etwas beschäftigen und es ausbessern. Der Austausch mit dem einfachen Laden einer
normalen .class Datei ist auch kein großer Akt.

Ich werde bei Zeit nocheinmal weiter schauen, wobei dann eigentlich doch wieder nur das Codieren und Dekodieren einer .class-Datei infrage kommt, da die Imports als Jars mehr nicht vorhanden sind..
 

Zurück
Oben