Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Class Viewer, Google searches, and rankings

Reply
Thread Tools

Class Viewer, Google searches, and rankings

 
 
JSH
Guest
Posts: n/a
 
      08-31-2008
On Aug 30, 6:58*pm, "Mike Schilling" <(E-Mail Removed)>
wrote:
> Mike Schilling wrote:
> > Andreas Leitgeb wrote:
> >> JSH <(E-Mail Removed)> wrote:
> >>>> On Aug 24, 2:03 am, Andreas Leitgeb
> >>>> <(E-Mail Removed)>
> >>>> wrote:
> >>>>> JSH <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Andreas Leitgeb
Guest
Posts: n/a
 
      08-31-2008
Mike Schilling <(E-Mail Removed)> wrote:
>> 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;
>> }

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.

>> This behavior is simple enough to reproduce. Try compiling
>> class Gunk implements Comparable<Gunk>
>> {
>> public int compareTo(Gunk g)
>> {
>> return 0;
>> }
>> public Gunk clone()
>> {
>> return this;
>> }
>> }


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

 
Reply With Quote
 
 
 
 
Joshua Cranmer
Guest
Posts: n/a
 
      08-31-2008
Andreas Leitgeb wrote:
> 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...

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      09-01-2008
Joshua Cranmer <(E-Mail Removed)> wrote:
> 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.

 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      09-01-2008
Andreas Leitgeb wrote:
> Joshua Cranmer <(E-Mail Removed)> wrote:
>> 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).


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.


 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      09-01-2008
Mike Schilling <(E-Mail Removed)> wrote:
> 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.)

 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      09-01-2008
Andreas Leitgeb wrote:
> Mike Schilling <(E-Mail Removed)> wrote:
>> 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.


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


>> 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?


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.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
I need help speeding up an app that reads football scores and generates rankings jocknerd Python 4 05-02-2007 05:09 PM
High Traffic Google Page Rankings Website? Heidi Manway NZ Computing 8 01-25-2007 08:53 AM
New Website and Getting Traffic-High Google Page Rankings Heidi Manway Computer Support 2 01-23-2007 09:30 PM
Google rankings when going from html to xml Don XML 5 06-13-2005 11:21 PM
Amelia Island, Casablanca SF Rankings Robert B. Waltz Computer Support 1 04-10-2004 09:17 PM



Advertisments