Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: Reflection and parsing Java classfiles

Reply
Thread Tools

Re: Reflection and parsing Java classfiles

 
 
Brendan Guild
Guest
Posts: n/a
 
      10-21-2005
"SAD" <(E-Mail Removed)> wrote in news:1129777988.703099.191080
@g47g2000cwa.googlegroups.com:

> This article describes a grammar and simple parser for processing Java
> classfiles:
> http://www.webservicessummit.com/Art...uOct2005_1.htm


It seems like abuse of reflection to me, especially since it depends on
undefined behaviour. I'm sure it works, but it is assuming that the
fields of a class are ordered when they are not. It's just lucky that
getDeclaredFields() happens to return the fields in the order that they
appear in the source, otherwise this whole concept would be totally
useless.
 
Reply With Quote
 
 
 
 
Chris Uppal
Guest
Posts: n/a
 
      10-21-2005
Brendan Guild wrote:

> > http://www.webservicessummit.com/Art...uOct2005_1.htm

>
> It seems like abuse of reflection to me, especially since it depends on
> undefined behaviour. I'm sure it works, but it is assuming that the
> fields of a class are ordered when they are not. It's just lucky that
> getDeclaredFields() happens to return the fields in the order that they
> appear in the source, otherwise this whole concept would be totally
> useless.


Yes, the JavaDoc for getDeclaredFields() specifically states that the order of
entries is undefined. Bad Madhu ! Bad !

But still, it'd not be hard to fix up by adding some explicit metadata to the
target class. The /concept's/ OK, even if the implementation takes one
short-cut too many.

-- chris




 
Reply With Quote
 
 
 
 
Ross Bamford
Guest
Posts: n/a
 
      10-21-2005
On Fri, 21 Oct 2005 10:46:10 +0100, Brendan Guild <(E-Mail Removed)> wrote:

> "SAD" <(E-Mail Removed)> wrote in news:1129777988.703099.191080
> @g47g2000cwa.googlegroups.com:
>
>> This article describes a grammar and simple parser for processing Java
>> classfiles:
>> http://www.webservicessummit.com/Art...uOct2005_1.htm

>
> It seems like abuse of reflection to me, especially since it depends on
> undefined behaviour. I'm sure it works, but it is assuming that the
> fields of a class are ordered when they are not. It's just lucky that
> getDeclaredFields() happens to return the fields in the order that they
> appear in the source, otherwise this whole concept would be totally
> useless.



I'd be very careful about the term 'reflection' from the start, since this
blatantly isn't it. I've had some fairly heated discussions during the
development of Jen about the use of that term, mainly because "it's a
common term", but I think it's deeper than that and it's wrong to claim
inaccurate facts, simply because people are likely to "know what you mean".

In docs and stuff we sometimes refer to these techniques as an
"alternative to reflection", but are always careful to make sure that we
don't claim it's reflection, because it's not (e.g. there's no mirroring
going on, and no link real between the values you get and any runtime
values).

--
Ross Bamford - http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Ross Bamford
Guest
Posts: n/a
 
      10-21-2005
On Fri, 21 Oct 2005 11:05:31 +0100, Chris Uppal
<(E-Mail Removed)-THIS.org> wrote:

> Brendan Guild wrote:
>
>> > http://www.webservicessummit.com/Art...uOct2005_1.htm

>>
>> It seems like abuse of reflection to me, especially since it depends on
>> undefined behaviour. I'm sure it works, but it is assuming that the
>> fields of a class are ordered when they are not. It's just lucky that
>> getDeclaredFields() happens to return the fields in the order that they
>> appear in the source, otherwise this whole concept would be totally
>> useless.

>
> Yes, the JavaDoc for getDeclaredFields() specifically states that the
> order of
> entries is undefined. Bad Madhu ! Bad !
>
> But still, it'd not be hard to fix up by adding some explicit metadata
> to the
> target class. The /concept's/ OK, even if the implementation takes one
> short-cut too many.
>


Thinking more about it, there isn't even any guarantee that the constant
pool is the same at runtime - the JVM is free to reorder and remove
entries as it sees fit, as long as it fixes up the references. For
example, when using the java.lang.instrument API in Mustang, the new
retransform classes feature specifically states that the constant pool in
the byte[] passed in is unlikely to be the same as the .class file, owing
to these optimizations.

Also, I don't think theres all that much of use to the programmer in the
pool - beyond classes, primitives and strings it's mainly the (internal)
method descriptors and stuff for invokexxxx instructions. Most of the
'constants' (I expect) in many classes are actually initialized in the
class init method.

I stand by my original comment, though, that it was a nice article. The
concept is good, and the implementation wasn't the point I guess.

--
Ross Bamford - (E-Mail Removed)
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      10-21-2005
Ross Bamford wrote:

> > It seems like abuse of reflection to me, [...]


> I'd be very careful about the term 'reflection' from the start, since this
> blatantly isn't it.


You may already have realised this, but I think Brendan was referring
specifically to the use of reflection (java.lang.Class.getDeclaredFields()) to
drive the parser from a list of the fields in the target/template class
(ClassFile).

-- chris


 
Reply With Quote
 
Ross Bamford
Guest
Posts: n/a
 
      10-21-2005
On Fri, 21 Oct 2005 12:26:57 +0100, Chris Uppal
<(E-Mail Removed)-THIS.org> wrote:

> Ross Bamford wrote:
>
>> > It seems like abuse of reflection to me, [...]

>
>> I'd be very careful about the term 'reflection' from the start, since
>> this
>> blatantly isn't it.

>
> You may already have realised this, but I think Brendan was referring
> specifically to the use of reflection
> (java.lang.Class.getDeclaredFields()) to
> drive the parser from a list of the fields in the target/template class
> (ClassFile).
>
> -- chris
>


Oh. I'll shut up then.

I thought OP was referring to the technique itself, but reading more
carefully now I see I should have read more carefully in the first place

--
Ross Bamford - (E-Mail Removed)
 
Reply With Quote
 
madhu.siddalingaiah@gmail.com
Guest
Posts: n/a
 
      10-21-2005
Well I'm glad someone thought it was a nice article!
The issue that getDeclaredFields() doesn't guarantee the order of
fields in the source concerned and annoyed me. I chose not to get into
it at the time, that's one of the reasons I didn't release the source
just yet. I wanted to address that issue (and a couple of others)
before releasing the code.

The point I wanted to make was that a small amount of code could solve
a significant class of problems. Looks like you got the point.

--
Madhu Siddalingaiah
http://www.madhu.com

 
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
Combining Java Reflection API with Java Annotation Types for Thread Safety pek Java 2 10-23-2007 03:00 PM
WSIF and Java Reflection Lee Java 0 07-28-2006 12:21 PM
Java Reflection: Is there an inverse of Class.getComponentType() Benjamin Johnston Java 1 01-06-2005 06:36 AM
Java Reflection Exception Jungle alan@engrm.com Java 23 01-04-2005 08:18 PM
Reflection in Java - Please help.. A. Wiebenga Java 2 02-08-2004 10:11 AM



Advertisments