Please refer to:
Message was edited by: xhq
> 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).
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 :)
GridBagLayout is, well, really bad. It should have been TableLayout;
Hint hint, Sun. It's not to late to abort your mistake.
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.
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
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!
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 :)
Want to work together on that list Gili?
I've some ideas about it myself, though they may be more radical than yours ;)
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".
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. ;)
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.
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 ?
Sorry. Now I realized that I was talking right things in right place. :)
I posted it to www.javadesktop.org:
Changing the title back so someone can notice it.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.