[jsword-devel] jsword on j2me

[DM Smith]

On Dec 17, 2006, at 2:04 PM, Kobus Grobler wrote:

> 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.

If I understand you correctly: The 1MB limit is the storage limit of  
the device, probably flash.
With regard to the code size of the parts of JSword and Common that  
have any meaning on a "small" device, this should not be a problem.

>
> 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.

I thought so, but I wasn't sure.

> Lucene won't work, which is as far as I can see a library that's  
> used fairly extensively.

In the list of core packages, I didn't include o.c.j.search.lucene  
because it will never be targeted toward small devices. If search is  
supplied, then o.c.j.search provides the interface.

I also did not mention o.c.j.install, because I figured that a  
different install mechanism would be needed than what we have  
implemented. However, o.c.j provides a good interface.

> 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.

And I think I heard that it does not have Properties as well. I am  
curious how internationalization is approached as the J2SE approach  
is Resource Bundles.

>
> 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.


I think it will be important to keep an authoritative bridge to the  
Sword modules, perhaps by creating an importer that can convert a  
Sword module into the format necessary for a J2ME implementation.  
This should be fairly easy given that JSword can read Sword modules.  
(Almost done with GenBook support).


>
> 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.

I guess I should have given a bit more info. eRCP is short for  
"Embedded Rich Client Platform" and is the Eclipse effort to create a  
j2me implementation of RCP.

There is a similar, related effort for eSWT and eJFace.

See http://www.eclipse.org/ercp/ for more details.

There is also a J2ME plugin EclipseME that allows J2ME development  
within Eclipse.

I imagine that eRCP/eSWT/eJFace may have a substantial foot print.

Again, I am in over my head with all of this. So I appreciate you  
filling me in and taking this on.

>
>>> 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.

Troy has just ported FlashCards to j2me (see: www.crosswire.org/fc ).  
He found that Hebrew is not supported. He had to resort to using  
images to get get it to look right. It may have been that it was just  
quicker for him to do that than figure out the font issue. I don't  
know. Perhaps, he'll chime in.