IMO the new features are indeed useful (or can be) in that they may speed up coding and reduce hard to track down bugs (especially with generics being used to enforce the content of collections).
The main bloat in Java these days is with the massive amount of "standard optional" packages that might be better off as separate installations. I'm thinking of things like XML and graphics support which used at some point to be optional installations for people that needed them but now are included as standard. Especially with XML support where people that use it usually install a 3rd party XML package like Xerces and possibly Xalan as well all this does is increase the installation size for you and your users with little advantage. Swing is not used by the majority of users who concentrate on serverside and web application development. It's another several megs on our harddrives that never gets loaded.
This sounds as though it could become a discussion on the merits or otherwise of including so many packages as part of the core Java installation. For what it's worth my opinion is that those few extra megs on my hard drive (which are quite cheap now) are worth it for the gain of having so much as a coherent whole. When packages are optional extensions it seems (perhaps just a psychological effect) more difficult to get a handle on what "the Java language" actually is. This is perhaps due to the tendency of authors to focus either on the core language or one or more optional packages, so making it quite difficult for newcomers to know what to focus on, and where to find information.
posted 15 years ago
I agree that with storage so cheap it doesn't make sense to have packages be optional just to save space...
I'm more curious about whether the features being added truly add value to the language, or do they just add more complexity...I'm only beginning to scratch the surface with 1.5 so I don't know enough yet to have an educated opinion...but I'd like to hear what the author and others have to say on the subject.
After working with many of the features for well over a year, I like it! In general, the new features make coding simpler and more expressive. In most cases, I don't think it produces code bloat or complexity bloat. The only exception is with respect to designing parameterized types--that can get a bit confusing, but most developers won't be doing that very often.
Another pretty good question -- it's certainly true, at least in my opinion, that Java (and in particular, J2SE) is getting a lot "bigger", and that some of these additions are questionable.
In terms of Java 5 specifically, I think it's a bit of both. For example, I think that enums and generics are welcome additions (although I don't agree with some of the implementation specifics; but that's another topic). However, there are other things that I think probably would be best served by a little more work. Annotations, for example, strike me as a great idea, but I think the way they work in Tiger is a little flaky, and immature. But again, that's not really a superfluous feature; it's just one that isn't done as well as it could be.
As for purely bloat, you could argue that something like for/in or import static is that, based on how you look at convenience features. That's what both are -- just niceties to make some (not that) common tasks easier. I've had my share of vi and Hungarian notation, so convenience isn't worth as much as it once was, but those are still ... well ... convenient.
So I guess I'd say that there is a little bit of stuff in Tiger that I might not have put in, but not a ton. I'm pretty pleased with the new release (although annoyed that my options on my trust Mac OS X are so limited).
Series Editor, Head First<br />Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0596102259/newinstance-20" target="_blank" rel="nofollow">Head Rush Ajax</a> and <a href="http://www.amazon.com/Head-First-Object-Oriented-Analysis-Design/dp/0596008678/ref=pd_bbs_sr_1/104-5348268-5670331?ie=UTF8&s=books&qid=1192568453&sr=8-1/newInstance-20" target="_blank" rel="nofollow">Head First OOA&D</a>
Originally posted by Brett McLaughlin: Annotations, for example, strike me as a great idea, but I think the way they work in Tiger is a little flaky, and immature. But again, that's not really a superfluous feature; it's just one that isn't done as well as it could be.
I looked at the article on annotations and have an idea now. Would annotations be used to generate code like xdoclet?. So would xdoclet go ahead and define standard annotations that we can use to annotate our code instead of their @ejb-bean kind of tags?
So would I be correct in my understanding that xdoclet wouldnt go away because it has the templates to generate code except that they might have to change their code generator to look up java 1.5 annotations instead of using their parser apis to look up the present xdoclet tags?.
expectation is the root of all heartache - shakespeare. tiny ad: