I've read what is available about this JSR, here and here.
It tries to solve the problem that you often need to make more classes and functions public than necessary, because classes in different packages can't access eachothers members unless they're public.
However, I'm really disappointed with Gilad Bracha, the Specification Lead for this JSR. He wants to create super packages, which sounds like an interesting idea, but his proposal is just hideous. Holy cow!
In the comments section of that blog posting, Inigo has this suggestion:
An alternative strawman solution - how about doing the opposite? Rather than restricting what's visible via a "superpackage", why not encourage clients of your interface to use "published" methods?To me, this seems like such an elegant and simple suggestion. No need for any new language features, just a handy-dandy new standard annotation.
Something like:@Published public class MyInterface { @Published public String publishedMethod(); public String methodUsedInternally(); }Then, my IDE can list the published methods first when it's autocompleting, I can tell my IDE/build tool/classloader to warn/stop me if I use unpublished methods from certain packages, I can build JavaDoc for just the published methods - but I can still ignore the warnings and use unpublished methods if I want to.
Gilad's comment to this was:
Many of the suggestions are the kind of horrible abuses of the annotation facility that I warned against in an earlier entry. Annotations are NOT used to add language features!Well, the genie is out of the box, and Sun opened it, in the form of at least @Override and @Deprecated. They do similar things to what @Published would do, letting IDE's and javac spank fingers that are doing bad things.
So, I suggest you vote no to this whole thing. Sure, the JSR is adressing a problem, but the pain it tries to remedy is nowhere near what his new super packages would do to us.