Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by jcn at 10:45 on Thursday 1 July    Add 'JSR 223: Scripting Pages in Java Web Applications' site to delicious  Add 'JSR 223: Scripting Pages in Java Web Applications' site to technorati  Add 'JSR 223: Scripting Pages in Java Web Applications' site to digg  Add 'JSR 223: Scripting Pages in Java Web Applications' site to dzone

Anders dan de titel van de JSR 223 zou doen vermoeden, zijn de leden van deze JSR uiteindelijk op een algemener scriptingmechanisme uitgekomen dan de smallere opdracht die alleen uitging van webscripting. De JSR is nu in early review, dus dit is een impressie van wat er gaat komen.

Definities

Volgens de definitie in JSR 223 is een scripttaal:

  • weakly typed
  • roept methodes aan van Java objecten, zgn. “Java language bindings”
  • geinterpreteerd (script wordt in hetzelfde proces gecompileerd en uitgevoerd)

Een script engine is deels de script interpreter, deels een Java API. Het bestaat uit een “front-end” (compiler), een symbooltabel en een “backend” (runtime). De front-end compileert de source naar “intermediate code”. Die intermediate code hoeft niet perse iets te zijn als byte code, het kan ook een instantie van een Java class zijn. De symbooltabel bevat de namespace van het script en bevat alle waardes van de variabelen in het script. De backend voert de intermediate code uit. Deze concepten worden allemaal gerepresenteerd in de script API.

Huidige situatie

Op dit moment zijn er een heleboel scriptingtalen die op het Java platform draaien. Rhino (Javascript), BeanShell, Jython, JACL, Groovy, Kawa… maar deze scripttalen werken allemaal op hun eigen manier. JSR 223 doet hier was aan door voort te bouwen op het Bean Scripting Framework dat ooit was ontwikkeld door IBM. De BSF maakt het in principe mogelijk om met verschillende scriptingtalen dezelfde API aan te spreken, waardoor ze uitwisselbaar worden.

Use Cases

Er zijn vier soorten gebruik van een scriptingtaal:

  • standalone interpreter
  • script compiler => class files
  • script engine embedded in java applicatie
  • script genereert web content

Alhoewel JSR223 in eerste instantie bedoeld was voor het laatste geval, is het algemeen genoeg om ook te functioneren op het derde geval. JSR223 kijkt niet naar het tweede geval omdat de bytecode specificatie al voldoende specificeert. De JSR levert een implementatie van PHP.

Voorbeeld

Ik doe dit uit mijn hoofd omdat je codeslides nooit snel genoeg kan overnemen, maar het model is vrij duidelijk:

   ScriptEngineManager sem = new ScriptEngineManager();
   sem.put("naam", eenOfAndereWaarde);
   ScriptEngine se = sem.getEngineByExtension(extension);
   se.put("foo", nogEenWaarde);
   se.eval(new FileReader(filename));

Dit is zo’n beetje wat je moet doen. In plaats van getEngineByExtension() zijn er ook andere manieren om engines op te zoeken: op naam en op MIME type. Er wordt gebruik gemaakt van het jar-manifest mechanisme, zodat je scriptengines kunt registreren die vervolgens automatisch door een ScriptEngineManager gevonden zullen worden. wat verder nog interessant is, is het “binden” van de variabelen met de put() methodes. Het verschil tussen het registreren bij de ScriptEngine en de ScriptEngineManager is dat het registreren bij de eerste de variabele beschikbaar maakt aan dat ene script, terwijl de variabelen in de laatste globaal zijn, en dus over scriptengines (en dus scripttalen!) heen gedeeld kunnen worden. In de demo was dit te zien doordat verschillende scriptpagina’s die webcontent genereerden met verschillende scripttalen toch de sessiestate deelden.


© 2019 Java Competence Network. All Rights Reserved.