Name: boT120536 Date: 08/20/2001


java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)


This is a follow-up to a bug I submitted a couple of days ago and seems to
have been filed under another bug number on the bug database without my original
comments, hence I'm having to re-submit it here.

My Original Posting:
--------------------

In your favourite directory, make the directory 'my_package' and place in it an
*empty* file called 'my_package.java' and the file 'AnonDemo.java' as follows:


package my_package;

class AnonDemo
{
    BaseClassForAnonClass tmpObject =
new BaseClassForAnonClass(this)
{
};
}

abstract class BaseClassForAnonClass
{
    BaseClassForAnonClass(AnonDemo owner)
    {
    }
}


Back in your favourite directory, type:

javac my_package/AnonDemo.java

...and the compiler gives this error:

my_package/AnonDemo.java:7: cannot resolve symbol
symbol : class AnonDemo
location: class my_package.my_package
{
        ^
1 error

This is a bogus error as the code is well formed. In fact it will compile
without an error if the unrelated, empty file 'my_package.java' is moved out of
the way!

This trigger for this bug appears to be the conjunction of several
items:

1) There must be a file '<package-name>.java' in the package <package-name>.
2) An anonymous class must be used in some '.java' file in <package-name>.
3) The base class for the anonymous class must have a constructor that utilises
   at least one parameter.
4) The parameter to the base class's constrcutor must be a reference type
   rather than a primitive type (and it might have to refer to an object
   defined in <package-name> - changing the parameter to a String cures the
   problem).

Breaking any of the above conditions makes the problem vanish.

The problem is also manifest in deeper package hierarchies. If the above
example is nested inside another level which is also called 'my_package' (and
the package statement in AnonDemo.java updated appropriately) then the error
changes slightly to the even more cryptic:

javac my_package/my_package/AnonDemo.java
my_package/my_package/AnonDemo.java:7: cannot resolve symbol
symbol : class my_package
location: class my_package.my_package.my_package
{
        ^
1 error

This may be quite a rare bug but I stumbled across it during ordinary use of
the compiler when implementing my first reasonably sized java program (a
standard invocation of Murphy's Law!) and it completely fazed me for a while.
workaround : Break any of the above 4 conditions (careful naming of the packages is probably
the simplest).

BTW, I've *not* compiled my_package.java, only AnonDemo.java. The class
AnonDemo does not reference the class my_package so my_package.java should not
be being built at all, right? Hence there should be no clash.

The compiler seems to be going off and building the class my_package when it
hits the anonymous class in AnonDemo (hinted at from the line number in the
error, and the fact that this problem resolves itself if the anon class is
removed).

(Review ID: 130253)
======================================================================