SWITCH FAIL

public class Foo
{
    public void foo(final long value)
    {
        switch(value) {
        case 0:
            break;
        default:
            break;
        }
    }
}

$ javac -Xlint:all Foo.java
Foo.java:5: possible loss of precision
found   : long
required: int
        switch(value) {
               ^
1 error

The argument to switch() must be an int, promotable to int, or an enumeration. So long can't be used. Good thing Java doesn't have to worry about things like handling 64-bit values or anything.

JUNIT FAIL

JUnit version 4.1
Could not find class: TestX

Time: 0.001

OK (0 tests)

Maybe, just maybe, if there is an error starting the test, that should be considered a failed test?

INTERFACE ENCAPSULATION FAIL

Let's say we have some existing useful library classes:

class LowLevelException extends Exception
{
    private static final long serialVersionUID = 1L;
}

class Base
{
    // Connect to the resource or throw if we can't
    public Base(final String resourceName)
        throws LowLevelException
    { /*...*/ }
}

Now, let's use that nice code to build some higher-level library

class Foo extends Base
{
    // A higher-level API that can work with a preferred resource, but if it
    // can't get it, will take a lesser-quality resource.
    public Foo()
        throws LowLevelException
    {
        try {
            // Try to get the good stuff
            super("Preferred Resource");

        } catch(final LowLevelException ex) {
            // Get by with this
            super("Fall-back Resource");
        }
    }
}

But we can't do that:

$ javac -Xlint:all Foo.java
Foo.java:18: cannot find symbol
symbol  : constructor Base()
location: class Base
    {
    ^
Foo.java:21: call to super must be first statement in constructor
            super("Preferred Resource");
                 ^
Foo.java:25: call to super must be first statement in constructor
            super("Fall-back Resource");
                 ^
3 errors

Zomg! So this means you can't catch exceptions from your base class constructor(s) and deal with them locally?

It would seem that it also prevents you from translating an exception from a base class constructor in your derived class constructor.

class HighLevelException extends Exception
{
    private static final long serialVersionUID = 1L;
}

class Foo2 extends Base
{
    // A higher-level API that has some better way to represent the low-level
    // exception, perhaps simply by adding more detail about the failure.
    public Foo2()
        throws HighLevelException
    {
        try {
            super("Something");

        } catch(final LowLevelException ex) {
            throw new HighLevelException("More detail", ex);
        }
    }
}

$ javac -Xlint:all Foo.java
Foo.java:43: cannot find symbol
symbol  : constructor Base()
location: class Base
    {
    ^
Foo.java:45: call to super must be first statement in constructor
            super("Something");
                 ^
Foo.java:48: cannot find symbol
symbol  : constructor HighLevelException(java.lang.String,LowLevelException)
location: class HighLevelException
            throw new HighLevelException("More detail", ex);
                  ^
3 errors

Yeah, cause why would I ever want to do that? I dunno, perhaps to make a clean API encapsulates its dependencies? *sigh*

ORTHOGONALITY FAIL

class Foo extends String
{
    // This avoids a warning
    private static final long serialVersionUID = 1L;
}

$ javac -Xlint:all Foo.java
Foo.java:1: cannot inherit from final java.lang.String
class Foo extends String
                  ^
1 error

I know what final classes are. I think they're the wrong solution to any problem, but I know what they are.

But what is the argument for making String a final class? And if the reason is "because String is special and the compiler knows about it and blah blah", it shouldn't be.

ENCAPSULATION FAIL

Nope, can't do this:

import java.util.regex.Pattern;
class foo
{
    public static void main(String[] args)
    {
        static final Pattern regex = Pattern.compile("abc");
    }
}

Now I have to go put it somewhere and document it in more detail instead of just keeping it by its only point of use.

LEXER FAIL

class foo
{
   public static void main(String[] args)
   {
       // This prints: \uXXXX
       System.out.println("\\uXXXX");
   }
}

$ javac -Xlint:all foo.java
foo.java:5: illegal unicode escape
       // This prints: \uXXXX
                         ^
1 error

No, Java. You shouldn't look for escape sequences in comments. Why are you processing string literal escapes there? Why are you even doing it at that stage of processing? C'mon.

What is this nonsense?

The compilations of a frustrated programmer skilled in modern C++ trying to get Java to do something useful. The real problem? Java.