OpenJDK10, OpenJFX 11... wtf

So here I am after 20 years coding in Java without any problems… because it is basically one of the easiest platforms around to make stuff work with. Usually. Once upon a time.
Up till now it was just, java -cp and maybe a -Djava.library.path and stuff worked. It really wasn’t complicated. Compiling worked in the same way too. It is this very simplicity that has made java just so excellent for everyone and productivity in general. I use C at work on a day to day basis and I cannot describe just how much bullshit there is to making anything in C. It is literally insane - that is, no rational person would start out today trying to make the C toolchain behave the way it does. I spend days - actual whole, multiple days - just pulling my hair out trying to figure out what bullshit thing has gone wrong and how to fix it. Then I do a bit of java and it’s all “ahh it just works, job done, move on”.

Until, that is, today.

Today I decided to try and use JDK10 (OpenJDK10 to be precise), and OpenJFX11, which comes in the form of “jmods” as well as an SDK download.

Little did I realise as I poked my little nose into the rabbit hole how deep it would go.

The module system is just batshit insane. It is the most crazily over-engineered complex bollocks I’ve seen for a while, and it seems to have been designed by the sorts of people who enjoy tools like Maven and Gradle and J2EE. I don’t think it really solves any problems and it creates so much complexity in using Java I just don’t even know what to say.

So … 20 years Java vet here, and I can’t even fucking make Hello World run in JavaFX. I spent all day trying. Someone help me out. FWIW I’m using Eclipse Photon 4.8.

Cas :slight_smile:

Probably you have at least double years experience in java then I have, but for learning the new java modules for me the best was this course:

I tried to read lots of tutorials/docs, but all of them fail somewhere. This guy clearly explains everything, starting with jars on class path and sublime editor. This is my best recommendation for you.

I finished it yesterday and successfully migrated my tiny engine to java9, even solving automatic module jlinking stuff, so if you specify your problem, I might be able to help you too :slight_smile:

So, bearing in mind the code has all actually compiled perfectly successfully, when I run it I get a single line of output:

Error: JavaFX runtime components are missing, and are required to run this application

All the JavaFX .jar files from OpenJFX are present in the classpath. I had it briefly working using the modulepath instead but there seemed to be some sort of weird problem with Eclipse and it would fail to run the second time so I’ve just reverted back to jars-on-the-classpath.

With the jars on the classpath, it’s compiling just fine. At runtime though - derp. Just that one line of output.

Cas :slight_smile:

When using modules, you have to compile with module path kinda parameters, just almost the same as you used javac before. I really recommend to take a look on that course as before I thought the same about jigsaw, after I’m happy that java introduced it :slight_smile: Also, it clearly explains the diff between the old way and the new way. Grab a beer and go watch it :slight_smile:

If you wont succeed, I’ll create a javafx demo for you tomorrow, but without ecliose :slight_smile:

Thing is I’ve actually got my head round the whole module-info.java thing. I successfully made a module out of my hello world and it ran. Once. Then Eclipse sort of got confused and it wouldn’t work any more and I don’t know why, which is why I’ve reverted to using jars on the classpath instead.

How do I get this crap working in Eclipse, properly, the way it’s meant to work?

Cas :slight_smile:

So, I just added a module-info.java thusly:


/**
 *
 */
module hello {
	exports hello;

	requires javafx.base;
	requires javafx.graphics;
}

… and now it runs ok. However this module-info.java is located in the default package, not in the “hello” package which is where I was expecting it to have to be located. In fact I was expecting it to not work.

Cas :slight_smile:

Eclipse suffered another funny turn when I tried to move module-info.java into the correct package location. Eventually I did it just using the system explorer and did a clean and build. So far so good. Still works.

… Noticed that Eclipse has now moved all my jars out of the project’s classpath and into the modulepath instead, automatically. Gah. Fine.

To confound matters I now realise that I was using OpenJDK11 EA and not JDK10 as I first thought (accidental misconfiguration). I will now try it with OpenJDK 10…

Aaaaand… it’s broken again… Switched to OpenJDK10. Eclipse now says there’s an error in module-info.java - exports hello apparently is now an empty package. (That’s where the HelloWorld.java lives, obviously). Clean/build doesn’t fix it. Grr. Switch back to OpenJDK11…

Error: JavaFX runtime components are missing, and are required to run this application

I have no words.

Cas :slight_smile:

Welp, it looks like most of the problems I’m having are that Eclipse is basically broken when it comes to modules.

If I put the module-info.java back in the wrong place - in the default package - everything settles down again (after having manually deleted the one in the right place and cleaning and building again because Eclipse throws a bunch of exceptions and doesn’t work).

I am not filled with confidence. But at least… I’ve got OpenJDK10 now running OpenJFX11.

Cas :slight_smile:

[quote=“princec,post:8,topic:59632”]
That IS the correct place, you can’t put module-info.java anywhere but in the default package. There’s a module per source root. If you need to work with multiple modules, then you need multiple source roots with a module-info.java in each one. You can’t have a “hello” package and a “world” package under the same root and make those two different modules.

On Eclipse, my understanding is that they basically ignored Java 9 & 10 and are waiting for Java 11 - the first LTS release after Java 8 - to properly support modules. LWJGL users have reported all kinds of issues and for many months (before and after Java 9) module support was entirely broken. Even now you can’t get LWJGL to work in a modular build (Bug 534624), will be fixed in 2018-09 M3 apparently.

I tried the Java 11 beta with Photon 4.9 M2 but it was even buggier so I’ve left that alone for now.

Explanations about the module-info.java are shall we say… mixed. But yes, thanks Spasi, you’ve confirmed my suspicions that it belongs in the root folder, and that’s what’s working. So a combination of massively overengineered design, totally broken IDEs, and misleading tutorials on the internet got me here. I’ve already come across the LWJGL issues too :expressionless: But it’ll be nice when it works.

Cas :slight_smile:

I couldn’t get modules to work with Eclipse. This is why for the tutorial I just posted, I manually created the module structure and copied over the source. I don’t know if NetBeans has done any better.

The sooner the IDE’s get up to speed on this the better.

Looking forward to reading tutorial cited above by mudlee.

I suspect you don’t actually need javax.base in your module-info, but it doesn’t hurt to have it there.

A posting of info on setting up a project with OpenJFX 11 could be very helpful. Seems like there must have been quite a few gotcha’s to create that much aggravation.

Does this mean I can’t write simple applications and compile via old-fashioned terminal commands?

So many confusion here… Guys, the course I linked above, has a module system section, which takes you around 2hours to check. Like a good movie :slight_smile:

But anyways, here are what I know:

  • You don’t have to use modules. It’s just an option
  • If you use modules, you can define strictly visibility for packages, even for reflections, which is really cool, I’ve programmed in Rust, C#, C++, PHP, Typescript, etc, but never seen a better solution
  • You can use it for services with ServiceLoader
  • As the whole JDK is now modularised, you can create your own JRE with jlink, ship your game with it without expecting the user having java. In my experience, I built a JRE that took 28MB only!
  • If you use modules, but one of your dependencies is not modularised, java handles it, and treats it as an “automatic module”, which mean it will export all of its packages by default
  • You can’t jlink automatic modules, but there is a solution for that, I wrote about it here: https://medium.com/@mudlee/java9-module-system-and-self-contained-apps-af26424fccae
  • Intellij IDEA supports modules, as maven

I see mixed feelings on the internet, but I see negative ones where the author has not checked it out in detail, how it really works. One who spent some hours to learn it just wrote positive thoughts on this (me too).

Yes, IDEA works perfectly with modules and NetBeans also has full support since the recent 9.0 release. IDEA practically writes module-info.java for you (adds missing requires or even missing exports for inter-module dependencies) and any error messages are very clear. I don’t think moving off Eclipse is an option for princec though, that’s why I didn’t mention it.

For Maven projects, I recommended the moditect plugin. Can be used to add custom module-info to non-modular libraries for jlink builds.

I pity the poor “fool” that hasn’t been using Idea for the last 15+ years. ;D

Believe me I’ve tried to get into IntelliJ a few times but I’m just several times more productive with Eclipse. And besides we use Eclipse at work.

It is a shame the modules stuff is so broken after all this time - I thought I’d leave it a safe period before jumping in. It reminds me of the colossal clusterf*ck that Eclipse made of generics back in about 2005 ish which must have set a third of the Java developer base back by about 2 years in understanding generics.

Regardless, the whole module system is just daft. The problems 99% of developers had were almost entirely related to JDK licensing not technology. We had a complete game - with OpenGL and everything - packaged into just a 5mb, that had the entire JVM embedded into it. Or rather just the bits we needed. It was of course against the license, but it just goes to show. This was 15 years ago.

So… boom. Yes, you do have to use modules.

Cas :slight_smile:

I went from Visual Café to Idea and was relieved to find an IDE evolved from what I used before; I never spent much time w/ Eclipse. I haven’t been in the Java space as far as proggy proggy goes for a few years, but will return for the 2nd gen Android video engine effort w/ LWJGL hopefully! :D!! Re: your latter sentiment… I can’t comment on the official module system as of yet, but definitely don’t discount the daftness possibility and agree that there “could have been” a streamlined way to expose the bare minimum + OpenGL long ago.

I remember playing with NetBeans support for modules almost 2 years ago - the transition to Apache was really done at the worst possible time in that regard. And a lot of other stuff has only just been donated. Still, it’s getting there! :slight_smile:

Personally, having worked a lot with NetBeans, and the odd passing glance at OSGi, I like module systems a lot. Not sure about Java 9+ modules though. If anything it’s under-engineered - missing some actually useful stuff. And not sure whether it belongs at the core of the language.

Since the existence of OpenJDK there’s not really been a licensing problem in shipping a slimmed down JVM in whatever way you see fit!

“odd passing glance at OSGi”

Yep and yep… One of the years that I had a BOF selected (~'04) for JavaOne I attended an OSGi session that Peter Kriens was involved with and approached the fellow and asked if he was free for lunch; we then grabbed some food at the Metreon food court. At this time OSGi was just trying to break beyond a possible embedded use case into the Java mainline direction, so he was surprised of my interest. I never got around to figuring out how it could work for my efforts then and to now though was a bit bummed I suppose that from a design perspective the NIH syndrome created the module system that we have now for better of for worse…

It is my undeniably contrary opinion that the whole mechanism should have been nothing whatsoever to do with the JVM or the Java language.

Cas :slight_smile: