Skip to main content

Getting More Involved in Projects

Please note these forums are being decommissioned and use the new and improved forums at
6 replies [Last post]
799 Guest
Joined: 2012-03-14

"If you want to get more involved in the project, start connecting with
other members of the project in that project's forums or mailing lists,
and get to know how the project is being worked or managed. Once you
get to know everyone, try asking one of the project administrators for
a higher role in the project like Software Developer or Content

Hi, I would like a folder in trunk where I can contribute to please. My
aim is to add precompilation directives to the project to bring the jar
size down.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2010-03-15

I have some changes and minor bug fixes as well, but I had hard time reaching any projects administrators.

It seems most of the active developers have switched to working on codenameone.

Since LWUIT is open-source you can always release your changes through your site.

Joined: 2012-03-14

What is codenameone?

My first intention is to contribute through the incubator

project. if no one responds to my email then yes my second option is

to make a branch in bitbucket or github or something.

I'll let you know if I go for option 2 cause im interested in your

fixes. I live in South Africa, and J2ME in africa is still huge.

thanks and cheers

Joined: 2012-03-14

Ok just saw what codenameone is. checking it out now ;)

Ok so codenameone is basically lwuit 2. Why do we bother then to use lwuit 1?

Joined: 2010-03-15

In my case I have legacy code that used LWUIT and was written before CodenameOne appeared.

CodenameOne still seems to have a few issues, but I will switch eventually.

Joined: 2012-03-14

I have created a copy of lwuit trunk at

I will be working on that trunk for the next few months to:

1. add pre-processing directives
2. add a library which you use to build lwuit screens. The benefit of this is that the screens will be specified by a remote server, the library parses the data and build lwuit screens. These screens will support interaction that talks back to the server.

Please feel free to contribute.

Joined: 2009-09-04


1) about preprocessing - I use jour ( for this purpose, it allows me to define functions which return true or false, and they are resolved at building time (not at runtime), so proguard can shrink not used code. It's much better than preprocessing because source code remains valid Java.

2) About library to build LWUIT screens - I also use approach like that in my apps, to send screens definitions (in XML or binary formats) to client and build screens at run-time. By the way LWUIT has an HTML browser and probably it could be used instead. Also I know that now LWUIT has a screen builder from resource file, which also could be used instead of building another LWUIT screen builder.
I used XML to define screens, with some very basic functionality to define transitions between screens. And I would say that my approach lacks 'scripting' features (to use templates for screens, put data to screen and back to code - probably you also addressed these issues in your code). I think that it would be better to use Scheme language to define both screens and scripting. Scheme is a rather lightweight language, there's an implementation even for microcontrollers and it works within 32k of RAM (BIT Scheme Scheme code is compiled to byte code (for Scheme VM), and it can be loaded to client at run-time, to be used as 'screen definition language'. I ported BIT to java, and could contribute this code. But generally it sounds like a crazy idea, I agree. I didn't success to implement it, used a plain approach with defining screens in XML instead.

Why do you plan to use LWUIT code as basis, instead of codenameone? LWUIT is dead, since authors forked it to a new project. It would better contribute to codenameone, I think.

It would be interesting to look at your implementation of the screen library. Mine (with XML) is not good designed, so I will never show it to public ))