JavaME scripting languages

[Nikita Kapitonov]

Hello there, I'm thinking about adding some scripting ability for my end users.

What it should like to be:

• an ability to write a script on a webpage
• to transfer it to a device,
• so device could run it,
• using hardware resources from script,
• maybe in a loop,
• to achieve greatest flexibility!
  

Now I'm using JSON configuration, and it already gives me a nice flexibility, with a rather small JSON parser. But I want more.

I was thinking to make my own scripting language for my needs, and I already did a little one, like you can make JSON array with JSON objects "commands", then execute it, parsing commands that you've implemented inside your app.

Example will be [{"cmd":"setValue", "var":"output1", "value":1},{"cmd":"wait", "seconds":3},{"cmd":"setValue", "var":"output1", "value":0}]

(this example obviously enables output1 then waits 3 s, then disables it)

Then I think that's not very cool in the long run, as you might want to make a "for" loop or comparison, or make some calculations, etc. So, I need a real scripting language that my app could parse.

I've found a nice list of java scripting languages, and even some comparisons of those.

Seems like coolest ones are:

• Groovy - fast, very javalike syntax, trendy
• Jython - fast, python is cool and trendy
• BeanShell - parses ordinary java code, that's cool
• Rhino - fast, javascript is very widespread and has javalike syntax
• Lua parsers - Lua is trendy in embedded apps

But you can't find J2ME parsers for most of that. So, filtering only those has J2ME/CLDC implementations, we have:

• Rhino - implementations are scary at first sight
• Rhino for J2ME CDC1.1 - hard to say if it could run under CLDC, and if it has bugs, updated in 2011
  
• Rhino JavaScript Interpreter J2ME/CLDC - at least has a little more description, some known bugs, updated in 2009
• MiniJOE - seems nice
• minijoe - not Rhino implementation, but also a subset of javascript parser, well documented, updated in 2010
  
• Lua - seems nice, but which one to use? And also, it seems I need to run compiler on lua texts before feeding them to interpreter. Not so cool, but why not?
• Kahlua - seems nice, documented, updated in 2011
• Mochalua - not so documented, updated in 2008
• Luaj - greatest documentation, lots of features, compiler invoked seamlessly, updated 2013
• Jill - not so well documented, not so up-to-date 2009
• Hecl - a scripting language designed specially for J2ME, and seems it must be small, because of its reduced syntax. Though it mainly focused on UI stuff, and maybe couldn't run under CLDC, and I don't see how to bind it to your java functions.
• FScriptME - a clipped port of FScript, initially a powerful yet simple language, ME one is really small, like a few classes and ~30 kB. Although a little old (2008) and unmaintained, seem it's easy to integrate it.

Hell, that's not so easy to choose an option from this list. To be objective, one needs also a precise memory footprint and maybe some performance tests. But oh maybe not this time.

So, my dear community, what do you think on scripting under javacint?

Do you have any experience in it?

What option would you take and why?

Did I miss any option?

[Florent Clairambault]

Hi Nikita,

I think it's definitely possible and worth trying. One application that might be very interesting to script is the simple setup of inputs handling and the report of data to a server. You can help user report data when they want it.

Luaj seems like the best deal out there, it's still maintained.  I tested groovy and beanshell in the past (on a JSE project). They were quite good.

Still:

- It takes a lot of time to actually provide all the base methods necessary to offer a fully featured control environment. 

- You will give a lot of power to your users. When problems arise, you have to fix them on what *they* built (which might be monsters). You have to maintain a stable API. Add some crash and logs reporting.

- I'm not sure a lot of users will be ok with typing (even a single line of) code.

- It will be slow and consume a lot of memory.

I can see two other options:

- Building a small expert system (sets of small rules) 

- Compiling code on server and deploying it in the program or as a liblet.

But I think scripting is a better one.

Best regards,

--
Florent

--
javacint group - http://www.javacint.com/
---
You received this message because you are subscribed to the Google Groups "Cinterion Java enabled chips support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javacint+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
  

[Nikita Kapitonov]

Hello Florent!

>>- You will give a lot of power to your users. When problems arise, you have to fix them on what *they* built (which might be monsters). You have to maintain a stable API. Add some crash and logs reporting.

You're right. Also, I need strong fool-proofing there. Some things I need to implement are:

- syntax checking.

- size of a program checking, as user could upload so big program to make "out of memory exception". Though I may just keep the script in a file, and execute it line-by-line, without keeping all script in memory, if it is possible.

>>- I'm not sure a lot of users will be ok with typing (even a single line of) code.

No problem, as the flexibility would be achieved in any case. It might be me or some other skilled person who can make scripts for those who can't, maybe with some money paid.

>>- Building a small expert system (sets of small rules)

I'm thinking about that in future some frequenly used "use-cases" and functions could be made as a natively-compiled code, maybe in an external library so they can be called from script.

>>- Compiling code on server and deploying it in the program or as a liblet.

Wow, I didn't thought about it. Really cool idea, because you can write programs in convenient Java language and it will be fast, low memory footprint, and no external interpreter-libraries needed.

Problems I see up for now:

- How to setup compiling on server-side?

- How to organize and transfer resulting liblet?

- Cannot so easily check the code validity.

- I think writing Java will be harder for end-users, than Lua.

I will go with LuaJ, as it's easier to implement, but maybe I will give the liblet variant a try someday.

Nikita.

2013/5/17 Florent Clairambault <flo...@clairambault.fr>