Java Creator James Gosling Hired by Amazon Web Services (He’s Still Got it, Baby!)

Java creator James Gosling announced on May 22nd he was leaving Boeing (formerly Liquid Robotics) for Amazon Web Services. The announcement on Gosling’s Facebook page said he would start that day.

Analyst firm Redmonk,

It’s no secret that IT, which mirrors our larger culture, values youth. According to the article, young people tend to have more energy, work longer hours, and have fewer family committments, allowing them to devote more time and energy to work.

But there is value in experience, prompting XML spec co-author Tim Bray (who is 61) to coin a new tongue-in-cheek acronym: GaaS, or Geezers as a Service.

It’s not clear what Gosling will be doing at AWS. On his LinkedIn page he says he’ll be wandering around.

Redmonk said in their post that Gosling is “…just as likely to be designing a fleet of underwater delivery drones as driving programming language innovation.”

At Liquid Robotics, Gosling worked on autonomous robots like the one shown here on Liquid Robotics YouTube channel.

Gosling posted on Facebook on May 28th a link to the Redmonk article, along with this response, where he said:

“One of the things I really liked about Liquid Robotics was the balance of ages. Amazon Web Services is that way too, which was a huge attraction. It’s weird to now show up as a poster boy for the grey-haired crowd.”

The old saying goes, “There is no substitute for experience”. It would seem that AWS totally gets that.

Project Jigsaw (Java Platform Module System) Coming Together

On May 8th, the Java Community Process Executive Committee voted No on the public review draft of JSR 376, code named project Jigsaw.

The JCP process gives Expert Group for JSR 376 has 30 days from May 8th to update the draft, and resubmit it to the Program Management Office, who then will forward it to the Executive Committee, who then puts it up for a Reconsideration Ballot.

If that ballot fails, then the JSR is closed. And if JSR 376 is done, then the future of Java 9 is unclear. Or at the very least a end-of-July delivery is in doubt, if even possible.

But Expert Group member Tim Ellison of IBM seems optimistic that JSR 376 will pass on the Reconsidertion ballot, and said this in a May 26th blog post following a series of expert group meetings he attended, held on May 18th, 22nd, and 23rd:

“… the Expert Group organized itself quickly around a series of real-time meetings that provided an immediate, productive, and healthy forum for discussion. While our preference is always for an open conversation including the broader community, we understand that sometimes such focus requires a “heads-down” working meeting. This was one of those times, and [the meetings] were very valuable as we were able to reach a much closer consensus… We look forward to seeing this revised specification being re-presented to the JCP EC, and expect the EC to support the Expert Group in their conclusion.”

A major concern in the minds of many, myself included, is the migration path of existing applications to Java 9 that work just fine under Java 8. In particular, frameworks like Spring and Hibernate that use Deep Reflection to do their thing are vulnerable to Java 9’s strict adherence to modularity.

Java spec lead Mark Rheinhold in March announced the introduction of the “Big Kill Switch” to ease the migration path to JDK 9.

The Big Kill Switch is a command line option that permits illegal reflective access from classes on the CLASSPATH. So when you fire up the JVM, you pass the

--permit-illegal-access

flag, and now classes in any unnamed module (i.e., on the CLASSPATH) can use reflection.

Any code that performs illegal reflective access will cause the runtime to issue a warning every time it happens.

“… The strong encapsulation of JDK-internal APIs has, in
particular, triggered many worried expressions of concern that code that works on JDK 8 today will not work on JDK 9 tomorrow… To help the entire ecosystem migrate to the modular Java platform at amore relaxed pace I hereby propose to allow illegal reflective access from code on the class path by default in JDK 9, and to disallow it in a future release.”

If approved, the Big Kill Switch will no longer be required, and if the runtime detects any code from the CLASSPATH performing illegal reflection, it will issue a single warning at some point, and that’s it.

The issues modularity raises in the presence of code that uses reflection is a fairly complicated one, and I found this post at SitePoint to be very helpful in explaining it.

So what does this mean for JSR 376 and Java 9? The productive Expert Group meetings are definitely a good sign. But whether or not allowing illegal reflective access by default will ease concerns of members of the Executive Committee is anybody’s guess.

The 30 day window for the Reconsideration ballot closes on June 7th.

Be sure to tune in to future episodes of Java News and Code for updates on this story.

Code Talk-through: Java Language Type Erasure

Finally, for this episode’s code talkthrough, I’d like to take you on a tour of Java Type Erasure.

Type Erasure is a compiler technique used to make Java Generics work.

The reason Type Erasure works the way it does is for the sake of backward compatibility, which has always been a primary concern of the Java language maintainers.

I’d like to walk through some of the Type Erasure recipe I wrote for IBM developerWorks.

I wrote an application to accompany the recipe, and you can clone the code from GitHub.

In this segment, I’ll show you one very common error and a common warning, both of which you are likely to see if you work with Generics.

Check out the Type Erasure Recipe for more details!

Credits

Music:

Slay Well by Gunnar Olsen, YouTube Audio Library (Free to use for commercial purposes, no attribution required), see YouTube Terms of Service and this YouTube support article for details.

Pixabay images and videos are free for commercial use, no attribution required. See Pixabay Terms of Service for more information..