File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes Why recompile? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Why recompile?" Watch "Why recompile?" New topic

Why recompile?

Aj Manch
Ranch Hand

Joined: May 07, 2001
Posts: 50
I have 2 simple classes - com.a.c1 and com.b.c2 as follows:

When I compile both classes and run c2, I get "In c1()".
Now, I change the class c1 to be default access as opposed to public and change the print statement in the constructor.

I compiled this class (c1) again and executed c2. This time I get "In c1()...". I was expecting that I will throw some errors because c1 is not accessible outside its package.
But now if I compile c2, I am getting the errors that c1 is not accessible.
Apparently, before I recompile c2 it is accessing c1 with the old access modifiers but with new constant expressions. Can somebody please explain me what's happening in the JVM? I would appreciate if you could give me some pointers on the internet where this is discussed/described in more detail.
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
Access modifiers are understood and implemented by the compiler only, not by the JVM. The two versions of are both legal on their own, and they compile to exactly the same .class files - no access info is stored in these files. The only way you will get an error is if you recompile the class that is doing the illegal accessing - c2. At that time the compiler will look again at the source for the accessed class, c1, and see that the access is illegal.
In general, there are all sorts of confusing effects you can create by recompiling only some of your classes. I have found that when compiling, it's usually best to recompile all files in a project from scratch. It may take a bit longer for a big project (only a little bit though given today's processor speeds), but it's well worth your while to avoid the kind of subtle, confusing bugs you get when some of your class files are out of date.

"I'm not back." - Bill Harding, Twister
Cindy Glass
"The Hood"

Joined: Sep 29, 2000
Posts: 8521
From the JVM Spec in the section on Linking: Class and Interface Resolution
To resolve an unresolved symbolic reference from D to a class or interface C denoted by N, the following steps are performed:
1.The defining class loader of D is used to create a class or interface denoted by N. This class or interface is C. Any exception that can be thrown as a result of failure of class or interface creation can thus be thrown as a result of failure of class and interface resolution. The details of the process are given in Section 5.3.
2.If C is an array class and its element type is a reference type, then the symbolic reference to the class or interface representing the element type is resolved by invoking the algorithm in Section recursively.
3.Finally, access permissions to C are checked: If C is not accessible (�5.4.4) to D, class or interface resolution throws an IllegalAccessError.
This condition can occur, for example, if C is a class that was originally declared to be public but was changed to be non-public after D was compiled.
If steps 1 and 2 succeed but step 3 fails, C is still valid and usable. Nevertheless, resolution fails, and D is prohibited from accessing C.

"JavaRanch, where the deer and the Certified play" - David O'Meara
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
Good catch, Cindy. I was wrong about the JVM's knowledge of access modifiers - I seem to recall there are cases where the JVM seems to know less about access than the compiler, but details are fuzzy in my memory right now and I don't have time to test. But contrary to me earlier statement, access modifiers are part of the class files, and the JVM is expected to enforce them. But of course, if the class file is out of date, strange things can happen...
I agree. Here's the link:
subject: Why recompile?
Similar Threads
access problems
inhertitance through multiple packages - not able to analyze the output-
protected member
protected and default constructor
protected constructors