September 2015 - jpms-spec-comments

Oops wrong JDK module structure
by Benjamin Nice 24 Sep '15

24 Sep '15

Hi, Apologies for my last post as it was based on the JDK module structure in "The State of the Module System" paper where I should of looked at the module structure in JEP 200. Here the CORBA has already been factored into its own module and the module structure looks great. The only module I would recommend breaking up more (if the coupling allows) is the java.desktop module here Applets, AWT, Swing, Beans, Imageio, Print, Sound could be split into their own modules to form cohesive modules. Regards, Ben Nice.

1 0

JDK Modules
by Benjamin Nice 22 Sep '15

22 Sep '15

Hi all, I have been looking forward to modules in Java for a longtime. I attended the talks on modules at JavaOne in 2007. The second language I learnt at university was Modula 2. Anyway, what I want to ask about is level of granularity of the modules in the JDK. I would have though it would have made sense to split the likes of CORBA, Swing, AWT etc into separate modules reducing the size of base JDK especially since some of these are getting a bit long in the tooth and there is a lot of java programs that don't need a GUI or CORBA. The only reason I can think of not modulizing these is out is if they are tightly coupled with the rest of JDK. I would love to here comments from the group as why the modules around the JDK is so course. I guess they could be made into modules later? Regards, Ben Nice.

1 0

Support for multiple modules in one JAR-File
by Stefan Fuchs 12 Sep '15

12 Sep '15

Hi, reading the State of the Module System, I got the impression that a modular jar file can only contain one module. However, many applications, I have seen, fold all its dependencies into one big jar file (See [1]m [2] and [3] for tool support). This is done to: * reduce startup times for webstart applications * ease distribution and deployment * enable efficient obfuscating of the resulting jar (see [4]) So I think it is critical to support multiple modules in one jar file, if the module system is to be adopted beyond the jdk. In this context I find the convention, of placing a module-info.java or module-info.class in the root of the jar file, a poor choice. It should be named after the module name (e.g.: com-foo-bar-module-info.java). Besides, I think using a simple text file to declare the module dependencies would have been the better option. No special tools would be needed to inspect the dependencies of a jar file, when the source is not available. - Stefan [1] https://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html… [2] https://github.com/shevek/jarjar [3] https://ant.apache.org/manual/Tasks/jar.html [4] http://proguard.sourceforge.net/

1 0