Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #7910
| From | Alex J <vstrength@gmail.com> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Annotations processing + type introspection + code generation |
| Date | 2011-09-12 11:08 -0700 |
| Organization | http://groups.google.com |
| Message-ID | <a91ceb4b-0cd8-4a0d-91bb-c44e2f1bafba@o9g2000vbo.googlegroups.com> (permalink) |
| References | <b4cda2f5-442e-42f3-af75-5040215ba997@k15g2000yqd.googlegroups.com> <9d6rupF6dkU1@mid.individual.net> <j4le3e$f7m$1@dont-email.me> <9d6tflFhe3U2@mid.individual.net> |
On Sep 12, 9:22 pm, Robert Klemme <shortcut...@googlemail.com> wrote: > On 12.09.2011 19:04, markspace wrote: > > > > > > > > > > > On 9/12/2011 9:56 AM, Robert Klemme wrote: > > >> The only reason I can think of which would require to generate code > >> would be ultra high speed requirements. > > > I think generated code is somewhat more common that you assume. Since > > the JVM byte codes and class format is public and relatively stable, > > it's quite easy to generate code in a manner that's compatible with > > many, or all, JVMs. > > > There's also things you can't do at runtime. For example, the Proxy > > class requires an interface to extend. But many POJO objects don't > > declare a separate interface. And requiring the programmer to declare an > > interface for all POJO types within a framework is pretty odious, and > > old school. > > > I'm playing around with JSF and JPA right now. I notice that all my > > Entity classes are decorated by extending them with generated code. I'm > > sure if there were a better way to do it, they would. But the generated > > code seems to be the way to go in this instance. > > OK, good point! I had generation of boilerplate code (e.g. via things > like XDoclet) in mind which is really 20th century. :-) Depending on > the use case reflection could still be sufficiently fast enough - and > it's likely simpler than byte code generation. XDoclet (http://en.wikipedia.org/wiki/XDoclet, right?) looks quite frightening :) Well, it's not a problem to generate code by simple print calls, entirely without AST or things like that. The main issue is the power enough type introspection as I need to know object model and sometimes methods implementation before code generation. Annotations processing API does not fit my needs, that's why I started to learn javac internals to cast APT interfaces to javac internal interfaces to access AST. > > Kind regards > > robert > > -- > remember.guy do |as, often| as.you_can - without endhttp://blog.rubybestpractices.com/
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
Annotations processing + type introspection + code generation Alex J <vstrength@gmail.com> - 2011-09-12 06:21 -0700
Re: Annotations processing + type introspection + code generation Robert Klemme <shortcutter@googlemail.com> - 2011-09-12 18:56 +0200
Re: Annotations processing + type introspection + code generation markspace <-@.> - 2011-09-12 10:04 -0700
Re: Annotations processing + type introspection + code generation Robert Klemme <shortcutter@googlemail.com> - 2011-09-12 19:22 +0200
Re: Annotations processing + type introspection + code generation Alex J <vstrength@gmail.com> - 2011-09-12 11:08 -0700
Re: Annotations processing + type introspection + code generation Alex J <vstrength@gmail.com> - 2011-09-12 11:00 -0700
Re: Annotations processing + type introspection + code generation Robert Klemme <shortcutter@googlemail.com> - 2011-09-12 20:21 +0200
Re: Annotations processing + type introspection + code generation Alex J <vstrength@gmail.com> - 2011-09-12 15:06 -0700
csiph-web