Comments on: Jigsaw and CDI: A Perfect Fit http://blog.caucho.com/2010/03/05/jigsaw-and-cdi-a-perfect-fit/ Inside info, thoughts, and opinions from Caucho engineers Tue, 21 May 2013 12:02:56 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: njbartlett http://blog.caucho.com/2010/03/05/jigsaw-and-cdi-a-perfect-fit/comment-page-1/#comment-588 njbartlett Tue, 09 Mar 2010 20:24:10 +0000 http://blog.caucho.com/?p=403#comment-588 @ferg No, JSR 294 does NOT define the module system. In the words of Alex Buckley, the specification lead for JSR 294, it "provides language and VM features for the benefit of module systems such as OSGi and Jigsaw". (http://blogs.sun.com/abuckley/en_US/entry/jsr_294_and_module_systems) Maven is a modular build system, not a runtime module system. OSGi certainly IS a module system, as is Jigsaw (once released). @ferg

No, JSR 294 does NOT define the module system. In the words of Alex Buckley, the specification lead for JSR 294, it “provides language and VM features for the benefit of module systems such as OSGi and Jigsaw”. (http://blogs.sun.com/abuckley/en_US/entry/jsr_294_and_module_systems)

Maven is a modular build system, not a runtime module system. OSGi certainly IS a module system, as is Jigsaw (once released).

]]> By: ferg http://blog.caucho.com/2010/03/05/jigsaw-and-cdi-a-perfect-fit/comment-page-1/#comment-585 ferg Mon, 08 Mar 2010 17:08:41 +0000 http://blog.caucho.com/?p=403#comment-585 Hmm. I think it would be more accurate to say that JSR-294 defines the module system, but leaves open the management of module repositories and their associated classloaders, like the current JDK leaves open management of the classloaders, jars and the classpath. Maven and OSGi are both jar management systems (OSGi is also a classloader manager), but neither is really a module system. Hmm. I think it would be more accurate to say that JSR-294 defines the module system, but leaves open the management of module repositories and their associated classloaders, like the current JDK leaves open management of the classloaders, jars and the classpath.

Maven and OSGi are both jar management systems (OSGi is also a classloader manager), but neither is really a module system.

]]> By: njbartlett http://blog.caucho.com/2010/03/05/jigsaw-and-cdi-a-perfect-fit/comment-page-1/#comment-581 njbartlett Sat, 06 Mar 2010 01:34:31 +0000 http://blog.caucho.com/?p=403#comment-581 Sorry my last comment was facetious. The point I really wish to make is that the new "module" access level keyword is being specified in JSR 294, which is separate from Jigsaw. 294 is the specification for module system support in the Java language, and is not tied to any specific module system. If the 294 Expert Group does its job properly then the "module" keyword will be understood by the javac compiler and usable in OSGi as well as within Jigsaw. Sorry my last comment was facetious. The point I really wish to make is that the new “module” access level keyword is being specified in JSR 294, which is separate from Jigsaw.

294 is the specification for module system support in the Java language, and is not tied to any specific module system. If the 294 Expert Group does its job properly then the “module” keyword will be understood by the javac compiler and usable in OSGi as well as within Jigsaw.

]]> By: emil http://blog.caucho.com/2010/03/05/jigsaw-and-cdi-a-perfect-fit/comment-page-1/#comment-580 emil Sat, 06 Mar 2010 01:29:15 +0000 http://blog.caucho.com/?p=403#comment-580 Hi Neil, Thanks for the correction about the injected services. Actually, now that I think about it, it might be possible to do some interesting work with CDI scopes to solve the dynamic injection issue you mentioned. I agree, CDI + OSGi would certainly work and I imagine there will be a melding at some point. In fact, I believe there was also some work to integrate Jigsaw (or at least JSR-294) and OSGi. I haven't kept up with the current state of that. The method-level hiding at the module level is completely new. Private, package, and protected access don't really allow the kind of cross-package access that a module keyword can. Thanks for the response, Emil Hi Neil,

Thanks for the correction about the injected services. Actually, now that I think about it, it might be possible to do some interesting work with CDI scopes to solve the dynamic injection issue you mentioned.

I agree, CDI + OSGi would certainly work and I imagine there will be a melding at some point. In fact, I believe there was also some work to integrate Jigsaw (or at least JSR-294) and OSGi. I haven’t kept up with the current state of that.

The method-level hiding at the module level is completely new. Private, package, and protected access don’t really allow the kind of cross-package access that a module keyword can.

Thanks for the response,
Emil

]]> By: njbartlett http://blog.caucho.com/2010/03/05/jigsaw-and-cdi-a-perfect-fit/comment-page-1/#comment-579 njbartlett Sat, 06 Mar 2010 01:17:53 +0000 http://blog.caucho.com/?p=403#comment-579 OSGi services do not need to be manually registered and looked up; they can certainly be injected. The injection can be driven by source code annotations, and I think it should even be possible to adapt CDI's annotations to inject OSGi services. The key challenge is that most existing DI frameworks (including e.g. Spring, Guice etc) do not support the dynamic re-wiring that is possible with OSGi services; there is no concept of having a dependency "uninjected" and then "reinjected" at runtime. Nevertheless both Spring and Guice have been very successfully adapted to OSGi so I see no reason that CDI couldn't be also. Incidentally, method-level hiding is of course possible in OSGi. Java has supported the private and protected modifiers on methods since... well, forever :-) OSGi services do not need to be manually registered and looked up; they can certainly be injected. The injection can be driven by source code annotations, and I think it should even be possible to adapt CDI’s annotations to inject OSGi services. The key challenge is that most existing DI frameworks (including e.g. Spring, Guice etc) do not support the dynamic re-wiring that is possible with OSGi services; there is no concept of having a dependency “uninjected” and then “reinjected” at runtime.

Nevertheless both Spring and Guice have been very successfully adapted to OSGi so I see no reason that CDI couldn’t be also.

Incidentally, method-level hiding is of course possible in OSGi. Java has supported the private and protected modifiers on methods since… well, forever :-)

]]>