Java 9 Maven, Compile Errors, Module Names, Kill Switches
CodeFX Weekly #13 — 7th of April 2017
another week of fiddling with Java 9… Boy, I really hope you’re stoked for it because otherwise this newsletter will get (or rather continue to be) really boring for you.
I send this newsletter out every Friday. Yes, as an actual email. Subscribe!
On SitePoint we’ve just published a post I was looking forward to for weeks: Why Maven Cannot Generate Your Module Declaration. No other than Robert Scholte himself, chairman of the Apache Maven project, explains why we’ll have to keep it in sync manually (or hope for IDE support).
To declare modules for Java 9's module system we need to create a file module-info.java - a so called module…www.sitepoint.com
Then, I went deeper into porting a large project to Java 9. It is built with Maven, of course, so one of the things I had to do was get the two to play together. In case you’re not clear of what options exist to do that (because I wasn’t), I started to collect them in a small project as I found them. You’re welcome.
In case you’re trying to use some of the new command line options like
--add-modules, be aware that putting the following into your
pom.xml doesn't work:
You’ll got errors like the following:
[ERROR] COMPILATION ERROR :
[ERROR] javac: invalid flag: --add-modules java.xml.bind
Usage: javac <options> <source files>
use --help for a list of possible options
Apparently it’s common knowledge that
<arg> will put arguments that contain a space into quotes before passing them (which in turn
javac doesn't like in this instance), so you'll have to do the following instead:
I blogged about how optional dependencies can be established in the module system.
Some examples build on of a small demo application, called the Service Monitor. To nail down where exactly the…blog.codefx.org
Encapsulation Kill Switch
A while back I wrote about reflection versus encapsulation in light of the module system. Since then a new flag,
--permit-illegal-access, was introduced into the JVM and I extended my post. To save you the clicks and the search the new part comes right here:
If all of this seems too cumbersome and you just want to get it working for your class path application,
--permit-illegal-access, amicably dubbed the encapsulation "kill switch", is the right command line argument for you. With it, all code in the unnamed module can access other types regardless of any limitations that strong encapsulation imposes. In exchange you get warnings on illegal accesses and the stifling feeling of living on burrowed time because the option will only exist in Java 9 to ease migration (so you just bought yourself two, three years).
Here’s how to launch with owner on the module and intruder on the class path:
And here’s the result — note how the warnings screw with my carefully created output:
WARNING: --permit-illegal-access will be removed in the next major release
public:WARNING: Illegal access by intruder.Intruder (file:/home/nipa/code/JigsawEncapsulation/mods/intruder.jar) to method owner.Owner.publicMethod() (permitted by --permit-illegal-access)
✔ protected:WARNING: Illegal access by intruder.Intruder (file:/home/nipa/code/JigsawEncapsulation/mods/intruder.jar) to method owner.Owner.protectedMethod() (permitted by --permit-illegal-access)
✔ default:WARNING: Illegal access by intruder.Intruder (file:/home/nipa/code/JigsawEncapsulation/mods/intruder.jar) to method owner.Owner.defaultMethod() (permitted by --permit-illegal-access)
✔ private:WARNING: Illegal access by intruder.Intruder (file:/home/nipa/code/JigsawEncapsulation/mods/intruder.jar) to method owner.Owner.privateMethod() (permitted by --permit-illegal-access)
As I’ve said, this only works if the intruder comes from the unnamed module. The rationale behind that is that properly modularized code, meaning code that lives in modules, should not need such hacks. Indeed, if we put both artifacts on the module path, we can see that the flag is not exercised (no warnings beyond the initial one) and access fails because the internals of
owner are strongly encapsulated:
WARNING: --permit-illegal-access will be removed in the next major release
public: ✘ protected: ✘ default: ✘ private: ✘
WTF, Java 9?!
While porting I found some things I didn’t know would break on Java 9, so far case particularly around type inference. This for example, compiles fine on 8, not so much on 9:
Now, I don’t want to argue whether that should compile or not — I’m just saying it doesn’t any more. I already ran into trouble with Hibernate as well and am sure there are more things to come.
I started collecting such problems in a project called Java 9 WTF (because, why not?) and contributions are very welcome! Let’s show people what they can do to fix the small things so they can focus on the big challenges — Gosling knows, there are enough of them.
A question on StackOverflow was how should I name my Java 9 module?. This is particularly interesting because there are in fact two opinions. The one that is well-known from packages (inverse domain) and the new one (pick whatever, preferably something short).
The second one does not come from just anybody, no, it’s the JDK team itself, particularly Marc Reinhold, who recommend it. Have a look at the answer for details.
I’m giving a course for fourth/sixth semester students in which I want to teach them how software development works (as opposed to mere programming). To that end I plan to teach them the basics in Git, GitHub, Maven, Travis, and JUnit. With this under their belt, they should be able to set up their own projects and participate in others without too much hassle.
I recently gave the first lecture and made it about Git. But, and this is why I’m writing about this, because the university is ~2 hours away I did it via YouTube Live. Wow, that was interesting!
I used Open Broadcaster Software (OBS) for that and have to say that I was delighted how smooth everything went (remember, I’m on Gentoo Linux). Arranging webcam and screen capture feet was a breeze and sound worked well too (after some fiddling). There is a 15 second delay from me to them, which can be a little confusing when I want them to ask questions, and not seeing your audience is weird in its own way but it was fun and I think well-received.
One other reason why I wanted to experiment with it is that I think about starting a YouTube channel with Java stuff when I’m done writing the book (which current estimates say will happen sometime late 2023). I guess it would be something similar to this weekly in video form: random (Java) stuff I find interesting. What do you think — would you want to watch something like that?
I further pimped
git log (I call it
got look now):
git log --graph --pretty=tformat:'%Cred%h%Creset (%Cgreen%cd%Creset, %C(bold blue)%an%Creset): %s%C(yellow)%d%Creset' --date=format:'%d.%m. %H%M' --abbrev-commit
It has date, time, author, and colors. Beautiful!
I started disassembling my Lego megaset (I finished it shortly after mentioning it last time). This may not be the most interesting news to you but I gotta tell you, it’s emotionally taxing to undo the 20 hours I spent building it. But without destruction there’s no change.
Project Of The Week
(Why did I call this “Lib of the Week”? That was just stupidly narrow.)
Sticking with the Maven/Jigsaw theme, have a look at ModiTect:
The ModiTect project aims at providing productivity tools for working with the Java 9 module system (“Jigsaw”).
Currently the following tasks are supported: Generating module-info.java descriptors for given artifacts, adding module descriptors to existing JAR files, creating module runtime images.
In future versions functionality may be added to work with other tools like jmod etc. under Maven and other dependency management tools in a comfortable manner.
I’ll definitely keep an eye on it and at least open issues for potential features.