"Jigsaw is implementing a module system for Java 8 that deviates from the modular spirit of Java in a way that is bad for the language."

It's a somewhat controversial thing to say about a system of modularity that not only positions itself as the standard for modular develop in Java, but also aspires to become the modular machanism upon which the JVM itself will be built. But Peter Kriens does not stand down from the controversy, expressing a strong argument that incorporates packages, dependency models, exporting-types and importing-modules, and subsequently applies Occams' Razor of Symmetry to show that the strengths of the OSGi approach is both more technically and philsophically sound.

Read the full article here:

http://www.theserverside.com/feature/Successful-modularity-depends-on-your-dependency-model

Edited by: Cameron McKenzie on Aug 22, 2011 2:05 PM

Hi,

I beleave you have all the dimonds for aggregation and composition on the wrong ends of relationship lines.

Ben.

 

You're right, egg on my face. Teaches me not to use new diagramming techniques.

I will try to fix it.

Maybe OSGi people should take this as an opportunity rather than an attack/battle.  As we've seen/learned with Java EE, specifications can obtain a lot of baggage over time.  Tackling modularization in Java 8 could be approached as an opportunity to take best practices/patterns/etc from OSGi and refactor them into Java SE without having to worry about backward compatibility from an aged specification like OSGi.

Having worked on a few JSRs over the years, there have been times where I've thought "I wish we never did that." and "Wouldn't it be cool if we didn't have to support that API anymore?"  This is such an opportunity for the OSGi folks.

The one thing Peter mentions he would remove from OSGi is Require-Bundle, which incidentially is exactly what Jigsaw seems to promote. So, it looks like you have not even read the article (or did not understand it). Sad...

We'll said. It's good to discuss this now, but also realize that Jigsaw is not necesarily equivalent to Java 8 modularity. There is still time to collaborate and make sure the right things get done.

I fought to get into JSR 277, I was (am) in JSR 294 and I post regularly on the Jigsaw mailing list. But I feel I am standing in front of an oncoming train.

Peter Kriens

 

Perhaps the article series on TSS was the right answer to the problem :-). I do understand some of the ex-Sun engineers' propensity for NIH. Hopefully that subsides a bit with Oracle :-).

I agree that Jigsaw has its problems, but the fact that it doesn't use package-based resolution is very definitely not one of them.  This article is full of pat truisms and defective logic, and completely ignores the requirements of a module system which has to be embedded in the JVM.  Any module resolution algorithm with a complexity greater than O(1) is simply not acceptable.  Starting up an OSGi container at boot is not acceptable.  Even executing resolution at build time is not acceptible, because when you install new modules under a package-dependency system, you might affect the resolution of all your existing modules, thus you must keep a complex resolution database.  This makes manual installation of modules impossible.  This is simply a non-starter.

Peter's article concerned logical structures - and nicely demonstrates the fundamentally logic flaw associated with Jigsaw. The inferences that an "OSGi container" is required and "hypothetical runtime resolver" issues are IMO attempts to uncessessfully muddy the water.

Best Wishes

Richard 

 

You mean "logical fallacy structures" right?  Those graphics completely misrepresent how Java linking and compilation even work.

Can you explain? I've tried to represent them as truthfull as I can but I can always be mistaken of course.

Peter Kriens

 

I beleve the issue is that the current java classpath model is not one where the current module (a jar or classpath root) exports packages. It still is just a collection of classes. There is no package index there, and in fact, a java.lang.Package does not even exist until a class associated with the package has been loaded. classpath modules export types.

 

I am only arguing in this article for package dependencies as this was a very strong lesson we learned. I am not advocating an OSGi container inside the VM, I already would be overjoyed if we could get versioned packages out of the VM.

I do not think we need an OSGi container at the heart of the VM, problems there are not comparable to the problems in the application world. However, the core should be really small and a careful design would take into account how we build big enterprise applications as well as small desktop apps on top of this mini-VM. In that world, packages are crucial to minimize dependency problems imho.

Stating that a resolution must be O(1) is not very useful as it does not say anything about the experience. O can be very large and an O(n) can therefore be shorter in all practical cases. The fact that a module system should not add to the startup has my fullheartedly support. I do not think this has to be an issue with a package based module system. On the contrary, OSGi is already faster in class loading than normal Java because it can directly request the class from the exporting bundle, minimizing unnecessary class path traversals. The right architecture allows numerous optimizations that can alleviate any performance impact. Look how Glassfish touted OSGi because it reduced their start up time.

I am not sure I understand why "manual" (what is this) installation is impossible? Modules that must be tightly bound are tightly bound, modules that are less anal should get a new version since it might contain the dearly needed (and expected) bug fix. If I update an important DLL on my windows system I want all dependents to be updated because it contains a bug fix. If a developer does not want that, he should provide his own copy. This should be a user/developer choice and not mandated by some architecture.

 

 

I don't see how we can meaningfully talk about O(n) being faster than O(1) in the abstract. No one is going to take it seriosly that some magic O(n) algorithm performs better for all n than any O(1) algorithm accomplishing the same thing.

By manual installation, I take it to mean, what dependency descriptor am I writing, as a systems author, to pull in the types required for the system. It just is not practical to do that as a list of packages. I would say the example of referencing the packages contained in JPA as javax.persistence.* illustrates the problem. It is a nice shorthand for the javax.persistence, javax.persistence.criteria, javax.persistence.metamodel, and javax.persistence.spi type space. It is simply tedious to have to specify all of these pacakges when speaking of some JPA version, and these packages are never going to be combined from different class loaders. Someone using JPA 2.x expects all 4 pacakges bundled together with the same defining class loader.

 

Peter Kriens in the article above has good points. I have never actually read about the details of Jigsaw, all I knew was that they are, finally, going to introduce a standarized module system into the Java core.

Now I am a little bit worried. If the Jigsaw tem is going to introduce such a mess - aren't we, as a community, now to start asking real questions? Who are we going to blame if they screw things up tommorow?

There's much more you can do than simply ask questions. You can get invovled with the JSRs in question and try to make sure the right things happen in a timely fashion.

Even better, details of the Jigsaw project on OpenJDK are here http://openjdk.java.net/projects/jigsaw/  and this page includes a link to the mailing list.

The discussion is mainly about what exported / imported content is and should be. For OSGi, this is about packages and modules (even though the later are seen as a burden that is there for political reasons), whereas Jigsaw modules will export types and import modules. I have done quite a bit of Eclipse programming in the past and this made me think a lot about exporting / importing content. I think the distinction between two layers of abstraction (the module, and the service layer – in case of Eclipse the extension registry) which even have different meta data formats is artificial and often leads to errors. Ok, the Eclipse UI tries to hide this, and one could argue that there are now attempts to build more consistent service layers and the situation in Eclipse is caused by history, but I think there is a much simpler solution to the problem.

Lets just remember how OSGi works at the moment. We have the following two types of module collaboration:

1. module 1 requires package version range - module 2 provides versioned package
2. module 1 requires module version range - module 2 provides a versioned bundle (=itself)

When using a service layer such as the Eclipse extension registry or declarative services, other collaboration types are added to the mix, in particular the following:

        3. module 1 requires interface - module 2 provides class

The contracts that define the correctness of the application are pretty simple: “version must be in version range” for types 1. and 2., and “class must implement interface” for type 3. By the way, this is not only about Java artefacts, there are many use cases for other types of collaborations between modules, such as:

     4. module requires xml instantiating a certain DTD – module provides XML

This type of contract is used in the Eclipse help system. My point is the following: perhaps we can and should be able to export / import all of the following: modules, packages, types and other artefacts. The key is a simple abstraction: modules declare what they need using typed resources (types are package version ranges, Java interfaces, DTDs, etc), and export what they can provide as typed resources (types are package versions, Java classes, XML resources, etc). Module system containers such as OSGi can then use the relationships between those resources (version matches version range, class implements interface, document validates against DTD, etc) to wire modules (=create classloaders) and verify assemblies (e.g. to check compatibility between classes and interfaces).

See also http://code.google.com/p/treaty/ - a prototypes we built a few years ago that implements some of these ideas.

 

 

 

 

 

 

 

for im still having a hard time with Jigsaw graphic designer holiday gifts

Nie od dzisiaj bez wątpienia o szkodliwości elektroniczne papierosy wypalania. Indywidua, jakie rzuciły nałóg tytoniowy, rozpamiętywają z kłopotem skończony ten proces. Interesy farmaceutyczne elektroniczne papierosy wdrażają w tym momencie pewien godzina innowacje plus plony pomagające w zrywaniu przyżegania. Pojawiły się elektroniczne papierosy z tej przyczyny przeróżne płaty nikotynowe, kauczuki aż do przeżuwania także nieelektronowe pety. liquidy e-papierosy Elektroniczne pety (sławetne w podobny sposób jako elektroniczne papierosy) to najpóźniejszy owoc na rynku. Egzystują one przewidziane, iżby wyglądać natomiast sprawiać jak na przykład pierwotne pety. Wydzielają również nieautentyczny kopć, atoli w rzeczywistości nie zamykają tytoniu. Konsumenci elektroniczne papierosy inhalują pary nikotyny, jakie kserują ćmijże odarty posad karcinogennych, jakie stanowią złe w celu palącego również odrębnych typów.

I agree this deviates from the modulars golden age of hollywood actresses