Comments on Mind the gap: The state of Java modularity: JSRs 277, 291, and 2...

Glad you've found the blog helpful.

2007-06-21T13:59:00.000+01:00

Glad you've found the blog helpful.

These comments have been invaluable to me as is th...

2007-06-21T10:25:00.000+01:00

These comments have been invaluable to me as is this whole site. I thank you for your comment.

Glad you found the blog useful, Carlus.

2007-05-19T08:34:00.000+01:00

Glad you found the blog useful, Carlus.

I have been struggling with understanding what is ...

2007-05-18T22:08:00.000+01:00

I have been struggling with understanding what is going on with all of the different JSR's regarding Java Modularity and how it relates to OSGi. After reading this blog posting, it is more clear as to the motivations behind the different JSR's as well as why they are all important.

Thank you so much for taking the time to produce this. I look forward to reading more interesting posts from you in the future.

Carlus

Further to my previous comment, I should have ment...

2007-03-29T06:39:00.000+01:00

Further to my previous comment, I should have mentioned that JSR 277 supports an optional "deep validation" check which detects some types of inconsistent class spaces.

I'm not sure whether deep validation would catch the particular scenario described.

Also I'm not sure whether it is feasible for the JSR 277 resolution process to use deep validation and continue searching until it finds a module wiring which ensures consistent class spaces.

>Does JSR 277 take care of class>space consistency...

2007-03-28T19:24:00.000+01:00

>Does JSR 277 take care of class
>space consistency like OSGi does?
In your example in OSGi, you'd have to encode the dependency from A to B with a "uses" directive on import-package so that OSGi will preserve class space consistency.

JSR 277 does not support this, so you'd probably get a class cast exception or something similar.

Yes, we need to take this into account when JSR 277 steps up to providing interoperation with JSR 291 (OSGi). I suspect there will be some restrictions that are not present when using OSGi on its own.

Does JSR 277 take care of class space consistency ...

2007-03-28T17:31:00.000+01:00

Does JSR 277 take care of class space consistency like OSGi does?
I.e. if class A requires class B, and class C requires both A and B than the modular runtime will resolve the modules of A and C to exacly the same module exporting B. If JSR 277 aims to evolve the class loader it seems to be a crucially important thing to guarantee class space consistency wouldn't you agree?

Even if JSR 277 does gurantee that it's evolved class loader will keep the class space it manages consistent at all times there will be trouble in mapping OSGi bundles to JSR 277 modules right? Because both the OSGi bundle and the JSR 277 module contain many java packages and at the same time the OSGi class loader handles consistency in terms of packages while the JSR 277 class loader would handle this in terms of entire modules only.

Richard: JSR 291 also solves class path hell and h...

2007-03-16T06:57:00.000Z

Richard: JSR 291 also solves class path hell and handles versioning, but you're right that JSR 277 is providing a repository for installing modules in.

>How do you see the comparison with >the log4j vs ...

2007-03-16T06:45:00.000Z

>How do you see the comparison with
>the log4j vs jdk logging decision?

I'm not aware of the detailed background of the logging debate, but logging would seem at least an order of magnitude easier to get 'right', although I dare say there's more to it than I appreciate.

With the benefit of hindsight, how much has log4j evolved since JDK logging was standardised? You see, I think the crucial point here is the rate of evolution of module systems relative to the rate of evolution of the Java platform.

Anyone have a link to a dispassionate analysis of the logging debate? Failing that, anyone prepared to write such an analysis?

Ok, Lets see if I'm getting this strait. JsR 277 &...

2007-03-16T03:47:00.000Z

Ok, Lets see if I'm getting this strait. JsR 277 & 294 are trying to solve the current issues with static class path. Example the issues with multiple jar's with the same name on the class path, versioning in jar's ect.. or class path hell. While JSR 291 is the dynamic issues of loading and unloading jar's (bundles) on the fly. If I'm reading this right then this is something I can get behind because the current jar hell is something that needs to be dealt with. It would be really nice to have a system repository where everything is installed then when my application loads the correct version of the lib(jar) I need will be loaded with out having to do class path magic. Something like that would be very help full for the end user and the developer.

How do you see the comparison with the log4j vs jd...

2007-03-15T17:56:00.000Z

How do you see the comparison with the log4j vs jdk logging decision?
Not going with the existing open source modularity mechanism might sentence us to apache-commons-modularity for life.