Skip to main content

Add good open source layout mangers into JDK

13 replies [Last post]
xhq
Offline
Joined: 2003-06-15
Points: 0

Reply viewing options

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

> The most radical of my ideas is to remove Generics. I
> didn't think this way 6 months back.
>
That's not very radical at all. While I like the ability to force a Collection to accept only specific types I wouldn't miss them.

I'd go a LOT further. Remove all "enhancements" introduced in Tiger except the performance improvement.
Remove Swing, JDBC, AWT, maybe XML.
Logging, security API, regexp, crypto, graphics, all should be optional packages.

Effectively reduce the core API back to what it was in 1.2 (with some of the enhancements from 1.3 and 1.4 like assertions and performance).

cowwoc
Offline
Joined: 2003-08-24
Points: 0

I think if you remove all of that, you'll end up with something equivilent to J2ME -- which is not suited for desktop or server development.

To me, J2SE is the client/server desktop platform -- the middle ground. So I would take all functionality absolutely required on this domain and pack it into J2SE. I wouldn't, for example, remove AWT/Swing or the Security API but maybe the others could become optional. These are all vital for deployment's sake. Although maybe it is reasonable to modularize AWT/Swing further and only include a smaller subset in J2SE.

Anyway, if you want to continue this discussion, we have to take it into another forum section or topic and not hijack this one :)

markf
Offline
Joined: 2005-01-20
Points: 0

Testify!

GridBagLayout is, well, really bad. It should have been TableLayout;
http://www.clearthought.info/software/TableLayout/

Hint hint, Sun. It's not to late to abort your mistake.

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

There are several quite good layout managers available besides the ones that Sun ships. Just about all the authors (including the author from TableLayout) have said they want to keep their layout manager outside of the core.
This should not be a problem since many are free and some (like NaturalLayout) can even be shipped with your application without any problems or attribution.

See: http://wiki.java.net/bin/view/Javadesktop/3thParty

clearthought
Offline
Joined: 2005-05-19
Points: 0

Actually, TableLayout is trying to get into the JDK. Check it out at https://tablelayout.dev.java.net/. You can even petition to get it into the JDK at https://tablelayout.dev.java.net/servlets/ForumMessageList?forumID=1535

jwenting
Offline
Joined: 2003-12-02
Points: 0

ah, add MORE MORE MORE!
After all, anything that's not at least 500MB downloaded and over a gigabyte installed is utterly useless!

Add every single thing ever released as an addon to Java NOW and forever, after all if it weren't useful someone wouldn't have released it!

cowwoc
Offline
Joined: 2003-08-24
Points: 0

For the love of god people! :) Nothing except deployment components should go into the JDK! There is absolutely no benefit to bundling this kind of stuff as part of the JDK if applications can ship with it as a dependency.

That is, either the application bundles it or the signals the dependency to the JDK and the JDK goes out and gets it if necessary. Look at Webstart for an example of what I mean.

I'm beginning to make a list of things I would *take out* of the JDK nowadays... a few years back I used to think like you... what a mess :) what a mess :)

Gili

jwenting
Offline
Joined: 2003-12-02
Points: 0

Want to work together on that list Gili?
I've some ideas about it myself, though they may be more radical than yours ;)

cowwoc
Offline
Joined: 2003-08-24
Points: 0

The most radical of my ideas is to remove Generics. I didn't think this way 6 months back.

My problem with Generics is the same as operator overloading. I just think this is one of those cases where Sun should selectively include Generics classes or operator overloading for specific instances/API calls and not allow end-users to create their own. Then, eventually when we find a good formula that works we might want to allow the end-user to do it -- but not before.

The reason I feel this way is that I found out the hard way a few months back that Generics were great for extremely simple things but very quickly as your use-case got more complex they lead to more pain than gain.

Adding Generics to the standards collections makes a lot of sense. I'd keep it. But I'd still opt for not allowing end-users to create their own. Maximum gain with minimum loss.

BTW: Sun is full of very intelligent people who did their best with Generics. I'm not trying to criticize them. I'm just saying that in my opinion "we're not there yet".

Gili

alexlamsl
Offline
Joined: 2004-09-02
Points: 0

I do understand your ideals about keeping a certain language platform compact hence maximising the ease of learning and deployment etc.

However, what I would like to say is that this is a forum section which welcomes collects the general community's ideas and suggestions. Although it is trivial that not every single suggestion would get itself into the Java Language Platform, it is equally vital to let these ideas flow around and let others to argue back and forth so as to decide whether they are actually worth their values.

Having said that, the idea about not including most of the additional features in Java is indeed itself a valid idea to be expressed against the platform - but as for people who like "Multiple Return Values" would not start putting their ideas across in other threads like "Image Acquisition API", "Extended Switch Statements" etc., it would be nice if you can open your own thread (which all users are authorised to do so) and express your more general arguments and ideas in there.

In short, it would be nice if we only express specific arguments (for / against) to the very feature(s) that is under question in the respective threads. ;)

cowwoc
Offline
Joined: 2003-08-24
Points: 0

heh, that's the first time I've been labeled a "Purist" :)

Your point is well taken though and I guess my reply to this suggestion is: introducing new mature layout managers into the J2SE is not necessarily a bad idea, so long as there is no feeling of overlap between all of them. There should be a distinct use-case for each layout manager. Deprecating GridBagLayout in favour of a new layout manager that replaces it is fine, so long as you remember to deprecate.

fsickert
Offline
Joined: 2004-03-18
Points: 0

What's wrong with talking about things that could be added to Mustang ? And why hasn't GridBagLayout been deprecated for extremely bad api usability ?

xhq
Offline
Joined: 2003-06-15
Points: 0

Sorry. Now I realized that I was talking right things in right place. :)

I posted it to www.javadesktop.org:
http://www.javadesktop.org/forums/thread.jspa?threadID=6745&messageID=44875

Changing the title back so someone can notice it.