Java VM in Hanlin V3

[Tumaini]

Hello!

I recently acquired a Hanlin V3 (Bebook) and replaced the firmware with Tirwal 2.9. It seems to be a great little device, though apparently lacking good developer support.
Being a Java developer, I looked around a bit for Java support on the device and found some posts stating that indeed the V3 had some form of Java VM.

Does anyone know what Java VM is running on the Hanlin V3?
If it is a custom one, is there an SDK or similar?

I've read about the possibility for BASH scripts, though there seem to be few of these circulating and no clear guidelines on how to get them to work.
Has anyone got information on this?
It seems someone called Leo has made some progress in this area, showing off a Wikipedia application, Sudoku etc., but with very little documentation.

Thank you for your time!

[wiffel]

Tumaini,

Yes there is a version of the Java VM on the Hanlin V3. As far as I remember, it is a microedition version of java (kind of like on mobile phones). I'm not quite sure anymore which profiles are supported, but it means you will have to compile for java 1.4 and use the pre-verifier.

Yes, there is a trick to actually launch things using a bash script. You just change the extension of the script to '.exe.fb2'. That will execute the script.

Enclosed you find an old 'HelloWorld' project that I used to test Java on the Hanlin. For me it was some time ago, so I'm not quite sure anymore of everything. But maybe it can give you something to start with.

Wilfried

[Tumaini]

Thank you very much for the reply, wiffel!
That was more than I had hoped for.
So it's indeed running something similiar to J2ME?
I've coded some for mobile phones before so that's very good news.

Big thanks for the example code, I see now how to set it up on the device (I think).
How did you find the classes.jar (or the contents from Jinke), is the source for those libs available somewhere?

Thank you again for your information, it was very enlightening!

[wiffel]

Originally Posted by Tumaini

So it's indeed running something similiar to J2ME?
I've coded some for mobile phones before so that's very good news.

Yes, it is similar to J2ME. I think I actually used a J2ME dev toolchain to make the hello world thingy.

Originally Posted by Tumaini

Big thanks for the example code, I see now how to set it up on the device (I think).
How did you find the classes.jar (or the contents from Jinke), is the source for those libs available somewhere?

Some time ago I did make an adapted version of the firmware. To do that, I had to extract all the files of the firmware first. So, I do have all of the files of the firmware on my machine including the 'classes.jar'. I'm afraid there is not very much extra info besides that.

I did try to port mochalua (a java implementation of Lua) some time ago, but stopped with that. Attached you find the two main files of that project. You can neglect the part that has to do with Lua, but it also shows how to handle key-presses and drawing onto the screen. It's very unmature code, but maybe it can help you a bit further.

Wilfried

Good luck

[Tumaini]

Thank you very much!
Those are very informative classes considering the Jinke classes have no javadoc attached, so all one can do is guess and test.
I'll do some tests on my bebook and see if I can figure it out.

Thanks again!

[Tumaini]

Here's a small update.
I've managed to run some test classes on the V3, writing some text to the screen, but I'm stuck at some very strange behaviour regarding key events.

In your HelloWindow.java class you have the following code:

class HelloWindowKeyAdapter extends KeyAdapter {
		public void keyPressed(KeyEvent keyevent) {
			// led.resume();

			if (keyevent.getCh() == KeyEvent.KEY_CANCEL)
				System.exit(0);

			if (keyevent.getCh() == KeyEvent.KEY_OK)
				runLua();

			// led.resume();
		}
	}

This throws a java.lang.VerifyError when I try to run it on the V3.
I've tried different methods to see what might be wrong.

I was able to print out both the char and respective int from keyevent.getCh() to the screen, so there's no error there.

I've even tested different if-statements without keyevent.getCh() and they work fine. I only get the error when I use if and keyevent.getCh() (or the instance variable ch) together.

Have you got any insights into this or any clues as to why it might throw this error here?

[wiffel]

Originally Posted by Tumaini

Here's a small update.
I've managed to run some test classes on the V3, writing some text to the screen, but I'm stuck at some very strange behaviour regarding key events.

In your HelloWindow.java class you have the following code:

class HelloWindowKeyAdapter extends KeyAdapter {
		public void keyPressed(KeyEvent keyevent) {
			// led.resume();

			if (keyevent.getCh() == KeyEvent.KEY_CANCEL)
				System.exit(0);

			if (keyevent.getCh() == KeyEvent.KEY_OK)
				runLua();

			// led.resume();
		}
	}

This throws a java.lang.VerifyError when I try to run it on the V3.
I've tried different methods to see what might be wrong.

I was able to print out both the char and respective int from keyevent.getCh() to the screen, so there's no error there.

I've even tested different if-statements without keyevent.getCh() and they work fine. I only get the error when I use if and keyevent.getCh() (or the instance variable ch) together.

Have you got any insights into this or any clues as to why it might throw this error here?

I'm not quite sure what is causing the error. My first guess would be that the classes.jar (or more correctly the KeyEvent class in the classes.jar) has been changed. I guess that would throw a VerifyError. On the other hand, this would throw an error even before your code would be executed. So, strange thing indeed. Is the error only thrown when the KeyEvent class is being accessed?

When I did this kind of development, I did compile and run my code against a 'normal' JME first. That way I could resolve most of the 'normal' bugs first. Did you try your code like that already ?

I'm a bit in a hectic time at work right now. But if I find some time tomorrow, I'll have a look at the new classes.jar in the current firmware (by the way, which one are you using?) If I manage to do so, I'll post the new one. At the least you would be sure that the problems are not caused by that.

[Tumaini]

The error is strangely only thrown when I access char from the KeyEvent argument in the keyPressed method in an if-statement.
If I access it in other ways, like gc.drawString(keyevent.getCh(), 50, 50), it doesn't throw this error.

It could very well be that the classes.jar is the problem, since I'm using the one you supplied when writing the code. I'm not quite sure how to access the root of the reader from Windows over USB and I haven't installed a Linux OS on this machine yet (though I think it'll be easier to do in Linux).

I've been using a normal Java SE 1.4 for these tests, but this has been the only problem yet. Was planning on switching to ME soon, but haven't gotten around to it yet, due to limited time to dedicate to the matter.

Thanks again for all your help!

[wiffel]

Tumaini,

I managed to get the 'new' classes.zip from the new firmware. And there is a difference between this one and the one that was in the one I posted. If you're lucky, this is what caused the errors.

You can find the new classes.zip attached to this post.

Good Luck,

Wilfried

[wiffel]

By the way ... a somehow unrelated topic, but you could be interested.

Since it is very difficult to program for the Hanlin device (or the other ebook devices), I started with a port of the LUA (http://www.lua.org/) virtual machine to the Hanlin device (but also the PocketBook, windows, mac osx and linux).

It's not Java, but a language that (in my view) has proven it's place. Anyway, I don't want to launch yet another language war ...

I did make a 'fat' binary that includes :

- the lua vm

- a binding to GD (http://www.libgd.org/) using Lua-GD (http://lua-gd.luaforge.net/) including the freetype font support and PNG support. The screen is represented as a GD image. This way all of the functions supported by Lua-GD can be used to draw onto the screen. (But the 'normal' functions are still supported, so e.g. one can read and write PNG images)

- a binding to key events, mouse events (not very usefull on the Hanlin), timer events, ...

- a binding to sockets using LuaSocket (http://www.tecgraf.puc-rio.br/~diego...nal/luasocket/) to be able to use networking. Also not very usefull for the Hanlin (but very nice to use on the PocketBook) besides some supporting function in the mime part of LuaSocket (http://www.tecgraf.puc-rio.br/~diego...cket/mime.html)

Just to make a difference between the normal Lua VM and this 'fat binary', I do call this one "eblua". By now I managed to create a first version of "eblua" for the 5 platforms mentioned above. Lua scripts written against "eblua" run identical on the 5 platforms. That should make it a bit easier to write simple applications that also run on ebook devices.

It's still very early stage. I still need to do a lot of clean-up stuff and unify some things for the multiple platforms (e.g. screen sizes, key-codes, available fonts, ...). But maybe a brave developer (like you) is willing to give it a try.

Just as a try-out I did write a version of 'tetris'. It's not the best application to run on devices with eInk screens, but I needed some application as a test vehicle.

Enclosed is a zip-file that includes three files. 'eblua.exe.fb2' is the fat binary. 'eblua.lua' is an initialization script that is run every time the VM is started. 'app.lua' is the actual application (in this case the tetris application). It's a text-file, so it's freely changeable. This is how 'new' applications can be written.

I'm still contemplating about the actual packaging of applications. For the moment the paths to the multiple files ar hard-coded ("/mnt/eblua/" which is an eblua directory on the SD card). Also the application to run is hard-coded: 'app.lua'. This will most probably change in the future. Hence, to run the application all three files should reside in an 'eblua' directory on the SD card. The application is launched by opening the 'eblua.exe.fb2'.

Feel free to try it out, or to completely neglect it :-)

Good Luck with the Java app,
Wilfried

[propylen]

Hi guys! I had decompiled classes.zip and it is promising. Check out my research.(Attachment).

EDIT:
OK, sorry I removed copyrighted material. In attach only javadoc - no code, also examples coded by me. It's not much, but should be enough for simple midlets.

If you want something more advanced, you will have to decompile /root/java/classes.zip, also /root/java/jinke.jar may be useful for api calls.

[Alexander Turcic]

propylen, I believe the archive file you posted contains copyright protected code (disassembled Mobipocket class?). If this is the case, we cannot have it posted here. Thank you.

Alex
Moderator