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."

Re:New Jade Version Released

[sr180]

I think the whole of Jade should be living in commons.apache.org somewhere

Apache Commons has been closed. Nothing lives there now.

Re:New Jade Version Released

[Zach Garner]

I think the whole of Jade should be living in commons.apache.org somewhere

You mean: http://jakarta.apache.org/commons/ [apache.org]

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 [java.net]) project (this isn't from Apache, unfortunately). The documentation isn't that great yet, but the API [javadesktop.org] is all you need.

Re:New Jade Version Released

[Anonymous Coward]

The author of the post was referring to the http://commons.apache.org/ commons project being closed. This is not the jakarta commons at http://jakarta.apache.org/commons/index.html.

cern.colt

[rowanxmas]

if you program in Java and need to do matrix stuff or, want fast data structures check out:
the CERN Colt Libraries [home.cern.ch]

Re:Interestin library ... this jade ... but ...

[jaoswald]

Garbage collection means you don't have to use tools that run your program in a sandbox to avoid programming errors which are unfortunately easy to make. Instead, you can spend the time making enhancements and improving performance instead of plugging stupid leaks all day.

Valgrind only fixes memory allocation problems which you can reproduce in a test situation. It doesn't fix memory allocation problems which occur when your application reaches the field and can be subjected to long runs with unpredictable inputs.

Garbage collection IS a modern programming tool. Why are you so afraid of it?

It's cute, but it won't fly...

[dkf]

What we have here is a library that comes in several bits. The numeric and units handling parts are all very neat, but rather special-purpose (I just don't need them at all in my Java programs), and the stuff to allocate things on the stack for improved realtime performance is rather risky for non-experts to use (e.g. stack space tends to be much smaller than heap space, so you have to be careful with how much stuff you actually allocate on the stack). The RT bits also look (from a casual glance) like they'd need an update to the JVM and bytecodes to actually work...

JVM and bytecode updates are painful (can you say "Porting and Deployment" without winceing?) so those bits are a non-starter for general use, and the rest of it could (theoretically; I don't know how much it depends on the parts I've just rejected out of hand) just as happily be in a third-party lib, and they're something that Java's really good at.