What I was trying to say was, I would like some way to declare (in my source) the existence of modules. I want those constraints enforced (with respect to package visibility) at compile-time and run-time by javac and java without the need for a separate OSGi runtime. This (may) be completely independent of how I actually package my app. I think this might map into what JSR 294 is addressing, although I’m not totally clear on the boundaries between 277 and 294.

The other item, which may not be feasible, is the ability to look up (dynamically) all implementors of an interface. This is critical for any kind of dynamic plugin architecture and is something that you can get in OSGi through extension points. It’s obviously complicated in Java by the fact that classes are loaded as needed, so it may be impossible to answer this question without actually scanning the entire classpath or doing something that would have performance or logistical problems.

Those are the two issues that I’ve hit repeatedly and looked to something like OSGi to solve. I think the first one can and should be handled as part of the platform, regardless of packaging. It’s possible that Java modules would allow me to handle the second as well, but I haven’t seen enough to know yet.

I apologize for the word “junk” which is not really fair (I didn’t mean it pejoratively) which I was using as a shorthand for “stuff above the Java platform”. And I was also thinking of the meta files that come out of using Eclipse projects, more than OSGi.

Thanks for keeping me honest…. :)

“Bundle” is the OSGi terminology for a module, and you can hardly have a module system without modules.

Manifests you have already any time you create a Jar. OSGi adds a few lines of metadata, such as the module name and the dependencies. Again, you can’t have a module without metadata.

And the other junk… what other junk? That’s all there is!