# Skriptsprachen für die JVM



## AlArenal (18. Jul 2006)

Ich beschäftige mich seit einer Weile zunächst mal lesenderweise mit Skript-Sprachen für die JVM. Die Auswahl ist groß, die Zeit ist limitiert. Was sollte man sich antun? Welche Sprache ist wofür geeignet? Wer hat überhaupt schon Erfahrungen?

*Links:*
- Groovy (JSR241): Groovy - Home
- BeanShell: BeanShell - Lightweight Scripting for Java
- Jython: The Jython Project
- JRuby: Home - JRuby - Codehaus
- Rhino: Rhino - JavaScript for Java


----------



## SnooP (18. Jul 2006)

Wofür braucht man das eigentlich?


----------



## thE_29 (18. Jul 2006)

Sag mal was man mit dem machen kann, dann gucke ich mir das an und berichte 


Die Beanshell, sagt mir sogar was..

Das is das man zur Laufzeit java Code "scripten" kann oder?

Sind das alles solche Dinger?


----------



## AlArenal (18. Jul 2006)

SnooP hat gesagt.:
			
		

> Wofür braucht man das eigentlich?



Gute Frage!

Neben dem offensichtlichen Nutzen, eine Anwendung mit einer Skriptsprache für den User zu versehen, gehts wohl vor allem um Produktivitätsgewinne hier und da. Auf der Serverseite (J2EE) kenne ich mich nicht aus, kann mir aber gut vorstellen, dass eine Integration von GRAILS (Groovy on Rails) in bestehende Umfelder schneller zu Produkten führen kann. Clientseitig überlege ich schon eine Weile gewisse Funktionalitäten für eine schnelle Erweiterung in Skripte auszulagern, evtl. für User zugänglich, damit ein User sich in einem definierten Umfeld selbstständig eigene Funktionelitäten erstellen kann (rein mathematisch, also irgendwelche Formeln, die über ne Schnittstelle auf Live-Daten zugreifen) und diese Funktionlität beispielsweise in einem Flowchart miteinander verbindet, ähnlich wie Altova MapForce es für XML visualisiet....

Ansonsten bin ich noch dabei mirgenug anzueignen, bis die kritische Masse erreicht ist und es in mir "klick" macht. 

- Scripting power saves the day for your Java apps - Improve your user's satisfaction with support for user-defined scripting in your Java applications (schon was älter, 1999)
- "Scripting for Java" war Leitartikel vom Java-Magazin 6.2006. Hab ich dummerweise nicht vorliegen 
- In irgendeiner realtiv aktuellen iX war doch noch ein Artikel über Groovy, oder? *grübel*


----------



## AlArenal (18. Jul 2006)

Grundsätzlich haben wir in Java ja schon ein wenig damit zu käämpfen, dass viele einfache Dinge recht umständlich zu lösen sind. Beispiel von Bruce Eckel aus einer Artikelserie, die ich gestern noch in meinem Blog verwurstet habe (siehe dortige Links), ist das Öffnen einer Datei und Suchen im Inhalt. In Skriptsprachen (im Artikel gehts grötenteils um Python) ist das ein Zweizeiler. In Java tippst du dich dumm und dämlich und musst zwischendurch noch in der API wühlen.

Das flotte Zusammenfügen gut getesteter (Java-)Module über eine Skriptsprache, verbindet viele Vorteile aller Welten. Man ist produktiv, verwendet vorhandenen Code weiter, setzt auf vorhandenes Know-How, verlangt Kunden keinen Wechsel auf eine andere Technologie ab, ....

Soweit die Theorie. Nur hab ich noch praktisch nicht viel gemacht und daher ist das für mich noch graue Theorie und ich sehe noch nicht so ganz wie es sich zusammenfügt.


----------



## AlArenal (18. Jul 2006)

Auch Ausgabe 8.2006 des Java-Magazins hat einen größeren Artikel "Neue Sprache für Java: Groovy - Dynamische Programmierung mit Groovy". Groovy wird eh Bestandteil von Java werden, ob wir wollen oder nicht. Schadet ja nicht, sich ein wenig damit auseinanderzusetzen.


----------



## thE_29 (18. Jul 2006)

Also könnte man das ganze beim mIRC Client vergleichen 

Der hat dort auch so ein "Scripting" drinnen!

Dh, mit Java wäre sowas via Beanshell nachbaubar?

Na hui....

Aber da unsere SW für DAUs schlecht hin ist.. (die bestätigen Dialoge indem sie aufs X drücken.. Bzw hatten vorher nie ne Maus in der Hand), ist das sowieso nur wars fürs nebenbei angucken!


----------



## AlArenal (18. Jul 2006)

Deutscher Online-Artikel:
Dynamische Freundschaft - Flexible Java-Objekte mit Groovy und Grails (iX 07/2006)

Code-Beispiel eines Newsfeed-Readers, der von einem Feed der BBC die ersten 10 Einträge in einer Swing-Tabelle in einem Frame anzeigt:

```
def base  = 'http://news.bbc.co.uk/rss/newsonline_uk_edition/'
def url   = base +'front_page/rss091.xml'
def items = new XmlParser().parse(url).channel[0].item

def swing = new groovy.swing.SwingBuilder()
def frame = swing.frame(title: 'Top 10 BBC News') {
  scrollPane {
    table() {
      tableModel(list: items[0..9]) {
        closureColumn(header: 'title', 
            read: { item -> item.title.text() } )
        closureColumn(header: 'text', 
            read: { item -> item.description.text() } )
      }
    }
  }    
}
frame.pack()                               
frame.show()
```


----------



## AlArenal (18. Jul 2006)

Kritische Anmerkungen zu Groovy (aus 2004 und 2005):

- The groovy sinking ship
- How Groovy Lost its Groove Thang

Mglw. ist Groovy doch nur ein weiteres Projekt, dass unverständlicherweise zu JSR-Ruhm kam? Vielleicht och besser nen Blick auf JRuby oder Jython werfen, weil man damit wenigstens noch außerhalb der Java-Possé was anfangen kann? Das macht den Einstieg in Java-Scripting irgendwie alles nicht einfacher...


----------



## Murray (18. Jul 2006)

Zur Frage, was man damit machen kann: ich habe einmal in ein System eine Jython-basierte Konsole eingebaut, so dass man zur Laufzeit z.B. Methoden aufrufen oder Variablen ausgeben konnte. Das war so eine Art Debugger und Low-Level-Admin-Konsole; man konnte einerseits im Entwicklungssystem Code testen, der noch nicht über die Oberfläche erreichbar war, andererseits konnte man das auch im Produktivbetrieb verwenden, um im echten System irgendwelche internen Zustände nachzuvollziehen. Man muss dabei natürlich im Auge behalten, dass man da sicherheitstechnisch betrachtet ein Scheunentor aufreisst...

In einem anderen Projekt habe ich Groovy zum Prototyping eingesetzt. Das System hatte eine Art Plugin-Mechanismus, wobei diese Plugins normalerweise in Java geschrieben und als Jar-Files ausgeliefert wurden. Alternativ konnte man das aber auch in Groovy machen, was den Vorteil hatte, auch mal eben im Rahmen einer Demo kleine Änderungen zu machen, ohne das ganze Build-/Deploy-Karussel zu drehen, oder auch nur den Server neu starten zu müssen. Nachteilig waren hier vor allen die fehlende Unterstützung von Java-5-Features sowie gewisse Performance-Probleme (beim Parsen der Groovy-Sourcen wurde aus irgendwelchen Gründen ständig wieder auf das Filesystem zugegriffen).

Ich bin mal gespannt, was sich jetzt mit dem JDK 1.6 tut, dort wird ja wohl eine Rhino-Engine als Referenzimplementierung des JDR 223 mitgeliefert; mal sehen, wie sich die anderen da behaupten können.


----------



## AlArenal (18. Jul 2006)

@murray:
Hast du außerhalb der JVM auch nur mit Python gearbeitet? Ich überlege, ob es nicht sinniger ist, sich mit einer "extern" existenten Sprache zu beschäftigen, die eine große User- und Code-Basis hat, anstatt dann mit Rhino, Groovy oder BeanShell wieder auf die JVM festgelegt zu sein. 
Mal über den Tellerrand geschaut, hat MS gerade die Beta 9 der Version 1.0 von IronPython rausgerückt, einer Adaption von Python auf das .NET 2.0 Framework. Überhaupt ist Python derzeit sehr präsent, dicht gefolgt von (J)Ruby.

Man hat mal wieder die Qual der Wahl. Es gibt schon wieder nicht einen zu Ende gedachten Weg, sondern eine Vielzahl. Das für sich genommen ein Vorteil, aber irgendwie auch blöde, wenn man sich entscheiden muss. Ich kann doch nicht erst ein halbes Dutzend Sprachen evaluieren, ehe ich am Ende unter den besten doch das Bauchgefühl entscheiden lassen muss. 

Auch wenn Rhino bald an Bord ist und Groovy folgt.. irgendwie scheint mir derzeit Jython auch abseits der JVM (als Python, IronPython, ..) die flexibelste Alternative. Zumal ja auch Bruce Eckel mittlerweile drauf schwört.. obowhl.. das war 2003.. mittlerweile hat er vielleicht schon wieder die Meinung geändert und findet Haskell ganz knorke..


----------



## Murray (18. Jul 2006)

Nein, ich habe ansonsten nicht mit Python gearbeitet; Jython habe ich damals nur genommen, weil die Integration am einfachsten erschien - das ist auch schon ein paar Jahre her. Und mir ging es eben auch nicht darum, existierende Scripte in meine Anwendung zu integrieren, sondern umgekehrt: ich wollte das, was ich normalerweise in Java gemacht hätte, ohne expliziten Compile-Schritt zur Laufzeit machen, aber eben ansonsten möglichst so, wie ich es auch in Java gelöst hätte.

Für das, was ich bisher mit Scripting gemacht habe, brauche ich eine Sprache, die a) möglichst gut mit Java-Code zusammenschnäbelt (ich möchte z.B. Klassen schreiben könne, die von Java-Klassen abgeleitet sind) und b) von der Syntax und den Konzepten her möglichst nah bei Java ist, damit Prototypen irgendwann wieder "eingefangen" und in "normale" Klassen überführt werden können. Im Moment würde ich für neue Projekte mir wohl Groovy und BeanShell nochmal genauer ansehen.


----------

