Improving The Java Core Library
dautelle writes "Many Java developers are frustrated by the not-so-open process to improve/correct/augment the Java core libraries. Unless you work for Sun or belong to a JSR expert group, there is very little you can do to influence the future of the Java platform. Even the JCP route can be a frustrating one (e.g. JSR-108 withdrawn by Sun because not enough progress made in a timely manner). To address this serious issue, the charter of the Java Addition to Default Environment (JADE for short) has been extended, along with the release of JADE 7.0. Participation to the jade.* package development is truly open (unlike javax.*). The library already provides numerous useful classes, bug fixes, enhanced implementations of existing classes, etc. Hopefully in the near future, the library could become so useful that it becomes a de-facto complement to the JDK."
i have been programming around with java for quite a long time, sometimes indeed i have felt like some c/c++ solutions would be so easy'n'fast'n'economic at some points, but i always have found a working workaround. seems like the jade dudes are not satisfied with that.
:)
the thing that disturbs me about this article is that, it seems like the author would like to have this lib in java. i'm against it. because it provides tools to improve your code in many ways, but at the same time, it somewhat brings java down to the c++ like level, where memory losses and "forgotten" objects are quite common mistakes.
as a separate library, i think jade is great and the next time i'm writing something really complicated i'll surely have a look at it. but at the same time i think it should not be included in java's original libraries cause java newbies would surely make a lot of mistakes by using it and then everyone would blame Java for being so buggy and unusable for them. java has a strong and stable baselib which doesn't provide many ways to make mistakes, jade surely has greater opportunities but also greater flawsources.
however i think that sun should somehow support jade's development and offer at least a link to it under it's downloads page, so people could see that the usual oop model is not the limit and also would avoid inventing the wheel in a lot of cases.
i think sun is being conservative, cause it has always been that way, and it seems a quite secure and reasonable, cause most java apps are more secure and stable than anything else around. they are just concerned about java's reputation and dont want to rush items into their language which would overhaul new java developers and lead to popularity loss of java.
many cool libraries could be real battleaxes in the hands of java, but at the sametime, they could backfire, which sun is just trying to avoid.
keep up the good work on jade
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
As an alternative to trying to contribute to the Sun java and javax libraries, people could contribute to the Classpath libraries. Getting these complete means effort could then be expended on useful extensions and perhaps some optional improvements to the standard libraries. If Classpath could get some serious impetus (from IBM for instance), then Sun may have to open the development of their reference implementation or risk being left behind.
I think the whole of Jade should be living in commons.apache.org somewhere
You mean: http://jakarta.apache.org/commons/
The Jakarta project is Apache's Java efforts. commons.apache.org used to hold common libraries such as APR for Apache HTTPD. These were mostly C libraries, I believe.
Apache Jakarta Commons (ok, so Apache needs to clean up and simplify there project namespace), rocks.
Here's there summary for commons-collections
* Bag interface for collections that have a number of copies of each object
* Buffer interface for collections that have a well defined removal order, like FIFOs
* BidiMap interface for maps that can be looked up from value to key as well and key to value
* MapIterator interface to provide simple and quick iteration over maps
* Type checking decorators to ensure that only instances of a certain type can be added
* Transforming decorators that alter each object as it is added to the collection
* Composite collections that make multiple collections look like one
* Ordered maps and sets that retain the order elements are added in, including an LRU based map
* Identity map that compares objects based on their identity (==) instead of the equals method
* Reference map that allows keys and/or values to be garbage collected under close control
* Many comparator implementations
* Many iterator implementations
* Adapter classes from array and enumerations to collections
* Utilities to test or create typical set-theory properties of collections such as union, intersection, and closure
For those doing Swing programming, also check out Java Desktop Network Components (JDNC) project (this isn't from Apache, unfortunately). The documentation isn't that great yet, but the API is all you need.
What about MS? I think that they also wanted to "embrace and extend" Java as well at some point.
My point is, that sometimes I feel like people think free software should always get its way as a matter of principle. The truth is, that you are free to write an alternative classpath. and distribute it with your own VM as it is. Quit moaning and join in with the guys at GNU Classpath. Sun doesn't mind. It's focusing on its own. That's what MS did.
To err is human, but to forgive is beyond the scope of the Operating System...
Yes, people could cram more and better functionality in there, and everyone is sure their idea will just make Java better; but every new version makes Java less and less portable. Adding the same functionality in a non-core library is every bit as effective, but doesn't add the additional requirement for a new version, and will avoid breaking and deprecating enormous existing bodies of code.
If you need new or better/differently implemented functionality, you are free to add it. If Java is unable to accomodate the addition outside the standard library, then the platform has failed.
Don't get me wrong -- I'm a fan of Java. But, if the core of a language needs to be constantly updated, its an unstable language, and bad for production development. I think Java can be stable, but it requires that the developers do just what they are. Keep the standard libraries standard, and not full of every shoehorned-in functionality they can think of. Its already bloated enough.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
if you program in Java and need to do matrix stuff or, want fast data structures check out:
the CERN Colt Libraries
I've never really understood why people get their panties in a wad over the java core library. The java core is a wealth of good tools, but the language is not limited to just those tools. If you write a good library, people will use it. If you write a crappy library, getting it included in the core java library won't make people use it, it'll just waste space. I personally would rather the core library be slower to include things until they are well tested, than to include lots of new things just because they're popular. Just because YOU write a library to calculating profit given two arguments and a couple ?'s doesn't mean *I* want it included as part of the java core.