 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2005Reflection and parsing Java classfiles
This article describes a grammar and simple parser for processing Java classfiles: http://www.webservicessummit.com/Articles/MadhuOct2005_1.htm There's a discussion thread at antlr.org about an ANTLR grammar for parsing Java classfiles. It mentions a jGuru search system for classes and methods. Is that source code available anywhere? It is better to get Bytecode Grammar from ANTLR Site; http://www.antlr.org/ This grammar is not full. There are missed some Constant Pool types, no Stack Map structure, etc. I have made my own full ByteCode Grammar with ANTLR that builds AST and then I can modify this AST and generate the ByteCode file with it. > This article describes a grammar and simple parser for processing Java > classfiles: [quoted text clipped - 3 lines] > parsing Java classfiles. It mentions a jGuru search system for classes > and methods. Is that source code available anywhere? > This article describes a grammar and simple parser for processing Java > classfiles: [quoted text clipped - 3 lines] > parsing Java classfiles. It mentions a jGuru search system for classes > and methods. Is that source code available anywhere? That's not a bad article, and judging by some of the tools I've seen theres many who'd do well to read it :) You might be interested in a project I've been working on lately, which creates a model of a class much as you suggest (using ASM in this case) and then provides a high-level interface for working with it. It's at http://jen.dev.java.net/ As you say the performance is generally surprising too - I believe it's partly down to the simplicity of the format, which also helps with getting Java into mobile devices and the like, and partly down to misconception (perhaps a blurring of the line between loading and resolving)... I'm afraid I don't know the search system you mention, but it occurs to me that both refactoring and obfuscation would use that kind of thing, so you could try finding OSS ones and browsing their source.  SignatureRoss Bamford - rosco@roscopeco.remove.co.uk "SAD" <sadavis68@netscape.net> 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. > > http://www.webservicessummit.com/Articles/MadhuOct2005_1.htm > [quoted text clipped - 4 lines] > 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 >> > http://www.webservicessummit.com/Articles/MadhuOct2005_1.htm >> [quoted text clipped - 13 lines] > 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. SignatureRoss Bamford - rosco@roscopeco.remove.co.uk 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 > "SAD" <sadavis68@netscape.net> wrote in news:1129777988.703099.191080 > @g47g2000cwa.googlegroups.com: [quoted text clipped - 9 lines] > 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). SignatureRoss Bamford - rosco@roscopeco.remove.co.uk > > 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 >> > It seems like abuse of reflection to me, [...] > [quoted text clipped - 9 lines] > > -- 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 :) SignatureRoss Bamford - rosco@roscopeco.remove.co.uk Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.