[jsword-devel] jsword on j2me

[Kobus Grobler]

DM Smith wrote:
> Kobus,
>     I am excited about the prospect of a j2me version of JSword!
>
> Kobus Grobler wrote:
>   
>> Greetings.
>>
>> I've been thinking about implementing a mobile version of jsword for a 
>> while now and have concluded that there's not much (if any) of the 
>> current jsword libraries that can be used on mobile devices. This 
>> means it has to be implemented almost from scratch. I have a lot of 
>> experience on the j2me platform, but cannot do this on my own, so I 
>> would like to know if a few other people would like to commit to time 
>> to this so I don't start something that will not be completed. I 
>> really think a mobile version with a few "special" features will be of 
>> help to our brothers that live in countries where access to a bible is 
>> still an issue (but not to a cellphone...). So internationalization 
>> should be a priority.
>>
>>     
> J2ME has been on our wish list for years, but there has always been so 
> much to do in rounding out the JSword implementation of the Sword API. 
> We have almost completed that task.
>
> The other thing that has held me back is that I have no experience with 
> j2me. So, I have focused on what I do most effectively.
>
>  From a J2ME perspective only the common.jar and jsword.jar are of any 
> interest. And only a subset of common would be used. There is a lot in 
> there that would not pertain to a J2ME environment. Obviously, 
> common-swing.jar and bibledesktop.jar are out. A new UI would have to be 
> created.
>
> I'm concerned by the "not much (if any) of the current jsword libraries 
> that can be used" statement. Could you help me understand this? Should 
> we target 1.0 or 1.1? What are the pros and cons?
>   
You have to understand from the outset that you are working with very 
resource limited devices. So just targeting an old version of j2se is 
just not going to cut it. Limited memory is usually a very real issue. 
CPU in for our target probably not as much an issue if designed 
correctly.Think < 1MB to cover most devices, although newer phones have 
about 6-8MB of which you can obviously use only a few MB.

J2ME/MIDP has no File class. Some of the newer phones does have an 
optional "FileConnector" api which allows you some access the file 
system, but its based on a different set of apis than what you have in J2SE.
Lucene won't work, which is as far as I can see a library that's used 
fairly extensively.
As for a collections, you have Vector an Hashtable is standard, the rest 
you have to port if needed, but even then you still have the cpu/memory 
constraints. You don't have ResourceBundle either.

Lets just say that you have to design for a mobile device from the 
ground up. It also probably won't be practical to have more than one 
translation on any  particular device, so probably best to pre-create 
indexes and provide a prebuild jar for every translation of the bible.

XML is possible on J2ME/MIDP with some 3d part xml parsers, but will 
only add extra overhead. Best to pre-parse into some efficient binary 
format,ship as resource with jar and then use Class.getResourceAsStream().
Remember you don't have files as such on j2me.

FYI here is the link to the j2me/midp api which is what most devices 
support [http://java.sun.com/javame/reference/apis/jsr118/].

Of interest is javax.microedtion.rms and java.util to give you an idea 
of the api limitations you have to work with.


> My guess is that J2ME does not have a robust collections framework. Is 
> it possible for us to use a collections framework (say GNU or homegrown) 
> to bridge the gap?
>
> If at all possible, I'd like for a core jsword implementation to be 
> useable on all platforms/devices. That is, I'd rather not duplicate 
> behavior. I'd rather evolve the code than create a parallel implementation.
>
> The most critical packages will be o.c.j == org.crosswire.jsword
>     o.c.j.book (Interface code)
>     o.c.j.book.basic (Abstraction code)
>     o.c.j.book.sword (Implementation code)
>     o.c.j.filter (Interface code)
>     o.c.j.filter.*
>     o.c.j.versification (KJV versification code)
>     o.c.j.passage (Interface, abstraction and implementation code)
>
> The core architecture of JSword is its xml handling of sword modules. 
> Does J2ME allow for xml and xslt?
>
>   
>> A few questions:
>>
>> 1)Has anybody else started/experimented with this?
>>     
>
> Yes. Zhoujun has expressed interest in eRCP as a j2me implementation. 
> eRCP is in alignment with some of the other things that we want to do.
>
>   
Sorry, is eRCP eclipse RCP? SWT is not possible at all on J2ME devices.

>> 2)Can we use the "incubator" repo?
>>     
>
> Yes. You have write permissions to there (as does everyone else). I'd 
> suggest creating a directory "eRCP" and under that create your directory 
> tree.
>
>   
Thanks.
>> 3)Would anybody else be interested in helping (especially with 
>> internationalization)?
>>     
>
> I can provide guidance as to how to understand the code. My approach to 
> internationalization is to create a framework and allow people to 
> translate it as they see fit. Currently we have a German and a Farsi 
> effort underway to translate BibleDesktop.
>
> We already have i18n Bible book names in about 30 languages.
>   
Ok, well I don't have access to a phone that supports the Asian 
character sets, so I hope it will just automagicaly render unicode 
correctly. I'll need some help there.

Anyhow, I'm sure it can and has been done.

Kind Regards

Kobus

> In His Service,
>     DM Smith
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3371 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.crosswire.org/pipermail/jsword-devel/attachments/20061217/4216b199/attachment.bin