Stanley Ho's Blog: Deployment Archives

In the past, the design work on modularity was split between two expert groups: JSR 294 was responsible for defining the language extension to support modularity in the Java programming language, while JSR 277 was responsible for defining the deployment aspect of the module system. The original rationale was that each expert group would have members with the most appropriate expertise to design what's best in each area for the Java platform. As it turned out, there were situations when experts needed to work at both the language and deployment levels, and a single expert group would have been more effective. To help make the discussions of modularity in Java more effective, Alex Buckley (the spec lead of JSR 294) has joined me to become a co-spec lead in JSR 277. In case you don't know Alex, he is *THE* language guy responsible for the Java Language Specification and the Java VM Specification, and I am very excited about this change. Our plan is to have all Java modularity discussions to occur in the 277 expert group from now on, and we hope this simplification will benefit everyone.

JSR 277 early draft review 2 specification (Coming soon)

Alex and I are currently in the middle of producing the JSR 277 early draft review 2 specification for the expert group to review and discuss. This specification will be quite different from the original JSR 277 early draft in the following ways:

1. New language support based on Alex's latest proposal. If you haven't been following the language discussion around modularity, the most significant change is that there will be a new module keyword in the Java programming language:

   module org.foo.app;
   package org.foo.app;
   module class Main {
      ...
   }

Defining a Java module will be as easy as declaring a module name using the new keyword. But ... what if you want to create a deployment module with metadata that could be used in the module system? Well, it will be as simple as defining a Java module with metadata annotations:

   //
   // org/foo/app/module-info.java
   //
   @Version("1.0")
   @ImportModules({
           @ImportModule(name="org.foo.library", version="1.0+")
   })
   @MainClass("org.foo.app.Main")
   module org.foo.app;

I won't dive into all the details here, but hope the example gives you some idea.

2. Incorporates inputs from EDR feedbacks and EG discussions on existing design and new features.

Since the original early draft was published, we have received many constructive feedbacks and most of them will be addressed in the upcoming specification. In addition, the specification will include details about resource modules (for internationalization), service/service-provider modules, etc. that have been defined by the expert group.

3. Reorganizes the specification to make the separation between the abstract module system framework and concrete module system implementation explicitly clear.

The original early draft actually has two separate parts: a framework for abstract module system, and a concrete module system implementation based on JAM (JAva Module). However, the distinction in that early draft was not clear because the focus of the original early draft was to gather feedbacks on the overall design rather than individual pieces. Bryan Atsatt, a very valuable contributor in the EG, recently suggested that a clear distinction between the two would help reduce a lot of confusion, and we agreed. This reorganization will happen and it will be one of the most obvious changes in the upcoming specification.

4. Validates the specification with the reference implementation.

We have been building the reference implementation (RI) through the Modules project in OpenJDK for quite some time now. The current RI has already implemented most of the functionalities as described in the upcoming EDR2, and we hope to bring the Modules project on par with the EDR2 around the same time when the specification is published. Stay tuned for more details.

Support OSGi bundles in the Java Module System

Mandy Chung and I have been working on a draft specification for supporting OSGi bundles in the Java Module System, and we have just made it available for the expert group to review and discuss. We understand that people who have invested heavily in OSGi would like to preserve their existing investment going forwards, and this is what we hope the support for OSGi bundles will enable. Check out Mandy's blog if you want to learn more.

JavaOne 2008

JavaOne is around the corner again. This year, Alex and I will be presenting a session and a BOF on modularity:

TS-6185: Modularity in Java™ Platform
Wednesday
5/7/2008
10:50 AM -11:50 AM

BOF-5032: Modularity in the Java™ Platform
Wednesday
5/7/2008
8:30 PM -9:20 PM

We'll go over the Java Module System from the language and deployment perspectives in details, and this will be a very technical and interesting talk. If you are attending JavaOne next week, we hope to see you in the session and BOF!

- Stanley

P.S. *random personal note* In the past year, I haven't been blogging much as I was on frequent leaves to deal with some family emergencies. The situation has been improving and I hope to blog more along with Alex and Mandy about all the exciting/interesting stuffs going on in modularity going forwards.

OpenJDK Modules project: Early snapshot, video, and more

Posted by stanleyh on June 28, 2007 at 03:36 AM | Permalink | Comments (0)

Early snapshot of JSR 277 and JSR 294 implementation

We have just made an early snapshot of the JSR 277 (Java Module System) and JSR 294 (Improved Modularity Support in the Java Programming Language) implementation available through the Modules project on OpenJDK:

http://openjdk.java.net/projects/modules/

This snapshot currently covers the core features (see Andreas's blog) described in the updated specification in JSR 277, and the reflective APIs defined in JSR 294. If you are wondering how the module system works internally and want to take an early look or even contribute, I encourage you to check out the Modules project.

Besides the snapshot, we have also made other goodies available:

A Getting started guide that helps you understand the source structure of the project.
A few samples that show you how to create and use simple modules.
Documentations that describes some of the tools and functionalities available, including

how to execute modules from repositories through the Java launcher.
jam tool - think of it as the jar tool for the world of modules.
visibility policy - a mechanism that allows you to pick and choose which modules to use in a specific deployment when there could be zillion of modules available from the repositories.

A NetBeans project (requires NetBeans 6.0 M9 or later) for easy browsing and editing of the relevant source files from the IDE.

Obviously, this is just the beginning. You should expect the snapshot will be updated periodically and new goodies will be posted going forwards, as we evolve the implementation and add many functionalities in the coming months.

If you are interested in discussing the implementation in the Modules project, we have made two discussion lists available for the Java community to join:

modules-dev@openjdk.java.net: Technical discussion about the implementation of the Modules project
modules-discuss@openjdk.java.net: General discussion of the Modules project and how to use modules

If you want to discuss the Modules project with its developers, or how to use JSR 277 and JSR 294, be a subscriber today!

JSR 277 on Google Video

A few weeks ago, Michal Cierniak (Michal has been spending part of his 20% time as a contributing member in the expert group) and I presented the Java Module System (JSR 277) as part of the Advanced Topics in Programming Languages Series at Google. This presentation was based on the current design described in the updated JSR 277 specification, and the video is now available online here. You could also google the video directly using "JSR 277" from the Google Video site. If you want to learn more about the current design of JSR 277, this would be a good place to start!

More on updating the JSR 277 specification ...

Since the early draft was available, I have been discussing the feedbacks we received from the community with the expert group and incorporating their inputs into an updated specification. This updated specification has evolved significantly from the early draft, and this is also what the recent discussions in the EG mailing list based on. To help those of you who are observers of the EG mailing list to follow the discussions more easily, I am going to make the updated specification (and possibly other strawmans as well) publicly available soon. Stay tuned!

More JSR-277 Early Draft Q & A

Posted by stanleyh on November 03, 2006 at 10:51 AM | Permalink | Comments (8)

Since the JSR-277 early draft became available, many comments have been raised by some reviewers. Some of the comments are valid concerns and good suggestions, and these are good inputs that will be discussed in the EG (Expert Group). On the other hand, some other are misconception and misinformation, and that's what I would like to address in this blog.

JSR-277 Early Draft Specification

Posted by stanleyh on October 27, 2006 at 06:00 AM | Permalink | Comments (18)

The JSR-277 early draft specification has recently been published - this is what I've been spending significant amount of time during the past year, and I'm very glad that it is finally available to the Java community for review.

What is JSR-277?

JSR-277 (Java Module System) is an architecture for the development and deployment of module-based applications and libraries. Applications and libraries written as Java modules are easier to develop and deploy, with first-class modularity, packaging, and deployment support in the Java SE platform.

New security dialogs coming to a Tiger update near you.

Posted by stanleyh on October 14, 2005 at 03:42 AM | Permalink | Comments (8)

A few months ago, I blogged about how we plan to revamp the user experience in Java Web Start and Java Plug-in in Mustang. After considering all the inputs from the Java community, we have decided to make the new security dialogs available in the upcoming J2SE 5.0u6. Here are some screenshots from 5.0u6:

JSR 277: Java Module System

Posted by stanleyh on June 14, 2005 at 12:03 PM | Permalink | Comments (6)

Sun has recently submitted the Java Module System JSR to revise the Java packaging architecture. This is an area that has been long overdue for an overhaul, and the goal is to make it easier to bundle, distribute, and deploy Java applications and Java extensions (aka optional packages).

Security and networking enhancements in Java Deployment

Posted by stanleyh on June 13, 2005 at 02:02 PM | Permalink | Comments (6)

In Mustang (JavaSE 6), there are many security and networking enhancements in Java Web Start and Java Plug-in that make your deployment more secure and simple. Let's have a quick look!

New user experience in Java Web Start

Posted by stanleyh on June 07, 2005 at 02:06 AM | Permalink | Comments (18)

As I mentioned in my earlier blog, we have decided to revamp the user experience in Java Web Start in Mustang, and the scary security dialog was the first to go. Here is more exciting news! I am very glad to announce that Andy Herrick and Margarita Fisher have completed the initial implementation of the new user experience for Java Web Start, and it is available in the promoted Mustang snapshot (build 39). You can download and try it out today.

Java Deployment in J2SE 5.0

Posted by stanleyh on June 05, 2005 at 06:17 PM | Permalink | Comments (2)

Java Deployment is a term that collectively represents the set of deployment technologies available in J2SE, including Java Web Start for JNLP application deployment, Java Plug-in for Java applet deployment, JDK/JRE installer, Java Update, and many others. Let's have a quick look to see what new features and enhancements are available in Java Deployment in J2SE 5.0 (aka Tiger) for your next deployment.

Deployment: Understand JRE download size

Posted by stanleyh on May 06, 2005 at 01:56 AM | Permalink | Comments (9)

I talked to many developers recently about the Windows JRE download size issue. The conversation often went like this:

Stanley: What do you see as the major obstacle of your deployment?
Developer: JRE download size is definitely a problem, especially on Windows.
Stanley: Why?
Developer: The JRE is 25MB, and it is beyond what most consumers are willing to download.
Stanley: Actually, the full download size of JRE 5.0 is ~15MB, and you could get a minimal download of ~7.2MB if you use the online installer.
Developer: Really? I didn't know that. I thought the JRE was '25MB' because that's what I've always heard.

Obviously, there are some misunderstanding among Java developers about the JRE download size. It is time to do a reality check!

Deployment: Goodbye scary security dialog box!

Posted by stanleyh on April 30, 2005 at 12:22 AM | Permalink | Comments (83)

During the post-Tiger planning, we talked to numerous developers to determine what features and enhancements we should work on in Mustang. Many feedbacks we received are related to the user experience in Java Web Start, especially around the security warning dialog box for signed application.

Powered by
Movable Type 3.01D

java.net RSS Feeds