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

41–50 of 59 posts

Re: Java 9: The State of the Module System

#41

Post by uxcn »

pjmlp wrote: post #38

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.

Is there an actual JSR for reified generics? I was under the impression that would generally break VM compatibility.

I have a hard time believing Google will stop supporting Java on Android, especially considering how widely they support it for other various platforms. I do know Go support for Android was recently released though.

Re: Java 9: The State of the Module System

#42

Post by pjmlp »

uxcn wrote: post #41
pjmlp wrote: post #38

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.

Is there an actual JSR for reified generics? I was under the impression that would generally break VM compatibility. I have a hard time believing Google will stop supporting Java on Android, especially considering how widely they support it for other various platforms. I do know Go support for Android was recently released though.

> Is there an actual JSR for reified generics? I was under the impression that would generally break VM compatibility.

Not yet. But it might happen, it depends how value types get implemented.

Check "New Bytecodes, New Objects", "Adventures on the Road to Valhalla":

http://www.oracle.com/technetwork/java/javase/community/jlss...

> I have a hard time believing Google will stop supporting Java on Android

Of course they won't stop supporting it. After all they stated at Google IO 2014, that only Java matters and they could not see why anyone would want to use something else.

But they also don't show any interest to reduce the gap with the official Java.

Even the actual version lacks many of the Java 7 libraries.

> I do know Go support for Android was recently released though.

It doesn't have any official support from the Android team.

Re: Java 9: The State of the Module System

#43

Post by hinkley »

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).

The jar files used to be memory mapped, and as far as I'm aware they still are. So there should be a noticeable improvement in seek time by eliminating never-used files.

You could also perhaps be looking at a situation in the future where the JRE can selectively exclude things at install time, which would be nice.

Re: Java 9: The State of the Module System

#44

Post by uxcn »

pjmlp wrote: post #42
uxcn wrote: post #41

Earlier quoted context omitted.

Is there an actual JSR for reified generics? I was under the impression that would generally break VM compatibility. I have a hard time believing Google will stop supporting Java on Android, especially considering how widely they support it for other various platforms. I do know Go support for Android was recently released though.

> Is there an actual JSR for reified generics? I was under the impression that would generally break VM compatibility. Not yet. But it might happen, it depends how value types get implemented. Check "New Bytecodes, New Objects", "Adventures on the Road to Valhalla": http://www.oracle.com/technetwork/java/javase/community/jlss... > I have a hard time believing Google will stop supporting Java on Android Of course they…

Interesting, thanks for the links. Honestly, I tend to avoid writing Java in favor of native languages at this point largely because of latency requirements. I still wonder where code sharing outweighs the type cast overhead for most JVMs though.

> It doesn't have any official support from the Android team.

Go on Android definitely seems to be in its infancy.

Re: Java 9: The State of the Module System

#45

Post by skrebbel »

The cool thing is that compared to many languages/platforms, Java already has an excellent module system. Just look at the horrible hacks you have to go through in C++, Ruby or Python to manage multiple projects written in different versions of the language or with different versions of dependencies are just ridiculous, especially if you're developing on multiple platforms. Oh, you want to deploy it too? Have fun.

Let alone the IDE support. I think it's truly amazing that I can make a project with 3 different JVM languages and get instant IDE autocompletion and warnings when calling methods between those languages. The source -> .class -> .jar thing has turned out to be a remarkably visionary design (or just a very lucky hit). For comparison, C# still compiles and "tools" that much slower because .class files are missing in the pipeline.

It's a testament to some of the true goodness of Java, despite its unpopularity in hipper circles, that they don't think a Maven-managed folder full of JARs is good enough.

Of course, this is really a JVM thing and you'll also get it if you use a different JVM language so you can actually get the best of both worlds.

Re: Java 9: The State of the Module System

#46

Post by aabbccdd »

skrebbel wrote: post #45

The cool thing is that compared to many languages/platforms, Java already has an excellent module system. Just look at the horrible hacks you have to go through in C++, Ruby or Python to manage multiple projects written in different versions of the language or with different versions of dependencies are just ridiculous, especially if you're developing on multiple platforms. Oh, you want to deploy it too? Have fun. Le…

Are there any horrible hacks needed for Ruby to cope with dependencies? Is this something new or you're just ranting?

Re: Java 9: The State of the Module System

#47

Post by needusername »

syjer wrote: post #32
needusername wrote: post #23

Earlier quoted context omitted.

> 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 expressin…

> For the purpose of modularizing the Java SE Platform’s reference implementation, .... Whether this new format, provisionally named “JMOD,” should be standardized is an open question.

That just talks about the JDK. There is no promise that normal applications can use this format.

Re: Java 9: The State of the Module System

#48

Post by skrebbel »

aabbccdd wrote: post #46
skrebbel wrote: post #45

The cool thing is that compared to many languages/platforms, Java already has an excellent module system. Just look at the horrible hacks you have to go through in C++, Ruby or Python to manage multiple projects written in different versions of the language or with different versions of dependencies are just ridiculous, especially if you're developing on multiple platforms. Oh, you want to deploy it too? Have fun. Le…

Are there any horrible hacks needed for Ruby to cope with dependencies? Is this something new or you're just ranting?

My experience with this is a bit dated so maybe they fixed it since, but here goes: Gems are installed globally on your system. You need something like RVM to work around this, but oops, RVM doesn't work on Windows and one of your devs uses that. There's a 3-year old tutorial about how you can get it to work with cygwin, but that doesn't work well with your favourite Ruby IDE, and the list goes on. You want to deploy to a server so you try to use bundler, but bundler hard-copies a dependency called somelib-mingw-x86 into the Gemfile.lock and your linux server chokes on that. In general, the idea that bundler makes a different dependency graph depending on the OS of the dev that happens to run "bundler install" is completely beyond my understanding.

I assume that it's a bit better if all your devs (and your servers) are on the exact same OS, but compared to say NodeJS or Java, the Ruby experience is pretty messy. With Node or Java, I just say "these are my dependencies", some package manager downloads them all into a subdirectory, and then I run the app. Done. The only global dependency is the VM itself, which is typically backward compatible so no problem there, just use the latest one. C# has it just as awesome except that some libraries were written by boneheaded Windows-only people (hardcoded backslashes in pathnames, Windows Registry dependencies, stuff like that), so in practice it isn't as cool.

Re: Java 9: The State of the Module System

#49

Post by smrtinsert »

wiradikusuma wrote: post #7

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

That's a naive solution. OSGi has a very specific target of embedded applications. Thanks to its classloader, its a headache to port existing libraries which weren't written with its classloader in mind. This leads to duplicate osgi safe versions in custom artifact repos.

In the end, not a solution, but a very nice environment and development choice if you are greenfield and in the target audience.

Re: Java 9: The State of the Module System

#50

Post by needusername »

HiYaBarbie wrote: post #24
needusername wrote: post #13

Earlier quoted context omitted.

They say that but I don't know anybody who actually uses classpath (java -cp). Most people use a custom class loader, container and module system. In addition Oracle cops out of versioning. So I'm not sure who they are targeting.

> Most people use a custom class loader, container and module system. Huh? That sounds like a lot of work reinventing the wheel. Could you give me some details on how that's arranged?

The most extreme example is probably WildFly that has just the JBoss Modules JAR in the class path. That sets up class loaders for the modular service container that in term sets up class loaders for all the deployments.

Every Java EE server (even Tomcat) sets up its own class loaders. So does Jenkins/Hudson, Maven, all RCP platforms, even applets. It's really rare to find applications where all the code is in the class path.

Post reply on HN