Challenges to adoption of Jigsaw

Discussions

News: Challenges to adoption of Jigsaw

  1. Challenges to adoption of Jigsaw (4 messages)

    We implemented a component deployment model, also known as JRE modularity, for the core of J2SE 5.0 and Java SE 6 without breaking Java compatibility. The technology’s been in production use for more than two years and proved effective. I’ve recently outlined the necessary deployment tools and Java runtime machinery in this Excelsior blog post. Given that Project Jigsaw is emerging in JDK 7, I offer some insights on the challenges that any implementation of modularity for the Java SE core may face. World peace. The corporate battle around OSGi needs a break. None has won and the Java Community has lost because, time after time, JRE modularity solutions appear to disappear (remember JSR-277). To use or not to use OSGi now is less of an issue as compared with the next challenge. Backward compatibility. In modular approach, each component should be sufficiently isolated and import relations should be declared statically. Besides that, import graph should be (close to) acyclic to minimize the number of indirectly used components. The problem is that the reference implementation of the Java SE API was coded without having modularity in mind. Somewhat it was a side-effect of the Java’s lazy classloading which created an illusion that a use of any class in Java code costs nothing until it’s actually executed at run time. It’s proved to be a technical debt and now is the time to pay the interest. In practice, it means that spaghetti-like dependencies between the implementing classes are omnipresent and breaking the ties without breaking backward compatibility with previous Java versions is double tough. The danger is to create something like Apache Harmony: everything is implemented with an elegant internal architecture, samples work, but existing Java apps have issues. Need for total modularization. There is a risk to get no benefits from the JRE modularity alone. Most real world applications use third-party components (Java APIs), which are yet to be modularized. Typically, applications tend to use only a part of the functionality provided by an API. Without total modularization, chances are good that unnecessary parts of (modularized) JRE will be taken in due to use of a (monolithic) third-party component. And it’s no matter whether the import declarations will be written in OSGi bundle manifests or somewhere else. What do you think of the above?

    Threaded Messages (4)

  2. I've been hearing about Jigsaw forever... When will we get to preview it?
  3. I’m not with the Sun Java SE core group and have no ideas about Jigsaw release dates. I’ve seen this blog post that discusses recent moves in Jigsaw concerning versioning mechanisms.
  4. OSGi has clearly won[ Go to top ]

    The corporate battle around OSGi needs a break. None has won and the Java Community has lost because, time after time, JRE modularity solutions appear to disappear
    I think you're wrong, OSGi has clearly won, the JRE missed the modularity train. Developers that are interested in modularity are already using OSGi. Java should start with a subset of OSGI and add some minimal changes as deemed absolutely necessary.
  5. Re: OSGi has clearly won[ Go to top ]

    I think you're wrong, OSGi has clearly won, the JRE missed the modularity train.
    I have nothing personal against OSGi but I would not call it “clear win” because the second player (Java Module System) retired from the match. Moreover, you confuse Java modularity with JRE modularity. My point is there are serious issues with splitting the JRE into components apart from what system will be used (OSGi or not).