[Java] 'eval()' methode

[Wekko]

Ik ben op zoek naar een vergelijkbare functie als 'eval()' in JavaScript en PHP, maar dan in Java. Aangezien Java pre-compiled is bestaat een dergelijke functie niet. Een optie is om reflection te gebruiken, maar buiten dat het traag is (snelheid is een issue) vind ik het ook niet handig genoeg.

Ik heb bijvoorbeeld de string "justAMethod(value1,value2)". Nu wil ik deze methode, inclusief argumenten aanroepen op een vast object. Dus new TestObject().bovenstaandestring . In Javascript zou dat dus eval("TestObject()."+methodstring); zijn.

Ik heb het nu opgelost met een regular expression om functies uit elkaar te halen en dan de functie naam door een hele lange lijst if/else if statements te halen. Het werkt, maar het komt nogal over als een hele ranzige oplossing. Bij het toevoegen of aanpassen van functionaliteit moet dat dus ook in de if/else if constructie.

Reflection lost dit deels op, maar je moet nog steeds de functies en argumenten uit elkaar trekken met een regex. Daarnaast is performance natuurlijk een issue bij reflection.

The methodenamen komen uit XML bestanden, vandaar dat het strings zijn. Iemand enig idee of hier een handige oplossing voor is?

[Crayne]

Misschien heb je hier wat aan?

[Verwijderd]

Ik vermoed dat je het hier en daar niet helemaal handig aanpakt.
1. Reflectie is niet significant traag
2. Je kunt het vast met een net OO principe op een andere manier oplossen.

[jAnO!]

google...

http://mindprod.com/jgloss/eval.html

optie 6 is wel netjes.
Of gebruik gewoon Jyton oid.

edit:
spuit elf!

en inderdaad riekt dit naar redesign

[ Voor 25% gewijzigd door jAnO! op 02-07-2007 16:54 ]

[BasieP]

method namen uit xml?
het klinkt mij in de oren dat je iets aan je design moet veranderen.

Een functie als eval is overbodig in een goed opgezet model

[Wekko]

Ik was al bang voor dergelijke reacties . Ik kan niet alle details geven, maar het gaat in ieder geval om een parsing algoritme. De grammatica is gedefineerd in een XML file, samen met de acties. Deze acties worden tijdens het parsen uitgevoerd en hebben vooral als functie om attributen door te geven (bv setParentAttribute()).

Het probleem is dat de grammatica dynamisch is. Deze worden gemaakt via een management interface. De parser moet verschillende grammatica's uit kunnen lezen en toe kunnen passen.

[Verwijderd]

Dan blijft ik nog steeds bij mijn eerder gemaakte opmerking. Reflectie zou niet significant moeten uitmaken (je kunt natuurlijk Methods cachen) en er is waarschijnlijk een betere methode om dit aan te pakken. Zeker als je middels de interface controle hebt over de xml.

[Not Pingu]

Wekko schreef op maandag 02 juli 2007 @ 17:00:
Ik was al bang voor dergelijke reacties . Ik kan niet alle details geven, maar het gaat in ieder geval om een parsing algoritme. De grammatica is gedefineerd in een XML file, samen met de acties. Deze acties worden tijdens het parsen uitgevoerd en hebben vooral als functie om attributen door te geven (bv setParentAttribute()).

En is er een reden waarom je parser dat zelf niet zou kunnen parsen? Je zegt zelf al dat de methods ook geparsed worden dus kun je toch met een simpele lookup de uitkomst van die methode bepalen?

[Wekko]

Not Pingu schreef op maandag 02 juli 2007 @ 18:25:
[...]


En is er een reden waarom je parser dat zelf niet zou kunnen parsen? Je zegt zelf al dat de methods ook geparsed worden dus kun je toch met een simpele lookup de uitkomst van die methode bepalen?

Tis geen Java parser.

er is waarschijnlijk een betere methode om dit aan te pakken. Zeker als je middels de interface controle hebt over de xml.

Die zou ik graag horen ;-).

[Verwijderd]

Wekko schreef op maandag 02 juli 2007 @ 21:01:
Die zou ik graag horen ;-).

Prima, maar daarvoor hebben we natuurlijk wel meer informatie nodig. Vertel eens wat meer over je intenties en hoe je dat gedacht had om te zetten naar uitvoerbare code. Ik ben benieuwd hoe je reflectie gebaseerde implementatie er uitziet en waarom deze dus niet snel genoeg was. Zou je dat kunnen tonen?

[cspare]

Misschien kan je iets met een strategy in combinatie met een factory. Beetje afhankelijk van hoeveel verschillende algoritmes je hebt en hoe ze van elkaar verschillen.

[Niemand_Anders]

Ik denk dat je eens het 'intepreter' design pattern eens moet bestuderen. Een C# implementatie van dit design kun je vinden op http://www.dofactory.com/Patterns/PatternInterpreter.aspx, maar zal zonder veel moeite ook wel naar java om te zetten zijn.

Een andere methode (zeer snel, maar wel stuk complexer) is dat je op basis van je XML definitie java code genereerd en inline compileert. Vervolgens laad je de assembly dynamisch in en gebruik je de intepreter. De definitie zal bijna niet (of zelden) wijzigen, dus kan het resultaat meerdere malen hergebruikt worden. De XML definitie wordt dan omgezet naar een 'native' parser. De definitie blijft dus flexibel, terwijl de parser redelijk statisch blijft.

Ik had eerst een dynamische parser die CSV/XML files importeerde naar een database model via een definitie in XML. Hoewel dit design 30 records per seconde haalde, duurde de volledige import (regelmatig meer dan 1 miljoen regels) ontzettend lang. Vervolgens ben ik op zoek gegaan naar een betere methode en kwam uit op het dynamisch compileren van code. De aangepaste tool verwerkte bijna 1200 records per seconde. Toen ik daarna de 'parser' had geschreven naar een thread based import parser support kwam ik uiteindelijk uit op 9000 regels per seconde en zit nu aan de hardware max (leessnelheid van het CSV bestand).

Het test bestand bestond uit 1.000.000 regels met 38 velden en een gemiddelde lengte van 2600 tekens en is in totaal 2,6GB groot. Dit bestand werd binnen 2 (7) minuten verwerkt. De eerste gegenereerde native parser deed iets minder dan 15 (90) minuten over dit bestand. De dynamische parser deed er meerdere dagen over. De eerste tijd is de inleestijd (lezen van regel en opdelen naar de 38 velden), de twee (tussen de haakjes) is de tijd van start tot finish (inclusief bewerkingen en opslag in database).

Het principe van het omzetten van een definite naar 'native' code gebruik ik inmiddels op ontzettend veel vlakken. Database O/R wrappers maken ook gebruik van deze techniek.