Class Viewer, Google searches, and rankings

[Andreas Leitgeb]

 [about Class viewer]
I had a look at your sourceforge page, and was unclear
about a few things:
 - why only "public" members?

More of an arbitrary thing where I just went that way.  I was taught
use public classes and stay away from protected, if possible.
But if I had a user base that was clamoring for that I'd guess I'd do
it, though individual developers can, of course, simply make the
change in the code themselves.

Well, right.

Hmm, yes, makes sense. Loading the root-frameset of Sun's API-docs does
take a while (due to the complete class list in the lower-left pane). so
effectively extracting the class list from local rt.jar and direct jumps
to the respective method's doc makes indeed lots of sense for those with
a rather slow connection to the 'net.


By the way, I made another mistake: I said it did not extract more than
what is in javadocs, but actually it does. In the screenshot it shows
a "volatile int compareTo(Object)", which is not mentioned in the javadocs,
but I saw it with my own class-parser that this method is indeed there and
that it is tagged as "volatile" and also as "synthetic".
javap also does display that method (the one with the Object argument), but
hides away both the "volatile" and the "synthetic" flag.

I've got no reasonable idea, though, what "volatile" means for a *method*.
Is it to prevent optimizing away double-evaluation for the same args?
If so, I wasn't aware of such optimizations in the first place, and
would rather expect a tag for those methods that could be thusly optimized.

 

[Daniele Futtorovic]

By the way, I made another mistake: I said it did not extract more than
what is in javadocs, but actually it does. In the screenshot it shows
a "volatile int compareTo(Object)", which is not mentioned in the javadocs,
but I saw it with my own class-parser that this method is indeed there and
that it is tagged as "volatile" and also as "synthetic".
javap also does display that method (the one with the Object argument), but
hides away both the "volatile" and the "synthetic" flag.

I've got no reasonable idea, though, what "volatile" means for a *method*.
Is it to prevent optimizing away double-evaluation for the same args?
If so, I wasn't aware of such optimizations in the first place, and
would rather expect a tag for those methods that could be thusly optimized.

Do you mean this "Synthetic":
<http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#80128>
"A class member that does not appear in the source code must be marked
using a Synthetic attribute"

Can't find any reference to a similar "volatile" or "Volatile"
attribute, though.

 

[Andreas Leitgeb]

Can't find any reference to a similar "volatile" or "Volatile"
attribute, though.

I meant this "volatile":
<http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#87652>
"ACC_VOLATILE" 0x0040

The corresponding table for a method's access_flags, does not
list any symbol for that bit-position, yet in java.lang.String
the method compareTo(Object) does have that bit set.

At some point in time, there must have been more flags (or
not all the flags are documented in the jvm-spec).

e.g.: enum-classes do have a static field "$VALUES", whose
access_flags contain the bit for "synthetic", 4096 (0x1000),
but there's no "Synthetic"-Attribute attached to it. Both
the enum class itself, and the fields for the instances
have bit (0x4000) set, which also isn't documented there.

 

[Joshua Cranmer]

e.g.: enum-classes do have a static field "$VALUES", whose
access_flags contain the bit for "synthetic", 4096 (0x1000),
but there's no "Synthetic"-Attribute attached to it. Both
the enum class itself, and the fields for the instances
have bit (0x4000) set, which also isn't documented there.

That should be the ENUM flag, documented in the Java 5 addendum to the
JVM spec. Why the JVM spec hasn't been updated to include the Java 5
errata and the Java 6 addendum (i.e. the bytecode verification helper)
is beyond me; I certainly hope they rectify that soon.

 

[Lits O'Hate]

To you. Anybody else would have put the word into Google and
discovered it for themselves _before_ sounding off about it.

The only name James knows how to search for is his own.

 

[JSH]

 [about Class viewer]
I had a look at your sourceforge page, and was unclear
about a few things:
 - why only "public" members?
More of an arbitrary thing where I just went that way.  I was taught
use public classes and stay away from protected, if possible.
But if I had a user base that was clamoring for that I'd guess I'd do
it, though individual developers can, of course, simply make the
change in the code themselves.

Well, right.

Hmm, yes, makes sense.  Loading the root-frameset of Sun's API-docs does
take a while (due to the complete class list in the lower-left pane). so
effectively extracting the class list from local rt.jar and direct jumps
to the respective method's doc makes indeed lots of sense for those with
a rather slow connection to the 'net.

Even with a fast connection I would find it annoying to have to take
all those steps, but with Class Viewer, I don't. I double-click and
I'm at the method without worrying about how to get there.

By the way, I made another mistake: I said it did not extract more than
what is in javadocs, but actually it does.  In the screenshot it shows
a "volatile int compareTo(Object)", which is not mentioned in the javadocs,
but I saw it with my own class-parser that this method is indeed there and
that it is tagged as "volatile" and also as "synthetic".
javap also does display that method (the one with the Object argument), but
hides away both the "volatile" and the "synthetic" flag.

Sun must have heard you and took it away... Just joking but I just
ran the program to look and see and that's gone. It just says int
compareTo(Object) now.

I've got no reasonable idea, though, what "volatile" means for a *method*..
Is it to prevent optimizing away double-evaluation for the same args?
If so, I wasn't aware of such optimizations in the first place, and
would rather expect a tag for those methods that could be thusly optimized.

I have no clue though I hope the other replies to you gave the answer.

My program just pulls the class information using Java Reflections so
before that must have been there and for some reason Sun made a change
so now it's not.


James Harris

 

[Andreas Leitgeb]

Sun must have heard you and took it away... Just joking but I just
ran the program to look and see and that's gone. It just says int
compareTo(Object) now.

Do you remember the Java version back when you did the screenshot,
and can you tell me the Java version you're using now (where the
volatile is gone)?

I did see the volatile flag present in version 1.6.0_10 (rc), so if you use
the same version, it's likely that they modifed the reflection classes to
just not report that flag (assuming you didn't change your application,
since taking the screenshot)

PS: If you really want to know, what's in a class-file, you gotta parse
it yourself ;-)

 

[JSH]

Do you remember the Java version back when you did the screenshot,
and can you tell me the Java version you're using now (where the
volatile is gone)?

I did see the volatile flag present in version 1.6.0_10 (rc), so if you use
the same version, it's likely that they modifed the reflection classes to
just not report that flag  (assuming you didn't change your application,
since taking the screenshot)

PS: If you really want to know, what's in a class-file, you gotta parse
     it yourself ;-)

I'm on 6.0 something or other. That probably was the older version
before generics, etc.

___JSH

 

[Mike Schilling]

On Aug 24, 2:03 am, Andreas Leitgeb
<[email protected]>
wrote:
[about Class viewer]
I had a look at your sourceforge page, and was unclear
about a few things:
- why only "public" members?
More of an arbitrary thing where I just went that way. I was
taught
use public classes and stay away from protected, if possible.
But if I had a user base that was clamoring for that I'd guess I'd
do
it, though individual developers can, of course, simply make the
change in the code themselves.

Well, right.

Hmm, yes, makes sense. Loading the root-frameset of Sun's API-docs
does take a while (due to the complete class list in the lower-left
pane). so effectively extracting the class list from local rt.jar
and
direct jumps to the respective method's doc makes indeed lots of
sense for those with
a rather slow connection to the 'net.


By the way, I made another mistake: I said it did not extract more
than what is in javadocs, but actually it does. In the screenshot
it
shows
a "volatile int compareTo(Object)", which is not mentioned in the
javadocs, but I saw it with my own class-parser that this method is
indeed there and that it is tagged as "volatile" and also as
"synthetic".
javap also does display that method (the one with the Object
argument), but hides away both the "volatile" and the "synthetic"
flag.

I've got no reasonable idea, though, what "volatile" means for a
*method*. Is it to prevent optimizing away double-evaluation for the
same args?
If so, I wasn't aware of such optimizations in the first place, and
would rather expect a tag for those methods that could be thusly
optimized.

The method is generated by a generics feature I had been unaware of.
String implements Comparable<String> and explictly provides a
compareto(String) method. The compiler autmoatically generates

int compareTo(Object o)
{
return compareTo(String)o;
}

This behavior is simple enough to reproduce. Try compiling

class Gunk implements Comparable<Gunk>
{
public int compareTo(Gunk g)
{
return 0;
}
}

If anyone can point me to the section of the JLS that documents this,
I'd be grateful.

My guess is that the flag you're seeing is AccBridge, meaning that
this method is used to bridge from one overload to another. (see
http://www.jdocs.com/page/AjaxSourceCode?oid=34854) I'm wondering
whether you see the same flag in the

Object clone()
{
return clone();
}

method generated by

class Gunk
{
public Gunk clone()
{
return this;
}
}

 

[Mike Schilling]

On Aug 24, 2:03 am, Andreas Leitgeb
<[email protected]>
wrote:
[about Class viewer]
I had a look at your sourceforge page, and was unclear
about a few things:
- why only "public" members?
More of an arbitrary thing where I just went that way. I was
taught
use public classes and stay away from protected, if possible.
But if I had a user base that was clamoring for that I'd guess
I'd
do
it, though individual developers can, of course, simply make the
change in the code themselves.

Well, right.

Yup. It's a quick reference tool. It's not about giving you more
info than you can get from other sources but about presenting
basic
class information so that it is easy to look over and getting you
javadocs easily, as in a double-click.

Hmm, yes, makes sense. Loading the root-frameset of Sun's API-docs
does take a while (due to the complete class list in the lower-left
pane). so effectively extracting the class list from local rt.jar
and
direct jumps to the respective method's doc makes indeed lots of
sense for those with
a rather slow connection to the 'net.


By the way, I made another mistake: I said it did not extract more
than what is in javadocs, but actually it does. In the screenshot
it
shows
a "volatile int compareTo(Object)", which is not mentioned in the
javadocs, but I saw it with my own class-parser that this method is
indeed there and that it is tagged as "volatile" and also as
"synthetic".
javap also does display that method (the one with the Object
argument), but hides away both the "volatile" and the "synthetic"
flag.

I've got no reasonable idea, though, what "volatile" means for a
*method*. Is it to prevent optimizing away double-evaluation for
the
same args?
If so, I wasn't aware of such optimizations in the first place, and
would rather expect a tag for those methods that could be thusly
optimized.

The method is generated by a generics feature I had been unaware of.
String implements Comparable<String> and explictly provides a
compareto(String) method. The compiler autmoatically generates

int compareTo(Object o)
{
return compareTo(String)o;
}

This behavior is simple enough to reproduce. Try compiling

class Gunk implements Comparable<Gunk>
{
public int compareTo(Gunk g)
{
return 0;
}
}

If anyone can point me to the section of the JLS that documents
this,
I'd be grateful.

My guess is that the flag you're seeing is AccBridge, meaning that
this method is used to bridge from one overload to another. (see
http://www.jdocs.com/page/AjaxSourceCode?oid=34854) I'm wondering
whether you see the same flag in the

Object clone()
{
return clone();
}

method generated by

class Gunk
{
public Gunk clone()
{
return this;
}
}

I've looked into this a bit and that's exactly it. From the 1.6
version of Modifier.java:

// Bits not (yet) exposed in the public API either because they
// have different meanings for fields and methods and there is no
// way to distinguish between the two in this class, or because
// they are not Java programming language keywords
static final int BRIDGE = 0x00000040;

Not that I see why it isn't possible to have both

public static final int BRIDGE = 0x00000040;

and

public static final int VOLATILE = 0x00000040;

with a bit of javadoc explaining that one applies to fields and one to
methods, but that's what it says.

 

[JSH]

On Aug 24, 2:03 am, Andreas Leitgeb
<[email protected]>
wrote:
[about Class viewer]
I had a look at your sourceforge page, and was unclear
about a few things:
- why only "public" members?
More of an arbitrary thing where I just went that way. I was
taught
use public classes and stay away from protected, if possible.
But if I had a user base that was clamoring for that I'd guess
I'd
do
it, though individual developers can, of course, simply make the
change in the code themselves.
Well, right.
Yup. It's a quick reference tool. It's not about giving you more
info than you can get from other sources but about presenting
basic
class information so that it is easy to look over and getting you
javadocs easily, as in a double-click.
Hmm, yes, makes sense.  Loading the root-frameset of Sun's API-docs
does take a while (due to the complete class list in the lower-left
pane). so effectively extracting the class list from local rt.jar
and
direct jumps to the respective method's doc makes indeed lots of
sense for those with
a rather slow connection to the 'net.
By the way, I made another mistake: I said it did not extract more
than what is in javadocs, but actually it does.  In the screenshot
it
shows
a "volatile int compareTo(Object)", which is not mentioned in the
javadocs, but I saw it with my own class-parser that this method is
indeed there and that it is tagged as "volatile" and also as
"synthetic".
javap also does display that method (the one with the Object
argument), but hides away both the "volatile" and the "synthetic"
flag.
I've got no reasonable idea, though, what "volatile" means for a
*method*. Is it to prevent optimizing away double-evaluation for
the
same args?
If so, I wasn't aware of such optimizations in the first place, and
would rather expect a tag for those methods that could be thusly
optimized.

The method is generated by a generics feature I had been unaware of.
String implements Comparable<String> and explictly provides a
compareto(String) method.  The compiler autmoatically generates

   int compareTo(Object o)
   {
       return compareTo(String)o;
   }

This behavior is simple enough to reproduce.  Try compiling

class Gunk implements Comparable<Gunk>
{
   public int compareTo(Gunk g)
   {
        return 0;
   }
}

If anyone can point me to the section of the JLS that documents
this,
I'd be grateful.

My guess is that the flag you're seeing is AccBridge, meaning that
this method is used to bridge from one overload to another.  (see
http://www.jdocs.com/page/AjaxSourceCode?oid=34854)  I'm wondering
whether you see the same flag in the

   Object clone()
   {
           return clone();
   }

method generated by

class Gunk
{
   public Gunk clone()
   {
       return this;
   }
}

I've looked into this a bit and that's exactly it.  From the 1.6
version of Modifier.java:

    // Bits not (yet) exposed in the public API either because they
    // have different meanings for fields and methods and there is no
    // way to distinguish between the two in this class, or because
    // they are not Java programming language keywords
    static final int BRIDGE    = 0x00000040;

Not that I see why it isn't possible to have both

  public static final int BRIDGE    = 0x00000040;

and

  public static final int VOLATILE    = 0x00000040;

with a bit of javadoc explaining that one applies to fields and one to
methods, but that's what it says.

Thanks for the clarification.


___JSH

 

[Andreas Leitgeb]

I thought, "synthetic" is the word for such extra
things (classes, methods, fields) created by the
compiler. But obviously, there's now that bit
of extra information about one possible reason
for the compiler to add the thing.

Yes both Object-variants were there and both with the
0x40 plus the synthetic flag.

I've looked into this a bit and that's exactly it. From the 1.6
version of Modifier.java:

// Bits not (yet) exposed in the public API either because they
// have different meanings for fields and methods and there is no
// way to distinguish between the two in this class, or because
// they are not Java programming language keywords
static final int BRIDGE = 0x00000040;

Not that I see why it isn't possible to have both
public static final int BRIDGE = 0x00000040;
and
public static final int VOLATILE = 0x00000040;

with a bit of javadoc explaining that one applies to fields and one to
methods, but that's what it says.

Thanks for the quotation, and I agree to your disagreement

 

[Joshua Cranmer]

I thought, "synthetic" is the word for such extra
things (classes, methods, fields) created by the
compiler. But obviously, there's now that bit
of extra information about one possible reason
for the compiler to add the thing.

Such a method has both the ACC_SYNTHETIC and ACC_BRIDGE flags set. It's
probable that the compiler uses the bridge flag somewhere internally...

 

[Andreas Leitgeb]

Such a method has both the ACC_SYNTHETIC and ACC_BRIDGE flags set. It's
probable that the compiler uses the bridge flag somewhere internally...

And meanwhile I can even think of a situation where it is useful
to do so:
A bridge method must not be treated as a candidate for overload
selection. The compiler must(and does) refuse attempts to call
String's compareTo(Object) directly, so the only way it could
be still called is, from code was compiled with a pre-1.5 compiler
(or such -source option).

Indeed:
class Test {{String foo="foo";Object bar="bar";int i=foo.compareTo(bar);}}

Is compileable (with a >=1.5 compiler), if (and only if) the option -source
is given with a <1.5 value. And guess what? It then calls that bridge
method from the resulting byte-code.

 

[Mike Schilling]

And meanwhile I can even think of a situation where it is useful
to do so:
A bridge method must not be treated as a candidate for overload
selection. The compiler must(and does) refuse attempts to call
String's compareTo(Object) directly, so the only way it could
be still called is, from code was compiled with a pre-1.5 compiler
(or such -source option).

Or via code like this:

Object o;
String s;
Object o2 = (Object)s;
int i = o2.compareTo(o);

But this does not invalidate your point; in this example the compiler
is looking at Object.compareTo(), not String.compareTo().

Indeed:
class Test {{String foo="foo";Object bar="bar";int
i=foo.compareTo(bar);}}

Is compileable (with a >=1.5 compiler), if (and only if) the option
-source is given with a <1.5 value. And guess what? It then calls
that bridge method from the resulting byte-code.

In general, the compiler won't let Java code explicitly call synthetic
methods (e.g, it can't call the oddly named methods used to access
private members of enclosing classes.) Perhaps the use of the BRIDGE
flag is that it indicates synthetic methods that *can* be called under
some circumstances.

 

[Andreas Leitgeb]

Object o;
String s;
Object o2 = (Object)s;
int i = o2.compareTo(o);

That wouldn't work in any version of Java, since Object
has no method compareTo at all. It's only the Comparable that
introduces this method into the standard class library.
It could have been designed from the beginning of Comparable
that it's compareTo took only Comparable instead of arbitrary
Objects, but it wasn't. Wouldn't make much of a difference
now, anyway, except that the bridge method for compareTo
would likely also take a Comparable, otherwise.

In general, the compiler won't let Java code explicitly call synthetic
methods (e.g, it can't call the oddly named methods used to access
private members of enclosing classes.) Perhaps the use of the BRIDGE
flag is that it indicates synthetic methods that *can* be called under
some circumstances.

I guess, you're right here

How would the Java platform prevent abuse of those synthetic methods,
when the bytecode is not generated by a javac? It obviously doesn't
prohibit calls to such methods entirely, but how can it tell legit
internal uses from crafted bytecodes?
(Otoh., in the case of those bridges, there's really not much to
gain from cheat-calling them apart from a ClassCastException.)

 

[Mike Schilling]

That wouldn't work in any version of Java, since Object
has no method compareTo at all.

Damn, you're right, I was thinking of clone(). Never mind.

I guess, you're right here

How would the Java platform prevent abuse of those synthetic
methods,
when the bytecode is not generated by a javac? It obviously doesn't
prohibit calls to such methods entirely, but how can it tell legit
internal uses from crafted bytecodes?

As far as I know, it can't. The compiler could randomize the names of
the inner class accessors to make them more difficult to call, but as
far as I know it doesn't. At any rate, inner class accessors aren't
public, so they only create potential security holes within their
package.