JPMS EG Meetings, Compact vs Compressed Strings, and The Unfollowing

CodeFX Weekly #20 — 26th of May 2017

Hi everyone,

JSR 376 is still hanging in the balance, so I’ll start by summarizing the recent developments, which were marked by some concessions and some resistance. And since I’m pretty much spending all my time with Java 9 these days, I have some details about that to spare (compressed vs compact strings and what’s up with the java.se module) before I meander into Twitter habits.

Oh, one more thing: Last week I presented my Java 9 talk at JUG Ostfalen and the video is online now.

I send this newsletter out every Friday. Yes, as an actual email. Subscribe!

JSR 376 Expert Group Minutes

The expert group started meeting regularly on May 18th and the first minutes of those meetings were published recently. The first meeting was not overly eventful. Noteworthy are the confirmation of two proposals:

• allow illegal access via reflection by default until the next release
• manifest file can define an automatic module’s name

Kind of apropos was this item:

The first item has been mentioned by a few people from Oracle at a couple of JCP EC meetings, and discussed informally at recent developer conferences. The general idea is that the ecosystem would be better served by a more-rapid release cadence for Java SE and the JDK. Since the inception of Java, big features or a handful of big features have driven major releases every two to three years. This was reasonable in the 1990’s and 2000’s. Going forward, Java needs to move at a faster pace in order to remain competitive. People are therefore exploring the possibility of shifting to a yearly or even a six-month cycle. If a big feature is ready, it goes in; otherwise, it waits for the next release. There is no formal proposal at this time; however, discussion is expected in the JCP and OpenJDK communities in the next few months.

This is not brand new information but not exactly public knowledge either. What do you think about it?

Monday’s meeting (May 22nd) made a significant step by resolving the discussion around concealed package conflicts, a major concern that caused Red Hat and IBM to vote “No” on the last ballot:

[E]verybody agrees that this is something that the module system should support. Everybody is disappointed that this is not addressed in the initial release. There is broad agreement from Rémi [Forax; independent], Mark [Reinhold; Oracle’s spec lead], and Tim [Ellison; IBM] that there are still technical issues that need to be considered and a solution should not be rushed. David [Lloyd; Red Hat] was not happy that there was no temporary solution and expected members of the community to share to share his disappointment, but did not have any better ideas.

JSR 376 Ballot and Automatic Modules

Another decision was to continue disallowing cyclic dependencies between modules:

[E]verybody seemed to agree that cyclic dependencies could become a problem at run time. In theory there was no aversion to having a different runtime response; however, additional, non-trivial analysis was required. Once there is confidence in a solution, the runtime behavior could be changed at that time.

Then discussion came back to layer primitives, a few methods that allow manipulating modules at run time. David Lloyd, who would want to see them in the first release to use them for the JBoss module system, and Mark Reinhold, who is opposed because this API was not designed to be supported long-term, continued to argue about it and reached no consensus. It does not look like Mark will make any changes here.

The minutes for later meetings are not yet online…

Java 9 Code

I continued fighting with the Maven JAXB2 Plugin (despite its name, it’s not official) over bindings and conceded for now. I did find out, though, that xjc as well as the org.glassfish.jaxb:jaxb-xjc project do their job - it's just the damn plugin that drops the ball somewhere! If you want to help out, have a look at this GitHub project.

CodeFX-org/java-9-wtf

Other than that I wrote two answers on StackOverflow…

Compact Strings (Java 6) vs Compressed Strings (Java 9)

What’s the difference between the two? Answer:

Compressed strings (Java 6) and compact strings (Java 9) both have the same motivation (strings are often effectively Latin-1, so half the space is wasted) and goal (make those strings small) but the implementations differ a lot.

Compressed Strings

In an interview Aleksey Shipilëv (who was in charge of implementing the Java 9 feature) had this to say about compressed strings:

UseCompressedStrings feature was rather conservative: while distinguishing between char[] and byte[] case, and trying to compress the char[] into byte[] on String construction, it done most String operations on char[], which required to unpack the String. Therefore, it benefited only a special type of workloads, where most strings are compressible (so compression does not go to waste), and only a limited amount of known String operations are performed on them (so no unpacking is needed). In great many workloads, enabling -XX:+UseCompressedStrings was a pessimization.

[…] UseCompressedStrings implementation was basically an optional feature that maintained a completely distinct String implementation in alt-rt.jar, which was loaded once the VM option is supplied. Optional features are harder to test, since they double the number of option combinations to try.

Compact Strings

In Java 9 on the other hand, compact strings are fully integrated into the JDK source. String is always backed by byte[], where characters use one byte if they are Latin-1 and otherwise two. Most operations do a check to see which is the case, e.g. charAt:

public char charAt(int index) {
    if (isLatin1()) {
        return StringLatin1.charAt(value, index);
    } else {
        return StringUTF16.charAt(value, index);
    }
}

Compact strings are enabled by default and can be partially disabled — “partially” because they are still backed by a byte[] and operations returning chars must still put them together from two separate bytes (due to intrinsics it is hard to say whether this has a performance impact).

More

If you’re interested in more background on compact strings I recommend to read the interview I linked to above and/or watch this great talk by the same Aleksey Shipilëv (which also explains the new string concatenation).

What’s up with the Java 9 module java.se?

Answer:

As far as I can tell the main reason is compatibility with non-modular Java EE code. When code that has no module declaration or descriptor (which defines its dependencies) is compiled or launched, the question arises which modules from the JDK it is allowed to “see”.

If those were all modules in the JDK, then the Java EE ones would “overshadow” any Java EE implementations that are put onto the class path. This is a peculiarity of the interaction between modules and the class path (which ends up in the unnamed module): if a package is present in both a regular module and the unnamed one, the latter will be effectively invisible.

To remedy that fact not all modules will be visible for code on the class path. Instead, module resolution (which resolves an application’s dependencies) will begin in the root module java.se, thus ignoring Java EE modules.

For a more detailed explanation, have a look at this mail from Alan Bateman, in which he explains the change of the corresponding JEP 261.

The Unfollowing

A few weeks ago it happened again: Something important was going on and people tweeted about it. So far not noteworthy but what pissed me off was that I initially missed it and got the news a couple days late. That’s not what’s supposed to happen!

But of course it does… I long ago gave up on reading my entire stream and accepted that some things will get past me. But if it happens with interesting developments like hotly discussed changes in Jigsaw, which I think was what tripped me off, it questions the very foundation for why I use Twitter.

Something had to be done! Well, there are not too many ways to go about this… Whenever I saw a tweet that I though I could live without I checked the person’s history and made a decision based on the quota of interesting tweets (the higher the better) and the number of tweets (the lower the better). I quickly realized a few things:

• developer advocates tweet way too much about the conferences they’re at
• some very interesting people tweet way too much about non-technical topics
• the Pareto Principle holds: by unfollowing little more than a dozen people I seem to have cut the number of tweets almost in half

I followed a few people back with a different account, which I don’t pay close attention to and which mainly follows accounts spouting politics and weird humor.

Project of the week

I saw Capsule a few months back and recently came across it again:

Capsule is a packaging and deployment tool for JVM applications. A capsule is a single executable JAR that contains everything your application needs to run either in the form of embedded files or as declarative metadata. It can contain your JAR artifacts, your dependencies and resources, native libraries, the require JRE version, the JVM flags required to run the application well, Java or native agents and more. In short, a capsule is a self-contained JAR that knows everything there is to know about how to run your application the way it’s meant to run.

It will be particularly interesting to see how Capsule can interact with Java 9’s jlink, which not only allows creating a reduced Java runtime but also to include application modules in it.

Capsule

Shots

• two translations involving awesome German: one about Volkswirtschaftslehre, the other about Trump being a whiny bitch
• the pope being snarky
• threat levels (it’s John Cleese, so you know it’s funny!)
• tutorial vs real life

so long … Nicolai

PS: Don’t forget to subscribe or recommend! :)