Javac VS JBuilder's bcj

Answers in this category:
Error #: 750 : initialization error: com.borland.compiler.symtab.LoadError: neither class nor source found for java.lang.Object
warning #908: can not append file ...
My WebLogic project won't compile on JDK 1.3. I get "Error #: 300 : method getAction() not found in class javax.swing.AbstractButton", and others.
JBuilder's obfuscator is pretty weak. Where can I find a better one?
Where can I find a complete list of JBuilder4 compiler error messages?
JBuilder won't compile just one file. No matter what, it compiles more stuff than I want. How can I make JBuilder compile only the file I want compiled?
I want to compile my Java application into .exe (or some other native binary form.) How do I do this with JBuilder?
I'm trying to compile a project and I'm getting something about "Error 900: out of memory". This project doesn't seem to be that big.
Error#2301:Internal compiler error: com.borland.compiler.symtab.CompilerError: unexpected type: null
I am not receiving the deprecation warnings I expected. The "show deprecation warnings" setting is enabled.
I am getting "sealing violation" exceptions when I run/compile my project. What does this mean?
Are there any tools available to help diagnose classpath problems?
I can add a whole package to my project and edit the source code. However, when compiling, you have to right click the desired package and the only that package is compiled. Any packages within the selected package are NOT compiled.
I'm trying to use the new JDK 1.4 betas, and JBuilder (of any version) gives me the following message when I try to build my projects: "Error #: 750 : initialization error: com.borland.compiler.symtab.LoadError: class file has wrong version 48.0"

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

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

2001-Jan-16 5:38pm gyles19@visi.com

  /home/gyles19/jbproject/MyProject/src

And you have a source file in which there exists lines like:

  package com.visi.gyles19
  public class Foobar {
  ...
  }

Then the source file itself must be named

  Foobar.java

and the proper location for Foobar.java is:

  /home/gyles19/jbproject/MyProject/src/com/visi/gyles19/FooBar.java

This breaks down as:

  /home/gyles19/jbproject/MyProject/src/com/visi/gyles19/FooBar.java
  ..................................... <-- sourcepath
                          package -->   ................
                                               class --> ............

This is especially important when debugging. When the debugger attempts to display a source file, it takes the class file's package, converts it to a platform path (ie com.visi.gyles19 becomes com/visi/gyles19) and then appends the class name (to make it com/visi/gyles19/Foobar.java)

Java internally converts the "." characters within your package statement into the file.separator characters specific to your platform, ie "\" on Windows/Dos and "/" on Unix.

It then goes through the project source path appending the converted package path to each source path provided until it finds the Foobar.java file.

If Foobar.java is in the wrong place, the debugger will never find it. The #908 compiler error is another symptom of a misplaced source file.

Rule: .class and .java files must always be placed in directory locations which reflect the package statement inside the .java file.
2001-Feb-26 4:26pm gyles19@visi.com

In the above case, the MyClass.java file contains a 'package MyPackage;' statement, but it is incorrectly located in directory 'untitled1'.
2001-Dec-30 10:41am gyles19@visi.com

Here's a workaround:

You have to adjust your project to force the naughty weblogic jars to appear AFTER the JDK 1.3 jars on your project's classpath. The easiest way to do this is to go into the JDK 1.3 definition itself, and add the weblogic jars to the JDK's list of jars, AFTER all the real JDK jars.

Do this under Tools/Configure JDK, select the JDK your project is using, and add the weblogic jar(s) to that JDK's own list of jars. Make sure to put them at the END of the list, so that the compiler will find the good 1.3 classes before it finds the bad 1.2.2 classes.

Then, delete the weblogic jars from your project's required libraries settings.

DO NOT edit jbuilder4/bin/jdk.config to do this. jdk.config controls the JVM under which JBuilder itself runs. What you have to fix is the classpath under which your project itself runs.
2001-Jan-10 5:32pm gyles19@visi.com

  Are there any tools available to help diagnose classpath problems?

  http://codecentral.borland.com/codecentral/ccweb.exe/listing?id=15717
  http://www.zelix.com/ 

Here is a list of links to 3rd party obfuscators:

1stBarrier (JProof)

  http://www.jproof.com/products.html

  http://www.2lkit.com/products/2LKitObf/index.htm

  http://www.condensity.com/

  http://www.preemptive.com/

  http://www.force5.com/

  http://www-personal.engin.umich.edu/java/unsupported/jobe/doc.html

  http://www.helseth.com/

  http://www.e-t.com/jshrink.html

  http://proguard.sourceforge.net/

  http://www.retrologic.com/

  http://www.4thpass.com/sourceguard/

  http://www.zelix.com/

(Link list provided by John McGrath.)

  http://www.borland.com/techpubs/jbuilder/jbuilder4/pg/errormsgs.html
   

  http://www.borland.com/techpubs/jbuilder/jbuilder4/index800x600.html

JBuilder's build system uses a package model, not a file model. When you ask it to make or build a single file from the project pane, JBuilder will compile that file, but it will also inspect its dependency information and may well compile more files. These can include classes which extend or use the target class, both within the target package and outside.

JBuilder does this to ensure that changes made within the target class will not break other classes which use the target. Sun's javac compiler does not make this check for you.

Because JBuilder uses a package model, it will notice every java file in a package and compile everything in that package.
2001-Jun-12 11:54pm gyles19@visi.com

Valentino Kyriakides
2001-May-06 3:52am vkyr@ision.net

If you just want to launch your application easily, you can make use of the launcher provided with JBuilder itself. Here's a Borland FAQ that discusses it:

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

  Jove: http://www.instantiations.com/
  Jet:  http://www.excelsior-usa.com/

    http://www.bearcave.com/software/java/comp_java.html

You need to use MRJAppBuilder, which is a part of the freely available Mac OS X developer tools which you can get at http://connect.apple.com (free registration required). The included documentation is rather sparse (as far as MRJAppBuilder is concerned), but you can read a pretty good tutorial article on O'Reilly's Mac DevCenter at:

  http://www.oreillynet.com/pub/a/mac/2001/07/06/osx_java.html

I had a switch statement something like this

  switch(x) {
     case FileA.abc:
     case FileA.def:
     // do something
     break;
  }

For some reason it didnt like the two cases.... never seen this problem anywhere before (had to change to an if/else if)
2001-May-14 1:20pm gyles19@visi.com

I've already resolved the problem, but thought I would document it since (a) someone else might come across it and (b) I don't think the error message was very helpful in determining the cause of the problem - even though it was accurate.

I received the error while trying to recompile a JUnit test suite which uses a number of inner class implemenations of other classes in our framework.

The error was because I had recently removed a parameter from the constructor of the class that was being created as an inner class. I had removed this parameter from constructors all over our code, but had forgotten that these inner classes extended the modified class and so was still passing a null for the parameter - hence the error is accurate.

However:

-JBuilders "internal compiler error" foxed me into thinking I had broken the compiler, and lead me away from thinking it was a simple problem with my own code.

-JBuilder could have highlighted the point where the unexpected type was occuring and lead me to realize what I had done much sooner. I'm not sure i'd have solved it yet if another poster in this group hadn't mentioned internal compiler issues with inner classes.

I think JBuilder should handle this case better.

2001-May-14 1:23pm gyles19@visi.com

  BrowserAction foo = new BrowserAction( "menuitem", 'm', "tooltip") {
    ...
  }

The compiler is expecting a character value for the second parameter. If you replace the 'm' with the null keyword, the compiler produces the unexpected type message. Unfortuately, it fails to provide a line number reference so you probably have no idea what caused it.
2001-Jul-15 3:37pm gyles19@visi.com

Here is the simple test case:

  public class Untitled1 {
        public Untitled1() {
        }
  }

  public class Untitled2 {
        public Untitled2() {
                Untitled1 _u = new Untitled1( null ) {
                };
        }
  }

I think the compiler should be able to generate a "constructor not found" error in this case, and not go bust.

2001-Sep-08 2:23pm gyles19@visi.com

This is by design, so that one can maintain software containing deprecation without getting spammed by the warnings.

Other projects which use this via a defined library will behave as you expect. Their uses of the deprecated items will generate warnings when they are compiled.

2001-May-25 11:13am gyles19@visi.com

Say you have two versions of a jar, "myjar10.jar", and "myjar11.jar" which are two versions of the same API. Assume the API contains a sealed package called "sealme" and a class named "Foo.class". Now assume Foo.class version 1.0 has a method named "oldMethod(int)", but version 1.1 has it as "oldMethod(double)".

If your application uses both methods (by mistake or design), the JVM will attempt to load "oldMethod(int)" from the 1.0 jar, and "oldMethod(double)" from the 1.1 jar, and it will detect the seal has been breached and toss the sealing violation exception.

You have to track down which jars are duplicating a sealed package, and remove all of the duplicates from the classpath.

This feature does make it difficult to "patch" or "override" classes by prepending to the classpath a jar containing replacement classes.
2001-May-25 11:23am gyles19@visi.com

The solution here is to reorder your project's classpath to place JAXP1.1 jars at the start of the classpath, prior to Tomcat's jar in the list of jars. You can do this by defining a required library for the JAXP 1.1 jars (xalan.jar, xerces.jar, crimson.jar, etc) and using the "move up/move down" buttons to place them at the top of the project's required library list. This should cause them to appear before the Tomcat jars in the runtime classpath and should solve the problem.

If that doesn't work, you may have to resort to using -Djava.class.path=... in the project's VMParameters field. This completely overrides the classpath Jbuilder is trying to provide, including the JDK's jars, so you'll have to specify everything the project needs to run by typing it manually (or using a cut/paste operation from the message pane's display of a previous launch.)
2001-Jun-06 9:47pm gyles19@visi.com

  Are there any tools available to help diagnose classpath problems?

JPathReport is free and may be downloaded from its source:

  http://www.jgoodies.com/

This is an all-javascript site.

Here are two examples of its output:
jpathreport1.gif (51.7 K)
jpathreport2.gif (19.7 K)
2001-Jun-19 6:27pm gyles19@visi.com

If your package does not show in the project pane as a direct child of the project node, then you have not actually added the package to the project.

If you are using the Professional or Enterprise version of JBuilder, you can enable automatic source package discovery in the Project Properties dialog, and they will be added automatically. Otherwise, you will have to add the packages to the project. There are a number of OpenTools available that will make this easier for you.
2001-Jun-25 3:04pm gyles19@visi.com

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

JBuilder's compiler has to be updated to handle the new JDK class type, or something like that.

JDK 1.4 introduces several other java language changes, particularly the new 'assert' keyword, and JBuilder's compiler is unable to process these new features.

Stephen Kelvin wrote a tool which resets the JDK class files back to 46, the version JBuilder supports. I have no idea if this is even safe to do, and it probably violates Sun's license, but people report that it gets the projects compiling again with JB3/4/5.

http://www.StephenKelvin.de/MerlinPatch/

People asking if Borland plans to patch JB3/JB4 to support JDK 1.4: I doubt it, myself, but contact Devsupport and ask. I think a JB5 patch is probably unlikely, given that the change is coming from Sun's java itself rather than a bug in JBuilder. (While annoying, the class version number concept in the JDK class files is doing exactly what it is intended to do: prevent incompatible class files from being mangled by elderly JVMs and compilers.)
2001-Aug-30 9:07am gyles19@visi.com

  http://www.borland.com/jbuilder/jb6/newfeatures.html

JBuilder 6.0 is able to compile projects using the 1.4.3 beta JDK on linux. I haven't tested it myself on Windows or using the earlier betas.

2001-Dec-18 12:05pm gyles19@visi.com