Re: Patch to Create a 'Local' Management Context (= SystemManager)

[Peter Donald <pe...@apache.org>]

At 08:06 AM 7/13/2002 -0400, you wrote:
>On Saturday 13 July 2002 06:15 am, Peter Donald wrote:
> > moved SubContext to being a top level class as I try to avoid inner classes
> > if possible. Other than that it works like a charm - thanks! It is a much
>
>Can you give some logic behind your avoidance of inner classes?

A few reasons. One of them is visibility. If you put a class as an inner 
class then it can sometimes make it difficult for developers to locate the 
class. However if it is a top-level class then it is easy to find. This 
becomes even more confusing when you have inner inner classes. It can also 
confuse imports. ie does "import a.b.c.X" denote the class X in package c 
or the inner class c.X in package a.b etc. It can also lead to massive 
complex source files.

Worse is the subtle changes in code that result from inner classes that 
most people are not aware of. These are usually the result of inner classes 
largely being a ugly hack built on initial bytecode format. ie consider

class X
{
   private int p;

   class Y
   {
     Y()
     {
       System.out.println( "Meep!" );
     }
   }
}

and compare it to

class X
{
   private int p;

   class Y
   {
     Y()
     {
       System.out.println( "p = " + p );
     }
   }
}

When compiled it will result in two class files; X.class and X$Y.class

Because in the second version, X$Y refers to p, thus p can not be 
implemented as a private variable - despite the fact that it is marked as 
private it is not implemented as private. Theres a whole bunch of cases 
where access  modifiers are silently changed by the compiler to allow inner 
classes to work. So inner classes can result in a whole bunch of code not 
being generated as you would expect it to be generated. In some 
circumstances variables marked as private can be silently "upgraded" to 
public variables to get the inner class hack to work.

Finally of course there is the fact that many compiler writers seem to be 
confused about how to implement inner classes. Quite a few compilers have 
generated bad code in past or just not supported the proper constructs. ie 
Try placing a inner class in an interface that does not specific public 
access and many compilers will not give it public access (however all 
class/variables/methods are implicitly public if declared in an interface). 
Even today jikes often generates bad bytecode for inner classes 
(particularly v1.15). In other compilers, the bytecode is static sections 
is also often butchered and inner classes in inner classes can lead to a 
world of pain.

Mix in anonymous classes and inner classes and you get even more broken code.

Anyways I have spent many many hours debugging problems that occured due to 
differences between compilers that was a direct result of using inner 
classes. I remember in one particular swing project we had to compile about 
a third with jikes and the rest with javac because no compiler supported 
all the constructs that were perfectly valid.

>Would you use
>package level visibility instead?

usually.

Cheers,

Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
              - John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Patch to Create a 'Local' Management Context (= SystemManager)

[Peter Royal <pr...@apache.org>]

On Saturday 13 July 2002 06:57 pm, Peter Donald wrote:
> Anyways I have spent many many hours debugging problems that occured due to
> differences between compilers that was a direct result of using inner
> classes. I remember in one particular swing project we had to compile about
> a third with jikes and the rest with javac because no compiler supported
> all the constructs that were perfectly valid.

meant to write this earlier, but thanks for the detailed explanation, it was 
enlightening :)
-pete

-- 
peter royal -> proyal@apache.org

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>