Den 22.04.2010 11:16, skrev ext [email protected]:
> Does anyone know for sure how much classes Jambi uses that aren’t included in
> Java ME? We don’t need GUI classes, but I really doubt about it having all
> core classes either... From what I know about, it is really tiny.
>
> Remember, that Jambi needs atleast Java 1.5, with current source it may even
> be 1.6, but that could be easily fixed... Nothing below that wouldn’t work,
> Jambi has written for Java 1.5 originally.
>
>
I did some POC work a couple of years ago to port Qt Jambi to CDC 1.1
Foundation Profile so it could be run on Nokia N800.
I thought it would be interesting to share some general pointers from
this work. In no particular order:
1. JNI on the embedded virtual machines tends to be less lenient with
regards to programming errors. For instance, if you use the JNI function
CallVoidFunction() to call a function which actually returns a value on
desktop Java, the return value will simply be discarded silently. On the
embedded VMs that we tried, the application would crash. There might
still be some bugs of this type in Qt Jambi that we didn't catch, so
keep an eye open for this.
2. Another possible source of error is: qreals will be 32-bit floats on
most embedded hardware, while there might be code in Qt Jambi which
assumes it's 64 bit precision.
3. Related to the previous one: If you want the Java APIs on desktop and
embedded to be identical, you need to make sure that qreal is always
mapped to a 64-bit double in the Java API, even if it's resolved to
32-bit float internally. Since the C++ code will still be float-based,
the values will be truncated when passed into the JNI code, but we opted
for this in the research work because we favored having a consistent API
across platforms.
4. When we did this work, the maximum JNI version supported by the CDC
VMs was JNI 1.2, so we have to request this version of the API in
JNI_OnLoad() and fix any usage of JNI functions which are newer than
this (shouldn't be too many, but I think e.g.
AttachCurrentThreadAsDaemon() is one.)
5. Qt Jambi is highly dependent on Java 1.5 syntax. Most of this can be
fixed using the following application and running it over the compiled
.class-files:
http://retrotranslator.sourceforge.net/
However, the translator doesn't fix all usages of API, so in some
places you will have to rewrite references to 1.5 API as well, such as
e.g. calls to the method String.contains(). I went through and replaced
all instances of this with String.indexOf() instead. There is a bunch of
stuff like this which will just have to be handled on a case-by-case
basis, most of which were easy to replace with older API. I also had to
implement some APIs myself to replace the missing ones, like
String.replace() and String.split().
6. Another big job which had to be done is to fix the library loader. I
refactored this into a plugin-like architecture, so that you had a
default library loader which simply searched for the files directly on
the library path. The more complex library loader, which loads libraries
from inside .jar-files and does all that magic, was then made optional,
and could easily be excluded from the build on CDC. The reason for this
is that it relies heavily on XML, and the XML packages are not part of
the CDC profile that we were using.
In addition to these caveats, the problem you're likely to face is
memory consumption. Specifically, the Qt Jambi libraries are huge and
will consume a big chunk of the available memory on many devices. The
main problem is that every single function in Qt has an equivalent
function in Qt Jambi with a huge function name. This function name is
listed in the symbol table of the binaries. The code itself is small
compared to the size of this symbol table. Enabling jump tables in the
generated code (call the generator with the undocumented argument
--native-jump-tables) and then stripping the binaries of all
non-exported symbols, makes a huge difference. Note that the jump-table
feature was considered experimental, so I don't know what state it is
in. What it basically does is try to group together functions with the
same signature into a single exported JNI function which internally will
redirect the calls to the correct place based on a selector index. If
that isn't enough, it should be simple to do similar optimizations and
get the size down substantially, since the generated code is high in
boiler plate.
I hope this gives you guys a head start on the project. Good luck! I'm
sure it will be both frustrating and interesting :-)
-- Eskil
_______________________________________________
Qt-jambi-interest mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
