Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 9: The State of the Module System

openjdk.java.net

Post reply on HN
Print view View original

31–40 of 59 posts

Re: Java 9: The State of the Module System

#31

Post by lighthawk »

MrBuddyCasino wrote: post #8
dj-wonk wrote: post #4

Earlier quoted context omitted.

According to the article: "A module’s declaration does not include a version string, nor constraints upon the version strings of the modules upon which it depends. This is intentional: It is not a goal of the module system to solve the version-selection problem, which is best left to build tools and container applications." I'm surprised by this as well. I was somewhat expecting Java 9 to tackle the dependency versio…

I'm glad they didn't. Its not essential to solve the problems the module system is designed to solve, making adoption easier. A mechanism to resolve, download and cache artifacts is still needed anyway, at least I didn't see anything in that regard.

> I'm glad they didn't. Its not essential to solve the problems the module system is designed to solve, making adoption easier. A mechanism to resolve, download and cache artifacts is still needed anyway, at least I didn't see anything in that regard.

But, had they included versioning support, they could have also built upon that later to support module distribution to finally not have to worry about maven, ivy, etc.

The main difficulty about versioning though are snapshot (development) versions that don't have a defined version number. In maven, typically these are just "*-SNAPSHOT" which may not be unique enough if two projects wanted to depend on two different snapshots of the same module.

Re: Java 9: The State of the Module System

#32

Post by syjer »

needusername wrote: post #23
syjer wrote: post #20

Earlier quoted context omitted.

>Except they don't mention at all how a module system should lead to faster boot times. They will switch from the basic jar (zip) format to a more optimized one. Additionally, with a modularized jre, it will load less modules (who use corba?). I'm quite sure there are additional reasons, but it's the 2 that I remember.

> They will switch from the basic jar (zip) format to a more optimized one. Straight from the article: > A modular JAR file is like an ordinary JAR file in all possible ways, except that it also includes a module-info.class file in its root directory. > A modular JAR file can be used as a module, in which case its module-info.class file is taken to contain the module’s declaration. It can, alternatively, be placed on…

That's why it's called a modular jar. There is also this "jmod" file described as:

"For the purpose of modularizing the Java SE Platform’s reference implementation, the JDK, we will introduce a new artifact format that goes beyond JAR files to accommodate native code, configuration files, and other kinds of data that do not fit naturally, if at all, into JAR files. This format leverages another advantage of expressing module declarations in source files and compiling them into class files, namely that class files are independent of any particular artifact format. Whether this new format, provisionally named “JMOD,” should be standardized is an open question."

Edit: from http://mreinhold.org/blog/jigsaw-modular-images

"The internal files rt.jar, tools.jar, and dt.jar have been removed. The content of these files is now stored in a more efficient format in implementation-private files in the lib directory."

Re: Java 9: The State of the Module System

#33

Post by syjer »

chrisseaton wrote: post #21
syjer wrote: post #20

Earlier quoted context omitted.

>Except they don't mention at all how a module system should lead to faster boot times. They will switch from the basic jar (zip) format to a more optimized one. Additionally, with a modularized jre, it will load less modules (who use corba?). I'm quite sure there are additional reasons, but it's the 2 that I remember.

The JVM already only loads classes on demand so if you don't use Corba it doesn't have any impact on you (maybe minuscule extra seek time reading the JAR).

Clear, but the single rt.jar will be replaced with a more convenient representation, so, as you said, the seek time will be reduced.

Re: Java 9: The State of the Module System

#35

Post by pjmlp »

smithkl42 wrote: post #34

I've used C# for a long time, but have barely touched Java. How does this differ from the idea of "Assemblies" in the .NET world?

This is like .NET modules.

It will allow a group of jars to be exposed as a single entity, with internal APIs that can be exposed across jars, but not accessible outside the module.

Re: Java 9: The State of the Module System

#36

Post by iso8859-1 »

smithkl42 wrote: post #34

I've used C# for a long time, but have barely touched Java. How does this differ from the idea of "Assemblies" in the .NET world?

See http://www.25hoursaday.com/CsharpVsJava.html#assemblies (and the rest of that page)

and http://stackoverflow.com/q/90578/309483

Re: Java 9: The State of the Module System

#38

Post by pjmlp »

Yet another feature that Android devs won't get.

By the time Java 10 gets out, they can see how libraries that make use of modules, reified generics, value types, GPGPU integration, JIT plugins are out of reach.

Worse even, having library devs writing two versions of their libraries.

Google's fork of Java is leading to a Python 2 - 3 scenario.

Re: Java 9: The State of the Module System

#39

Post by pjmlp »

hitlin37 wrote: post #3

is this the same module thing that's coming up in c++17( or later, it it doesn't make on time.)

No.

C++ modules are more like packages.

Java modules, which happen to exist in other languages like .NET, Delphi and Ada, are akin to having a set of dynamic libraries exposed as a single library. With the ability of having symbols that are only visible to the dynamic libraries that are part of the same module.

Re: Java 9: The State of the Module System

#40

Post by njitram »

wener wrote: post #26
wiradikusuma wrote: post #7

Or, you know, you can use OSGi ( http://www.osgi.org/Main/HomePage )

Use complex to achieve simple, that's Java Style, :P

OSGi isn't that complex, it's more that modularisation is inherently complex and people try to wave that away. When thinking modularisation through you quickly end up wanting depencency managament, versioning, modules and dynamic updates (meaning no restart of the VM when updating a module), and combining all of this is inherently difficult to design, and some of the stuff the JVM wasn't really designed for from the beginning. OSGi solves all that in a quite nice way, but for political reasons Oracle doesn't want to use OSGi ('not invented here syndrome').
Post reply on HN