The LWUIT home page now reflects the open sourcing of LWUIT today and Terrence is also blogging about this. Today we are finally switching to the java.net SVN repository for all development which means changes to LWUIT will be made live within that repository.What does that mean to you?
We no longer need to tell you that a fix will be available in the next drop, we can commit to the SVN to deliver fixes for issues discovered by the community.
You can now contribute code to the project using the incubator project but make sure to sign the SCA before applying for a role.
Drops probably won't be as frequent as before since they won't be as essential for bug fix deliveries. We would expect more detailed bug reports from the community though ;-)
The license we picked is the GPL+Classpath Exception which allows binary linking with the application (unlike the LGPL) thus allowing you to build and obfuscate your own proprietary applications. We still intend to offer binary drops under the current binary license to give you a choice between two licenses and ease your interaction with the legal department in your respective corporation (note that the binary license only applies to the binary drops!).
The current source code is a snapshot in time, development has been ongoing with many new features available in the current source code that weren't previously available in a drop. To bring all things into line we are also publishing a new drop with updated release notes etc.
Main features of the new drop/source code include the following:
- Live drag and drop support for components in layouts
- Component z-ordering support
- New absolute/scalable layout allowing arbitrary positioning
- SVG Image support using JSR 226 - SVG Images can be loaded and applied to any component
- 3D transitions are now possible for all components including dialogs and arbitrary components
- Performance improvements: Added the ability to repaint a dirty rectangle within a Component
- Added support for glass pane allowing a painter/painter chain to draw on top of the current component very efficiently.
- Fix for issue of layering modal dialogs one on top of the other
Please look to the release notes for further details of what has changed.
17 comments:
Does this mean we finally get to see the LWUIT.jar for CDC/PBP devices?
Or are you leaving that implementation to the community?
While the community can start working on a CDC port we already have a functional port of our own. Getting it out the door (in binary or source form) is a different matter altogether and one in which I have no say whatsoever (priorities for LWUIT).
I hope we will be able to release that too as well as the resource editor source code and some other things we have (the LWUIT Matisse source code, the Ant task, the many demos we have etc...).
Shouldn't we just wait for JavaFX to run on mobiles?
First off, feel free to wait no one is stopping you from doing that...
Disclaimer: This is purely my opinion and not Sun's official stance in any way!
LWUIT Differs from Java FX in almost every possible way:
1. JavaFX is more of a vector graphics platform. LWUIT is a scene graph component model framework like Swing.
2. Since LWUIT is a component model framework it can feature things like themeing etc. which are not the use case for Java FX.
3. LWUIT is targeted at Java Swing/MIDP developers. FX is targeted at the general public and script developers.
4. LWUIT requires MIDP 2.0+CLDC 1.1. FX Mobile will probably require SVG for its vector graphics implementation which means only the newest phones would be supported.
If you need to do a vector graphics based application, you can either do it using JSR 226 today (with or without LWUIT) or wait for Java FX. If you want to write a component based application then Java FX might be useful although LWUIT will probably be simpler to use for that (although we don't really know what FX mobile will offer in its final version).
First off, this is cool, thanks a lot to you folks and to Sun.
When you say "we picked [..] GPL+Classpath Exception which allows binary linking with the application (unlike the LGPL) thus allowing you to build and obfuscate your own proprietary applications" what exactly does this mean in the context of MIDP, where everything is packaged in a single jar and there are no separate modules?
Even if when using IDE tools in Eclipse like EclipseME that make it "feel like" you're linking to a separate jar, we know that's actually IDE automagical convenience for configuring the build path -- for MIDP what's happening under the covers during build is that the toolchain is unpackaging everything out of any linked jars and putting it all into a single MIDlet jar that you distribute as one module. That's a bit different from other Classpath Exception scenarios where there's a clearer sense of "libraries" and "modules". My non-lawyer understanding of the GPL was that most of its provisions were invoked by the actual nature of the distribution of the work.
Can you clarify Sun's intentions a bit more with respect to the Classpath Exception and LWUIT? Is the intent that the Classpath Exception will apply more to source packages rather than literally jar libraries as distributed?
Hi Michael,
this is more of Terrence's domain than mine but I will try to shed my understanding with the caveate that I am neither a lawyer nor a Sun employee (contractor technically).
We anticipated such confusion which is why both Terrence and myself tried to be very clear in specifying that proprietary applications can be packaged with LWUIT.
The way I see this (and I am not a lawyer) there is no linking going on here since Java is dynamically linked (obfuscation doesn't link it just jumbles and removes some stuff). Some don't agree with this interpretation but since Sun has specifically stated that particular interpretation for this particular case I would say anyone can accept that...
Having said that... Assuming your lawyers are giving you hell over this particular license (a problem I'm sadly very familiar with). We offer another option, we allow you to download the binaries and then use the more "lawyer friendly" SLA binary license. This license only applies to our binary and so is only useful for changes going into the LWUIT trunk, since the code is mostly for insurance and debugging lawyers shouldn't bother you there.
Shai, thanks for the answer. It's good enough for me if I just get a clear sense of Sun's intention about this, which is what your post helps with.
If what you're saying is that Sun is cool with people downloading LWUIT source, building apps with it, keeping their own rights to their own code, but making sure that any fixes, changes, additions, etc. to the LWUIT packages are contributed back to the community, then this is fine. I guess it's almost like we're considering the Java .class files to be the "modules" in this case.
Have I understood correctly?
You understood perfectly. Our goal all along was to allow content/Java developers to use the library freely whether for proprietary or open source projects without being bothered by licensing.
However, to avoid LWUIT forks along the rode we want all changes to LWUIT to be contributed back. According to the GPL you can just publish the source in the web site, but technically its pretty easy to sign the SCA and place your changes in the lwuit-incubator project.
Thanks a lot Shai, this makes a lot of sense.
Given that as you mentioned, you don't speak for Sun, it would be great to hear Terrence confirm this as an authorized representative of Sun. I've posted a question over on his blog too:
http://weblogs.java.net/blog/terrencebarr/archive/2008/08/lwuit_released_1.html
That aside, this makes me a very happy camper...
I develop a simple mobile applicaiton using new LWUIT tool kit version. In that I perfoms RMS related operations. The application performance is very very slow. That is, the events are working slowly. If we perform any command action, it takes lot of time to show dialog response
How to dispose the Form object which is added to Display / Container ?
We developed a simple mobile application using new version of LWUIT. Jar(LWUIT_20081222). Overall performance of application
is very slow, we took maximum care in designing application like using threads etc, now we doubt the reason for bad
performance is unable to dispose Forms (Form objects) which are created and no longer required, let us know how to dispose
forms added to Display, or give us know your valuable suggestion on improving application performance especially LWUIT based
application.
You overused threads in your application from the little I saw. Compare your code to makeover or the LWUIT Demo and read the developer guide/performance guidelines.
Can u pls, tell me------
How to dispose the LWUIT Form form LWUIT Container?
Pls, give me ur valuable suggestion-------------
Hello
i have the same problem. When i change the new release(20081222) lib, the performance of application is fine in the simulator. But it works very very slow when i put the program to mobile phone. i use the old release(20080814), the performance is fine. i have try running the LWUIT Demo for check if my applicaton problem. the Demo is still running slow in mobile phone when use new release. i dont know why use the old release is fine, but use the new release the performance is slow. Dose anyone have the same problem???
I have some problems with the Dicember LWUIT version too. My application doesn't manage to dispose a form when another one is called to be shown. It seems that the second form remain behind the old one. With the previous lib version I hadn't no problems.
Post a Comment