Skip to main content

Open Source SWING Native Look And Feels

3 replies [Last post]
ekartzma
Offline
Joined: 2003-06-17
Points: 0

There is no danger in open sourcing the native look and feels. The various platforms look and behave a particular way so there are no potential forking decisions to be made in those packages. Let the community catch and fix inconsistencies with the native platforms for faster turnaround times with less Sun resources being devoted to it.

I think all you need to do is to come up with a licensing policy that allows you to redistribute the open source libraries with the Java runtime without it also becoming open source. And I believe even the existing LGPL would allow for that.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
bjb
Offline
Joined: 2003-06-12
Points: 0

IMHO, it should be Swing that should be LGPLed !

So the Swing framework could evolve on his own, and Sun will qualify Swing release to be part of the J2SE platform thru the regular unit test kit.

There is no threats I can see with Swing beeing LGPLed. But the one to see it drastically improve and regain the momentum it has lost.

Please realy consider this one ASAP.

ekartzma
Offline
Joined: 2003-06-17
Points: 0

I am for anything that advances Swing's marketshare. I can only guess at why Sun hasn't open sourced Swing already, but I had heard in the past that Swing was to be an 80% solution to prevent bloat. If they open source all of Swing, I am not sure how the unit test kit would prevent that bloating. Of course I may have heard wrong about the 80% rule on this or it may no longer be a concern of Sun.

I presented the native L&F option because I couldn't think of ANY reason to hold that back whereas, valid or not, I could hypothesize a Sun objection to open sourcing all of Swing.

zander
Offline
Joined: 2003-06-13
Points: 0

The best reason against open sourcing Swing is probably that Sun is pretty well aware that Swing has some very basic problems in its API.
In order to make it workable and long-term viable 2 days after an open source release was made a source-incompatible version would start to be worked on to fix API problems.

This would entail simple things like javax.swing.filechooser.FileFilter starting to implement java.io.FileFilter
but also creating an interface that would allow JMenu and JPopup to be populated similarly (addSeparator() etc)
And naturally simple things like a component does have a getParent(), I would like to have a getChildren(), not a getComponents()

Naturally these reasons alone are very good reasons to release Swing under the Apache licence; this license disallows others to fork and still keep the name Swing.