Kompilering / virtuelle filer

Jeg er ikke helt sikker på om jeg forstår dig. Hvad er en virtuel fil?

Hvis du vil bruge compileren fra java så brug

Runtime.getRuntime().exec();

eller måske er det muligt med sun.tools.* selv om man helst skal holde sig fra de pakker. Men ellers må der findes nogen 3. parts... kender dem ikke lige.
En api er under udvikling under jsr til det men der går et godt stykke tid før vi kommer til at se noget til den
http://www.jcp.org/en/jsr/detail?id=199

Bytecode generation kan være vanskeligt men kig på javaassist det er næsten javakode som man giver den.

Her er et eksempel:

        ClassPool pool = ClassPool.getDefault();
        CtClass cc = pool.makeClass("Bla");

        CtMethod m = CtNewMethod.make("public static void main(String[] args) { " +
                "System.out.println(\"Bla!\"); }", cc);
        cc.addMethod(m);
        cc.writeFile();

og du kan også hive fat i den direkte uden at skrive vil jeg mene
        cc.addInterface(pool.get("Interface"));

        Class c = cc.getClass();

        Interface iff = (Inteface) c.newInstance();
        iff.kald()

->simonvalter: Ja, jeg bruger allerede
Runtime.getRuntime().exec("javac..."). Det er også rigtigt, at man kan bruge den interne klasse com.sun.tools.javac.Main(). Man kan anvende Javassist eller ASM eller lign. til dynamisk bytecode-generering, men det er ofte kringlet og kompliceret.

"Problemet" med javac er, at compileren virker på fysiske .java- og .class-filer. Indtil det bliver muligt at foretage intern kompilering, jf. din reference, må man altså leve med kald af javac, og her interesserer jeg mig for, om det er muligt at simulere de fysiske filer med virtuelle filer, f.eks. vha. "RAMDisk", altså et stykke software, hvor en del af memory fungerer som et virtuel filsystem. Se f.eks. http://www.cenatek.com/product_ramdisk.cfm eller http://www.superspeed.com/ramdisk.html

Den frække løsning (før rigtig intern kompilering bliver mulig) ville være, hvis man internt i Java kunne simulere et virtuelt filsystem, som javac kan afvikles mod.

Nogle kommentarer/erfaringer omkring RAMDisk eller muligheden for at etablere et virtuelt filsystem internt i Java?

Jeg kender ikke de produkter men jeg har kender godt lidt til memory drives og der mener jeg at operativ systemet ser det som et almindeligt drev og så skulle der vel ikke være nogen problemer i at køre javac mod filer der ligger der.

Jeg kender ikke nogen java produkter der kan det så det er internt i Java. Men jeg tror da det er muligt at f.eks skrive kode med javaassist der indlæser klasser og opbevarer dem internet i en eller anden struktur som CtClass'er hvorefter du kan tilgå og compile dem og skrive til disk eller indlæse i hukommelsen disse klasser kunne automatisk blive indlæst ved ny,ændret osv klasse i det rigtige filsystem, men jeg tror ikke du kommer uden om at skrive en masse selv.

Hvad grunden til det skulle være er jeg heller ikke helt med på endnu :)

Hvis jeg stadig ikke har forstået dig så kunne du forsøge dig i #java på Efnet - irc. Der sidder en masse smarte mennesker men det sværre bliver at overbevise dem om at der er en grund til det inden du bliver bannet derfra ;)

Her er et eksempel på JSR 199 der er i Mustang http://www.javalobby.org/java/forums/t44534.html
Det er vel sådan noget du leder efter..men du må nok vente lidt endnu.

Hvad har du fundet ud af?

->simonvalter: Mange tak, det ser meget interessant ud!

Det må præcis være noget i den stil jeg sukker efter :-)

"The first argument is of type JavaFileManager , and is an abstract representation of a 'filesystem' - it could be in-memory, across a socket, or on the actual filesystem; but the tool api allows for the actual source-code to be compiled to come from an implementation of your choosing. Incidentally, the demos that ship with the JSR 199 API (while being a little outdated) have an example of an in-memory compile-from-string example."

Hvad gør jeg? Indtil videre bruger jeg bare den "grove" metode med at skrive til en (fysisk) .java-fil, som jeg så kompilerer med Runtime.getRuntime().exec("javac...") til en (fysisk) .class-fil.

I en ikke så fjern fremtid :-) må det være muligt helt at undgå disse .java- og .class-filer, således at man f.eks. kompilerer en String direkte ind i en classloader. Fordelen ved dette er dels hastighed men måske også beskyttelse af kode. Alt andet lige er det sværere at aflæse kode, der kun eksisterer i memory.

Ellers bruger jeg bytecode-manipulering (ASM: http://asm.objectweb.org/, andre værktøjer er også anvendelige, f.eks. BCEL, Javassist) i visse tilfælde, hvor min kode følger en bestemt skabelon. Herved undgås kompilering, idet bytecoden skrives direkte til en classloader, hvilket er ekstremt hurtigt/effektivt.

->simonvalter: Smid gerne et svar.

ok

Mustang er jo paa gaden i beta nu og jeg har skrevet lidt her http://www.eksperten.dk/artikler/941

->arne_v: Fornemt at du huskede netop dette spm!

Kald af kompileren direkte fra kode er i min verden lige så essentielt som reflection og AOP, så jeg vil se på det med stor interesse.

En ny facilitet, som jeg også finder meget interessant, er den nye Desktop API (http://java.sun.com/developer/technicalArticles/J2SE/Desktop/mustang/desktop_api/).

maaske skulle jeg tilfoeje lidt om det til artiklen

men generelt er GUI ikke min store interesse

PS: Jeg kunne ikke huske lige netop dette spoergsmaal, men jeg kunne huske
    dit brugernavn, saa jeg ledte lidt efter spoergsmaalet

->arne_v: God ide. Jeg tror i øvrigt at netop denne del endnu ikke er færdigudviklet. Jeg har rodet noget med JDIC, som wrapper IE, og den er slet ikke på niveau med specielt JExplorer (http://www.jniwrapper.com/pages/jexplorer/overview), som jeg ser det. Basale problemstillinger som håndtering af indhold af frames, pop-up vinduer m.m. er ikke færdigt i JDIC endnu, og helt konkret implementerer JDIC ikke DOM, som JExplorer gør, hvilket er en stor forskel. Den nye Desktop API er dog andet og mere end JDIC, så..

->arne_v: Hvordan skulle du skrive et par linier om din subjektive vurdering af Mustang. Er det en forbedring på niveau med det forventede, eller er der positive/negative overraskelser?

->arne_v: Der skulle stå "Måske skulle du.."

ogsaa det

mit indtryk er at 1.6 ikke er naer saa stor som 1.5

og at aendringerne er mere specialiserede og mindre generelle

(alle kan da bruge generics og auto boxing/unboxing, men kald af compiler
runtime henvender sig til de faa)

Jeg har lige tilføjet et lille desktop eksempel til artiklen.