Re: Reflection and parsing Java classfiles

Discussion in 'Java' started by Brendan Guild, Oct 21, 2005.

  1. "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/Articles/MadhuOct2005_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, Oct 21, 2005
    #1
    1. Advertising

  2. Brendan Guild

    Chris Uppal Guest

    Brendan Guild wrote:

    > > http://www.webservicessummit.com/Articles/MadhuOct2005_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, Oct 21, 2005
    #2
    1. Advertising

  3. Brendan Guild

    Ross Bamford Guest

    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/Articles/MadhuOct2005_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, Oct 21, 2005
    #3
  4. Brendan Guild

    Ross Bamford Guest

    On Fri, 21 Oct 2005 11:05:31 +0100, Chris Uppal
    <-THIS.org> wrote:

    > Brendan Guild wrote:
    >
    >> > http://www.webservicessummit.com/Articles/MadhuOct2005_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, Oct 21, 2005
    #4
  5. Brendan Guild

    Chris Uppal Guest

    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, Oct 21, 2005
    #5
  6. Brendan Guild

    Ross Bamford Guest

    On Fri, 21 Oct 2005 12:26:57 +0100, Chris Uppal
    <-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 -
     
    Ross Bamford, Oct 21, 2005
    #6
  7. Brendan Guild

    Guest

    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
     
    , Oct 21, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. A. Wiebenga

    Reflection in Java - Please help..

    A. Wiebenga, Feb 6, 2004, in forum: Java
    Replies:
    2
    Views:
    510
    Tony Morris
    Feb 8, 2004
  2. Replies:
    23
    Views:
    5,589
  3. Benjamin Johnston
    Replies:
    1
    Views:
    489
    Mike Schilling
    Jan 6, 2005
  4. Lee

    WSIF and Java Reflection

    Lee, Jul 28, 2006, in forum: Java
    Replies:
    0
    Views:
    298
  5. pek
    Replies:
    2
    Views:
    1,093
Loading...

Share This Page