My Experience taking the new Java SE 11 Programmer I 1Z0-815 Exam

One day after Oracle announced the new Oracle Certified Professional: Java 11 Developer certification, I decided to jump in and take the first of two exams! As an author of a best-selling Java certification series, how hard could it be I thought? In short… very! I did pass, but it was very different from what I imagined it would be.

Certification Changes

On the surface, the new Java 11 Programmer I (1Z0-815) and Java 11 Programmer II (1Z0-816) exams appear to be loosely based on the original OCA 8 (1Z0-808) and OCP 8 (1Z0-809) exams. I say loosely, because glancing at the objectives would lead you to believe they might be the same exams. They are decidedly not! More on that in a minute. One major change to the structure, though, is that the Oracle Certified Associate title no longer exists. Completing either exam does not grant you any certification title, and you must complete both Programmer I and Programmer II exams (in any order) to be an Oracle Certified Professional 11. There is also a single Java 11 OCP Upgrade (1Z0-817) exam for holders of a Java 6/7/8 OCP certification. Each of the three new exams are listed at $245 US. Unlike previous Java exams, there is no discounted beta exam, or beta exam of any kind, for the new Java SE 11 exams.

Neither Jeanne nor I have taken the Programmer II exam yet, so the rest of this post will be about my personal experience with the new Programmer I exam.

OCA 8 (1Z0-808) vs Java 11 Programmer I (1Z0-815): What’s the difference?

A LOT. I can’t emphasize this enough. The new Programmer I exam is significantly harder than the OCA 8 exam was. Questions are much more involved, much longer, and often require answering multi-part questions. For example, a question might have 8 answer choices and you need to select 3 completely independent answers. Process of elimination is crucial to finishing the exam. For example, in some cases it’s a lot easier to find the 5 choices that don’t compile than the 3 that do.

The new Java 11 Programmer I exam also includes a lot of topics that were previously only found on the OCP 8 exam. While you don’t need to know stand-alone topics like Concurrency, JDBC, and NIO.2 for this exam, you do need to know nearly everything there is to know about core Java topics like interfaces, generics, and Java operators. Jeanne and I noticed the new objectives appear to be a lot vaguer and broader than the previous objective set, meaning they can (and do) encompass a lot more than is explicitly listed in the objective titles. For example, == and equals() are no longer listed in the objectives, but don’t let that lull you into thinking for a second that you don’t need to know them to pass the exam!

Modules, modules, modules, Oh my!

The Java 11 Programmer I exam includes new topics like Project Jigsaw modules. Prior to taking the exam, I thought there going were only going to be a handful of questions on modules. Boy was I wrong! There were many questions on modules and the depth of them was honestly very surprising. You definitely need to memorize all module-related command line arguments to java/javac/jdeps/jmod, as well as knowing the long and short command-line flags. Just because modules is 1 of the 12 of the top-level exam objectives, don’t be fooled into thinking only 1/12 of the questions will be on modules! Understanding modules is vital to passing this exam!

OCA 8 (1Z0-808) vs Java 11 Programmer I (1Z0-815): What’s the same?

Excluding modules, the objectives are quite similar between the OCA 8 and Java 11 Programmer I exams, but that’s more likely to do more harm than good. Anyone going into this exam thinking this is just a Java 11 version of the OCA 8 exam will be in for a surprise.

So what is the Java 11 Programmer (1Z0-815) exam?

In a nutshell, it’s like they took the old OCA 8 exam, increased the difficulty of the questions by an order of magnitude until it was as hard as the old OCP 8 exam. Then, they updated the length of questions so that you had to answer 2-3 questions at once in a single question. Next, they greatly increased the depth of any topic on the previous exam. For example, previously you might have only needed to know 2-3 StringBuilder methods, whereas now you need to know nearly all of them. Finally, they filled the exam to the brim with Java module questions.

Of course, they also included other new Java 9/10/11 topics, like var and some string/array methods, but they pale in comparison with the changes in depth, difficultly, and new module topics.

“Can I use your OCA 8 book to study for the Java 11 Programmer I exam?”

As the sole source of preparation for the exam, definitely not. The OCA 8 exam was significantly easier and lighter than the new Java 11 Programmer I exam, and we wrote the questions and topics to match that particular exam. If you only study from our previous book, there is a good chance you might fail the exam.

That said, you could use our OCA 8 book, as well as the first half of our OCP 8 book as a starting points for studying for the new Java 11 Programmer I exam, but you will absolutely need to supplement it with education on the new topics, methods, and classes in Java 9/10/11, as well as in depth and hands on knowledge of modules. You should also expect the questions to be at least on the level of difficulty as the OCP exam.

“Hey Scott and Jeanne, is there a new Java 11 certification book coming?”

We get this question a lot, even before the objectives were announced. All I can say is, stay tuned for now!

consistency is a lovely thing

Since Oracle certifications are tied to version numbers, they periodically announce the retirements of old exams. This is reasonable. They even publish a page of retiring exams and include this fact on the all exams list.

However, this is incomplete and currently inconsistent.

The retiring exam page currently lists the Java 7 certs, but not the Java EE 6 certs. On the other hand, if you go to the page for a Java EE cert that is retiring, it says in the title that the exam is retiring.

On the third hand, if you go to a page for a Java 7 cert that is retiring, it does not say anywhere on that page that it is retiring.

I hope Oracle fixes this. It’s confusing!

more on backward compability – this time with lang

I blogged an answer to Mark’s question about var in Java 10. He wrote back the following. I thought it was great and asked if I could use it as a guest blog post. He said yes.

So compliments of our guest blogger: Mark Yagnatinsky.

Thanks! You inspired me to try compiling my own little test program that I’d wondered about for a while:

It turns out that if you try to do this:

class java {
    class lang {

Java won’t let you (it notices that there’s already a package with that name).
But first of all, this protection extends only to java.lang, and not, say, java.util.
And second of all, we can distract it by putting our code in a package:

package Scratches;
class java{
    interface lang{
        class String{}
        static void main( HELP[] args ) {

As far as I can tell, there is nothing we can type instead of HELP to make the above main method runnable on the command line.
In this case though, we’re only doing “local” damage: the rest of the code in our package (outside of “interface lang”) can still use Strings.

The way this is usually described is that there is an implicit “import java.lang.*” at the start of every file.
It turns out that java.lang is more special than this description implies.

If we try the same trick with java.util, we can knock access to the entire package (but not subpackages):

package Scratches;
// the line below has no effect whether you comment it out or not.
//import java.util.Hashtable;
class java {
    interface lang {
        class String{}
        static void main( String... args ) {
            // can't fix signature to run this method.
    interface util {
        class Hashtable{}
class Main {
    public static void main( java.lang.String... args ) {
        // this method does not get called if you run from the command line
    public static void main( String... args ) {
        // this method runs from the command line just fine
        new java.util.Hashtable(); // this is our hash table, not Java's
        // the line below won't compile (no such name)
        //new java.util.HashMap();
        new java.util.concurrent.ConcurrentHashMap(); // but this is fine

It’s kind of amazing how much insanity the capitalized class name convention protects us from.
(Though to be fair, Java.Util is also a fairly unlikely class name…)