Answers in this category:
Case statement #1
Usage of this$0
The serialVersionUID from classes compiled by JB4 doesn't match Sun's javac 1.3 or 1.4.
super.getSuperclass() and getClass.getSuperclass() return different results! Code compiled with javac returns the same value, but code compiled with JBuilder does not!
We have some code which builds OK with Sun's JDK 1.3 javac, but gives the following error message when built with JBuilder3: "cannot reference variable markerList before superclass constructor has been called". Will upgrading to JB4 solve this problem?
Sun Document: Bugs Fixed in J2SDK 1.3.1
Why does JBuilder complain about upper-case package names?

          case p_ev.VK_UP: {           <- line 131
            setValue(++value);
            break;
          }
          case p_ev.VK_DOWN: {
            setValue(--value);
            break;
          }
        }

John McGrath writes:

JBuilder is correctly reporting an error in your code. The expression in a case label must be a compile-time constant expression. According to the Java Language Specification, if you reference a static final variable using an object reference, that is not considered a compile time constant. However if you reference the variable using the class name, then it is considered a constant expression. So it should compile without error if you change your code to:

           case KeyEvent.VK_UP:

Note that when you specify the JDK for JBuilder to use, that only affects the runtime classes that it uses to compile with. JBuilder always uses its own compiler.

I presume that when you compiled from the command line, you were using the javac compiler from JDK 1.2. If you compile the same code with the javac from JDK 1.3, it will report an error as well. Sun fixed the bug in their compiler with the 1.3 release.

2001-Feb-15 1:43pm gyles19@visi.com

See the JLS 2nd ed. § 15.8.4. The this$0 synthentic variable is an implementation detail of Sun's compiler. Using it is not portable or safe. Use the name of the outer class, as in "TheOuterClass.this" instead.
2001-Mar-20 8:43am gyles19@visi.com

Inner classes gain access to their container class variables using auto-generated access methods created by the compiler as needed. The specification declares that these methods should be named "access$n" and this is the form javac 1.2.2 (and earlier) and other compilers have used (including JBuilder's).

The problem appears in javac 1.3 and 1.4, which has changed the name of the access methods to "access$nnn" meaning the number appended to the name now contains leading zeroes.

Because the serialVersionUID is computed using the method names within the class, the change in the access methods changes the computed value. So, the same class file compiled by javac 1.2.2 and 1.3 will have different values! Of course, this applies to JBuilder's compiler, also.

The only way to get around this problem is to ensure all copies of your class files were compiled by the same compiler, or by compilers known to produce compatible method names.

The DUMMY static constant trick mentioned elsewhere will not fix this problem, only recompiling with a compatible compiler will do it.
2001-Jun-02 11:57am gyles19@visi.com

Should the "Include debug info" switch affect the serialVersionUID?
2001-Jul-09 2:28pm gyles19@visi.com

I have not looked at this for a while, and I see that Borland has changed the compiler to always generate the static initializer block, regardless of whether the -g option is used.

It seems as if Java compiler developers have been grappling with this issue, as different versions of compilers handle this differently. I compiled the following program with various compilers, both with and without the debug (-g) option.

    public class SUID implements java.io.Serializable {
        public static final String suid = "suid";
    }

As you can see, the results are somewhat mixed.

                   Debug (-g)
                   ----------
    Compiler       Yes     No
                   ---     --
    JDK 1.1.8       N       N
    JDK 1.2.2       N       N
    JDK 1.3         N       N
    JDK 1.3.1       N       N
    JDK 1.4         N       Y
    Jikes 1.12      N       N
    Kaffe 1.4F      Y       Y
    JBuilder 4      N       Y
    JBuilder 5      Y       Y
    JBuilder 6      Y       Y

    N = Does not have static initializer
        SerialVersionUID = 2823290551686321412L;

    Y = Has static initializer
        SerialVersionUID = -2815904881746903822L;

I am going to see if I can find out more about this.

I presume that the reason you are concerned about this is that the default SerialVersionUID varies depending on the compiler. The way to fix that is to add a static non-final variable with an initializer into your class. Then, you will have a static initializer with all compilers and there will be no compatibility issues. For example:

   private static int DUMMY = 1;

2002-Apr-17 6:02am gyles19@visi.com

super.method() is having your object run the superclass's method() body. It's still your object running the method, not the parent class. this.getClass.method() is calling the method on the Class object corresponding to the superclass. This may not be what you intended. That object is of type Class, not the type of 'this'.

Here are two source files which illustrate the problem you're having more clearly. Run this and look at the output closely. Note that I had to comment part of Untitled2 to make it compile. You've been fooled because the method you're calling happens to exist all the way up the inheritance chain, but in my example below it does not.

  package xperiment1;
  public class Untitled1 {
    public Untitled1() {
     System.out.println("1 " + this.getClass() + " with parent " + super.getClass());
     System.out.println("1 " + this.getClass() + " with parent " + this.getClass().getSuperclass());
    }
    public static void main(String[] args) {
      Untitled1 untitled11 = new Untitled1();
    }
    public String getFoo() {
      return "untitled1 foo";
    }
  }
  
  package xperiment1;
  public class Untitled2 extends Untitled1 {
    public Untitled2() {
     System.out.println("2 " + this.getClass() + " with parent " + super.getClass());
     System.out.println("2 " + this.getClass() + " with parent " + this.getClass().getSuperclass());
     System.out.println("2 " + this.getFoo() + " with parent " + super.getFoo());
   //  System.out.println(this.getFoo() + " with parent " + this.getClass().getFoo());
    }
    public static void main(String[] args) {
      Untitled1 untitled12 = new Untitled2();
    }
    public String getFoo() {
      return "untitled2 foo";
    }
  }

Gillmer Derge writes:

When you define an inner class, the compiler adds a reference to the outer class object (usually called something like "this$0", use javap to see it). So when you refer to "markerList" what you're really saying is "this$0.markerList," and since "this$0" is an instance variable declared (implicitly) in this class, you're violating that rule. Now, I may be abusing the JLS by using that quote in a way in which Sun never intended, but I don't think it's clearly an abuse.

You might want to try using "Counter.this.markerList" just to see whether that puts you into a different set of compiler rules that don't cause the error message, but I doubt it will help.

The following quote from Section 8.8.5.1 of the Java Language Specification http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#229267 covers this issue.

An explicit constructor invocation statement in a constructor body may not refer to any instance variables or instance methods declared in this class or any superclass, or use this or super in any expression; otherwise, a compile-time error occurs.

For example, if the first constructor of ColoredPoint in the example above were changed to:

    ColoredPoint(int x, int y) {
      this(x, y, color);
    }

then a compile-time error would occur, because an instance variable cannot be used within a superclass constructor invocation.

http://java.sun.com/j2se/1.3/fixedbugs/1.3.1/compiler.html
2001-Dec-04 8:26am gyles19@visi.com

See this Borland FAQ for additional information:

  http://community.borland.com/article/0,1410,28129,00.html