Re: Reflection and parsing Java classfiles

"SAD" <> 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.

Brendan Guild

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

Chris Uppal

On Fri, 21 Oct 2005 10:46:10 +0100, Brendan Guild <> wrote:

> "SAD" <> 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 -

Ross Bamford

On Fri, 21 Oct 2005 11:05:31 +0100, Chris Uppal
<> 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 -

Ross Bamford

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

Chris Uppal

On Fri, 21 Oct 2005 12:26:57 +0100, Chris Uppal
<> 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 -

Ross Bamford

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

madhu.siddalingaiah@gmail.com