commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [All] Compiler Warnings/What's left for a release? [WAS: [Poo l] C ompiler Warnings/What's left for a release?]
Date Wed, 23 Apr 2003 20:03:33 GMT
Hello, 

Here are the answers, in all glorious and gory details. First, a summary:

>Are these really compiler warnings,

Yes.

>or due to some plugin in eclipse?

No but... eclipse does have its own compiler which (optionally) generates
these warnings.

>are the performance implications due to java specs,

Yes, a "hidden" method call. More on this below and security implications.

>or a particular jvm implementation etc.

No, this part of the Java specs.

Now, the gory details gathered from <jdt-dev@eclipse.org>

You need to get the Inner Classes Specifications (part of the JDK1.1
documentation on the Sun web site).

If an inner class is accessing a private member from the enclosing class,
the compiler will generate an access method inside the enclosing class.

It states this from the specs:
"Names of generated variables and methods
As we have seen previously, if an inner class uses a variable from an
enclosing scope, the name expression will be transformed, into a reference
either to a field of an enclosing instance, or to a field of the current
instance which provides the value of a final local variable. A reference to
an enclosing instance, in turn, is transformed into a reference to a field
in a more accessible current instance. These techniques require that the
compiler synthesize hidden fields in inner classes.


There is one more category of compiler-generated members. A private member m
of a class C may be used by another class D, if one class encloses the
other, or if they are enclosed by a common class. Since the virtual machine
does not know about this sort of grouping, the compiler creates a local
protocol of access methods in C to allow D to read, write, or call the
member m. These methods have names of the form access$0, access$1, etc. They
are never public. Access methods are unique in that they may be added to
enclosing classes, not just inner classes.


All generated variables and methods are declared in a class file attribute,
so that the 1.1 compilers can prevent programs from referring to them
directly. "


If you want more details, please retrieve the whole specs (part of the
JDK1.1 documentation on the Sun web site).


Of course it works without changing the visibility. The compiler simply
gives a warning that the user needs to be aware that an access method needs
to be invoked to get the private member value or to set the value of a
private member.


To the first question, the answer is:


The performance issue is a consequence of the JLS specification for inner
classes. All java compilers use these access methods.


That's all. I won't try to convince people to change the visibility to get
rid of these warnings. The generated .class files contain an access method
that can be targeted by malicious code to change the value of a private
member. Even if a java compiler might prevent from compiling such code, it
is not difficult to generate a .class file without a java compiler that
could use these access methods. So the argument of not changing the
visibility to prevent illegal access is wrong.

</jdt-dev@eclipse.org>

Gary

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message