I would like to see a formal End Of Life (EOL) program for deprecated content. Once there is a documented and well known replacement for deprecated content, that content should be given an official EOL. The EOL can be expressed as the release at which that content will no longer exist. This could be an argument to the Deprecated annotation for documentation purposes.

EG If, as we approach the 1.8 release, we see that a new Date/Calendar API has replaced all useful functions of the recently deprecated Date API and is being successfully adopted then we might declare the EOL of the old Date API as “Java 1.9″.

@Deprecated(endOfLife=”Java 1.9″)

Benefits
* Library and tool maintainers will know how to prioritise efforts to move away from deprecated content.
* APIs will tend to grow at a lower rate rather than bloating with unused (and often unusable) content.
* APIs will be simpler to learn (a balance against the increasing, albeit useful, complexity of the language)

“Daniel Fuchs announced the open-sourcing of the OpenDMK project, which implements cascading, a key feature of JMX 2.0.”

In fact OpenDMK implements *a* type of cascading – which is *not exactly* what will be in JMX 2.0 (how exactly the cascading feature of JMX 2.0 will be like is open to discussion in the JSR 255 expert group).

However OpenDMK is a good starting point to experiment and raise feedback.

Cheers,
– daniel