Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #7910

Re: Annotations processing + type introspection + code generation

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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