Java’s New Pricing

Java’s New Pricing

by | Sep 17, 2018 | Software

I recently attended a talk by Georges Saab, Java head honcho at Oracle. The following is an executive summary, simply explained so you can understand the changes and plan accordingly. If you use Java commercially, the odds of you reading this and saying, “We’re fine, don’t need to change anything,” without doing any checking, is very low.

I’ll add the same “safe harbor” statement Georges added: any planning/spending you do should not rely solely on this article – things can change, I might have misheard something, etc. Do your own research.

Background

  • The JDK, or Java Development Kit, is a versioned specification. JDK 5, 6, … 11. There are also editions, such as Java SE, Java EE, etc.
  • For 5 through 9, major versions were released every 2-5 years. Updates (e.g. 8u20) came out about every 6 months. “Updating” means back-porting security, bug fixes, and possibly other improvements that are guaranteed to have no breaking changes.
  • The JDK specification has implementations, which are downloadable binaries. They come from various providers (companies, organizations, or individuals) and may be
    • under various open source or commercial licenses
    • free or paid
  • The most common one is Oracle JDK.
  • OpenJDK is a community project which provides the reference implementation of the JDK. 
  • It is a collaboration between several companies, but >90% of the contributions come from Oracle. 
  • Anyone can create their own build/distribution of OpenJDK and many do – including Oracle.
  • These builds can have code changes. For a while, Linux vendors replaced code that wasn’t GNU-compatible so it could legally be distributed with Linux, but is/was still called “OpenJDK.”

Today and the Future

  • Starting with JDK 10, a major version of Java will be released every 6 months. Far fewer changes, but still major versions, so not guaranteed to be backward-compatible. 
  • JDK 11 introduces the concept of long-term support (LTS) versions. These are the ones that are going to get updates after the next version is released. Example:
    • JDK 12 is released and bug security fixes are back-ported to 11.
    • JDK 13 is released and bug security fixes are back-ported to 11, but not 12.
  • The big news is that Oracle is going to stop updating Oracle JDK 8 for commercial use in January 2019 and personal (desktop) use in December 2020 unless you pay for support.
  • Oracle will only provide updates to the free version of Oracle JDK, and OpenJDK, while it is current (versions released in the last 6 months). Meaning as soon as JDK 12 is released – 6 months later – they will stop providing updates to Oracle JDK 11 unless you pay.

Let me clarify that with an example that shows you your options:

  • JDK (Java) 11 is released and you adopt the Oracle JDK in a commercial setting. You’re paying nothing as usual.
  • Six months later, JDK 12 is released, with fixes and new features.
  • Your options:
    1. Do nothing. Continue to use Oracle JDK 11 for free forever, legally. The license does not expire, it will just never be updated by Oracle.
      • Maybe you’re running on a closed/air-gapped system and there is nothing else you need.
    2. Upgrade to Oracle JDK 12. Still free and likely can run everything you built under 11 without issues.
    3. Switch to OpenJDK 11 from a provider other than Oracle, who is updating it.
    4. Switch to another commercial JDK.
    5. Pay Oracle for updates of 11. I was told the current price for this is $25/processor/month, with volume discounts, run on the honor system. I understand this is a significant discount from earlier pricing models.

It will be interesting to see how this plays out. I totally get that Oracle has a big staff of developers making Java better and they need to pay them. Giving the product away for free makes that more difficult.

On the other hand, many people have gotten used to paying nothing. A number of companies are already planning to provide updates for older versions, but we’ll see what kind of toll this puts on other contributors and who does what for free. Some have extensive Java experience and their own (often commercial) distributions: Red Hat, Azul Systems, IBM, etc. Those may be more cost effective for you. Maybe you’re already using one.

For the record, I have no problem with companies charging money for software development. Mine does and I’m very fond of the rent and coffee it pays for.

CIO/CTO Action Items

  1. Identify every system that is running Java in a commercial environment. This includes desktops.
    • Remove Java from systems that don’t need it.
  2. Identify where those distributions came from: Oracle, Red Hat, GNU, etc.
  3. Determine their update schedule. Be aware of when your Java versions will be out of date. Put it on your maintenance schedule or potentially get pwned. 
  4. Switch to JDKs that will be updated or plan for regular upgrades.
  5. Budget accordingly.

For further reading, Java Champions have created a document summarizing the changes in a bit more depth.

Hope you found that useful! Please comment with any corrections. 

Thanks to Marco Villalobos for pointing out some issues in the first version.

Dropwizard, JDBI, and Metrics

by | Jun 20, 2014 | Software

I recently attended the SBJUG talk on Dropwizard, which is less of a framework than a collection of libraries for developing self-contained REST web services. I had been hearing a lot of buzz about it recently and wanted to see how it compared to Grails. It is definitely lightweight and I’d encourage you to check it out. However, if you are an experienced Spring developer, your time might be better spent learning Spring boot and using that collection of libraries. If you know Grails, you might just be able to start using 2.4, which allows the @CompileStatic annotation in controllers and domain classes, which could really speed things up. For various reasons you may not be a fan of Spring, and if that’s the case definitely check out Dropwizard.

Although it’s not for me, I did learn about two cool libraries that could be incorporated into any project:

JDBI is like the sequel to iBATIS. You use straight SQL – no HQL or equivalent – with convenience features for writing DAOs to map to classes. No XML. Seems appropriate for groups where most of the queries are hand written for performance or religious reasons.

Metrics is a performance measurement/profiling library. Looks handy. Like Dropwizard, it’s a Yammer project.

Eclipse “cannot be resolved to a type” error

by | Dec 3, 2008 | Software

So I’m coding along and all of a sudden, Eclipse (3.4) can’t resolve classes. Classes that are in the same package as the class I’m editing. Classes that are fully qualified in the import statement.

Not good.

The last thing I had done was add a Spring @Autowired annotation. I saved the file and voila, everything goes to crap. I then spend a stupid amount of time trying to track down the cause. I took the changes out. I did a clean and rebuild and retest (everything passed; this was Eclipse-only). I added new classes to see if they broke (they did). I did a false modify (add space, remove space, save) to see if that broke said file (it did). It was a death spiral. No matter how I changed the code, the same problem was there.

Turns out, it wasn’t the annotation, or anything else in Spring, or any of my code, or any of my Eclipse plugins. It was a step before that killed me. I was doing a little cleanup and I created a temp directory at the top of my project folder so I could move some files there. It wasn’t nested in anything, other than the top level directory. What could go wrong?

Apparently, that makes Eclipse see red. Squiggly red.

The solution was simply to do a refresh (F5) on my project. Just as quickly as it started, the problem went away. That smells like a bug to me, but if it was I figure I’d see a lot more mentions in Google or the Eclipse bug tracker. I’m really hoping this helps someone save some time.

Update: If that doesn’t work, try:

Clean, refresh, build, restart

Also, remember any external build/clean scripts you might be using. For instance, Grails has a command line “clean” you may have to invoke. Same if you have Ant or Maven builds.

David Resnick (comment below) discovered this tip for those with an external build script:

Windows–>Preferences–>Java–>Compiler–>Building–>Output folder–>”Rebuild class files modified by others”.

This exists in Eclipse 3.5; I’m not sure about earlier versions.

Another issue I’ve found over the years is problems when upgrading Eclipse. In theory, new versions of Eclipse should update your workspace and project files just fine. In practice, they can become corrupted. My new rule is to create a new workspace for every major version upgrade of Eclipse (maybe more often if you’re cautious). Then I copy those projects and import the copy. This ensures I have a backup plan should something go awry. You may need to reimport your project(s) if there’s a problem that won’t go away after an upgrade.

Many commenters offered other solutions, so check below. Thanks to those who contributed them!

Update: I switched to IntelliJ. Click that link for details why, it’s not the usual hand-wavy “it’s just so much better” that never got me to switch. Not saying it’s bug free, but nothing is, and I’ve never seen errors like this there.

Keywords: false error, bogus error, eclipse bug