Help

I had the pleasure of gabbing about JBoss Modules a couple times at the Red Hat/JBoss booth at JavaOne this year, drawing frankly more interest than I thought I'd see. As a part of my talk (the video for which you can download here [well, soon anyway]), I chatted a bit about what the future may hold for Java in terms of modular runtime, modular development lifecycle, and distribution management. Some things seem certain - that the current paradigm won't hold, for example - and some are very uncertain - such as what, if anything, will replace Maven as the ubiquitous modular build/distribution system of the future.

There are many things that we, as a community, have learned over time about how projects are built, deployed, maintained, and integrated. However, every popular build and deployment system in existence today is crafted from only a limited subset of this shared knowledge, usually from the point of view of that project's particular czar. The advent of modularity in common usage, and ultimately the JDK, is the final call to arms for the community to step up and share their knowledge.

Because Oracle continues to turn a deaf ear to the community when it comes to Jigsaw, it is left to the community itself to establish and understand the true nature of the problem of program and library distribution for Java. The requirements published thus far by Oracle are presented from the perspective of a company whose expertise lies not in the development of the applications that you write, but in the sales and marketing of the platform that they develop. This is why there is a community process, which is unfortunately thus far being largely bypassed in the development of Jigsaw and its supporting infrastructure. History has clearly shown that the success of any given Java specification depends largely on community involvement and empowerment. So it seems clear to me that the success of the modularity initiative will also depend on the community.

With that in mind, members of the jigsaw-dev mailing list recently discussed the idea of holding a community meeting for the purpose of brainstorming requirements for modularity in Java. I am hoping that we can discuss topics ranging from run-time modular resolution requirements and technical details to build dependency resolution to library distribution paradigms; if the chat goes well we could even evolve it into a regular or semi-regular event.

The chat is scheduled to be held at 10:00 A.M. US Pacific time on Friday, October 21, 2011 in the ##java-modularity channel at irc.freenode.net (web chat link). If you have any experience you'd like to share, either as a user or a developer of an existing build or modularity system, or you just want to see what happens, please join in the discussion. It's undecided at the moment but the discussion may be moderated, depending on attendance. Note! Make sure you have a registered nickname ahead of time so you can join in without any issues when the time arrives.

I look forward to chatting with you!

7 comments:
 
15. Oct 2011, 11:19 CET | Link
Philippe Marschall
I currently see nothing that could replace Maven. And Maven repos and metadata are probably going to stay with us even longer.

I see Jigsaw as I see JBoss Modules.
JBoss Modules: if it makes JBoss AS "better" (which it obviously did) it's a great thing even if it's inadequate for me (with it is)
Jigsaw: if it makes the JDK/JRE "better" (which it might, arguably Oracle understands the needs of the JDK best) it's a great thing even if it's inadequate for me (with it's likely going to be)

Look at JSR-47 for example. Classical Sun fuck up. Did anybody outside of Sun care? No. Was anybody affected by this? No. I wouldn't be surprised if Jigsaw is going to be the same. It's just another API that doesn't get used in practice like so many in JavaEE.

Oh, and your session timeouts suck. I had two timeouts while writing this post.
ReplyQuote
 
16. Oct 2011, 00:36 CET | Link
Gary Struthers

JBoss should forget about brainstorming yet another module system and cooperate with Sonatype, Apache, Fusesource etc. on Enterprise OSGI developer tools so that application developers can be productive creating modular applications.

Enterprise OSGI specs should, finally, be complete enough for application development at the end of this year. Implementations from Spring/Oracle and Apache/IBM/Fusesource should be released next year. The problems with OSGI are that vendors spent way too much time arguing about specs and vendors were allowed to force too much backward compatibility. The criticism of OSGI as being too complicated is not borne out by the two teams quickly implementing specs. Lack of developer tools is why I don't build OSGI applications right now.

Today Peter Kierns says BndTools will be released next week with tight integration with Maven and the m2Eclipse plugin. I believe the coming release of BndTools Eclipse plugin will allow me to add it to my m2Eclipse plugin, then when I do a Maven build, BndTools analyzes class dependencies so that package dependencies are added to the jar manifest files turning Maven built jars into runnable OSGI bundles.

 
18. Oct 2011, 21:01 CET | Link

You should take note that nothing in JBoss Modules or Jigsaw is designed to replace OSGi. They really meet different use cases. In our case, we build JBoss OSGi on top of JBoss Modules and the result is, last I heard, faster than anything else out there.

OSGi (like Java EE) is something above and beyond a module system; it's a service container which includes a dependency resolution system. However the type of resolution that it does is designed for a container environment - in many cases, all possible bundles have to be visible and at least partially resolved in order to resolve any bundles due to the complex resolver algorithm. This is simply not viable for an SE-scoped module system, whose purpose is simply to replace classpath with a more efficient mechanism. The goals of an SE module system are not the same as OSGi's goals.

That said, it has been stated repeatedly that one requirement of Jigsaw (and JBoss Modules for that matter) is to be compatible with an OSGi runtime. So you shouldn't be worried about yet another module system, because that isn't what OSGi even is (at least, not solely).

Most specs in the Java space are tanked by lousy requirements gathering. Vendors who are motivated by hidden agendas are not level with use cases; instead they push solutions to problems they don't explain. I don't think that this is good for the project or the community. It's much better to establish the actual requirements and then argue about implementation once that is done. From the OSGi perspective, it's a specification that clearly isn't suited for this task, yet the primary argument I keep hearing is well it's a standard specification and it'll catch up. But this kind of logic will drag you down in the real world. I've seen and implemented many specifications which were designed this way, cart-before-horse style, and the result always sucks. Always. The spec rarely catches up with the real requirements. You place your faith in specifications; I will put mine in effective requirements gathering and community participation.

 
19. Oct 2011, 04:47 CET | Link

I've rarely in my life met a more overengineered, overcomplex spec than OSGi. Compatibility with OSGi should be an anti-requirement in any sane world. Unfortunately we live in this world :-(

 
19. Oct 2011, 04:52 CET | Link
Gavin King wrote on Oct 18, 2011 22:47:
I've rarely in my life met a more overengineered, overcomplex spec than OSGi. Compatibility with OSGi should be an anti-requirement in any sane world. Unfortunately we live in this world :-(

It could be like a marketing feature of your module system: we've carefully engineered this solution so that you cannot possibly build anything to do with OSGi on top of it.

 
17. Jun 2014, 13:18 CET | Link

I was new to working with JavaOne, Jigsaw, JBoss modules. It was for the fist time I got a compiled report on how these modules can be brought about onto a single platform. Good post. Can we get some programs than can help us in making our work easy?

click here
 
30. Aug 2014, 03:47 CET | Link
polo

Best friend successive good years, Gucci Shoes Factory, winter spent in Sanya, Monster Beats Outlet, so winter home, seems to be nowhere in sight, North Jackets Outlet, both a little rusty, Nike Air Max Shoes, but also very cordial, Burberry Outlet Online, forward to tonight, feather-like snow, MCM Bags Outlet, drifts underground, Coach Black Friday, looking at that the floc, Louis Vuitton Outlet, fly like snow Ling, Michael Kors Outlet Online, eloquent, Polo Outlet Online, flying in the sky, Cheap Canada Goose, limp walk downs, strange things, Marc Jacobs Outlet Online, I float thinking lianpian, North Outlet Online, poetic heart wenqing, not help surging surging, Coach Factory Outlet, so I borrowed the winter, Ralph Lauren UK, snows research ink, Longchamp Sacs Sortie, into the mind of inactivity, Michael Kors Outlet, the white snow everywhere, Monster Beats By Dre, wrapped in some different, Ralph Lauren Outlet, kind of scenery, Oakley Sunglaases Outlet, wherever the wind in the faces, of the people, Michael Kors Bags Outlet, who are very Huddled, could not help.

Post Comment