This sort of thing has definitely taken root in scala-land. Consider the
@BeanProperty annotation:
class Foo {
@BeanProperty var x
}
generates getX and setX as used by java stuff expecting beans (i.e. spring)
we also have @BeanInfo, which can be applied to a whole class and generates
accessors for all members.
On 14 June 2010 05:20, Bill Robertson <[email protected]> wrote:
> I added code generation to our project about a year and a half ago.
>
> .java --> javac --> @annotations --> .java (and .h)
>
> There is a wafer thin layer of native code that interacts with a
> message bus that we need to talk to. It has no real message format,
> you get five void pointers and you have to know how to pick out the
> data (or you define for your clients how to format the data). In our
> case the annotations describe how the data is un/marshalled for the
> native layer. We generate (quite readable) dispatching and
> unmarshalling code, and the header files contain code that can write
> the data to the bus in the correct format (think tie classes and
> client stub classes).
>
> Annotation processing in the compiler like this is quite powerful,
> although its a bit difficult to get started with it. It has been a
> huge benefit, because the code is simple enough to write in an
> automated fashion, and also a real pain to get right if you were doing
> it by hand. Also, like you mentioned, the annotations become the
> canonical description of the data layouts (at least when we're the
> callee), and the .java and .h artifacts are always in sync. Well,
> unless you cheat, then its just comedy when things fall apart.
>
> I also added another bit of code generation to the project recently.
>
> .g --> antlr --> .java
>
> This type of code generation has been around a long time too. Again,
> easy to describe to a computer and stupidly hard to get right if
> you're doing it by hand. I wouldn't put antlr's code into the "quite
> readable" category, but its readable enough.
>
>
> On Jun 5, 1:01 am, Christian Catchpole <[email protected]>
> wrote:
> > I think 2 is a solution but 1 can cause more problems that it solves -
> > because code generation is simply a transformation from one model to
> > another. So, if you can, why not just use the original model as it
> > stands, rather that create source and compiled artefacts. We find
> > though that code generation is often just used for binding. Its used
> > to fulfil language level requirements. eg. with ORM we export DB
> > schemas to beans because we need something to compile against.
> >
> > I think code generation is fundamentally a bad idea but obviously
> > necessary in some circumstances. It can highlight a discrepancy in a
> > language and / or a platform.
> >
> > I use janino to implement interfaces. But it's done at runtime, in
> > memory and essentially hidden. So it's a means to an end. And the
> > code generated does the minimum to satisfy the binding.
> >
> > So you would question any code gen that is more than a binding. If
> > you can, use the "information" / model etc in it's original form, then
> > surely that's a better way to go.
> >
> > But as Robert suggests (I think), if its somewhat transparent, it's
> > just "getting a job done" and it should neither be here nor there.
> > The problem of course is when it affects the lives of actual
> > programmers who write code that interacts with the generated code.
> >
> > On Jun 5, 12:32 pm, Robert Casto <[email protected]> wrote:
> >
> > > Something like ...
> >
> > > Description --> tool --> Java --> javac --> bytecode --> jit -->
> cpu
> >
> > > As software gets more complicated and is required to do more things
> there
> > > are only 2 choices.
> >
> > > 1. Write more code and generators can help here.
> > > 2. Languages that simplify the problem domain.
> >
> > > A code generator is really like a compiler. Its output is something you
> > > don't necessarily want to read. It does a lot of work for you and you
> hope
> > > that it is doing things correctly. I can't remember the last time I had
> to
> > > look at bytecode to debug a problem. I have had to look at the Java
> > > libraries a few times, but most of the time I stay above and trust that
> > > things are being done correctly. Generated code is the same thing. I
> don't
> > > care what the JSP, AOP, GWT, etc got compiled to.
> >
> > > These code generators could be what we think of compilers today. The
> > > alternative is to push this logic down into a language but all you have
> done
> > > is made it simpler to write more code. Whether it is expressed as Java
> or
> > > yet more bytecode, it feels like the same logic which has to be created
> in
> > > order to keep me at a high enough abstraction layer so I can get work
> done.
> >
> > > I would venture to say that out industry has been doing this since the
> > > beginning. We now have hardware that can encode and decode MP3 data. We
> have
> > > GPU's for handling graphics data and rendering pipelines. Everything
> gets
> > > pushed down a level once the method is well known and standardized. I
> think
> > > we are way past having to rely on 'magic' since my line above shows 6
> steps
> > > before what you wrote hits the CPU. We'll probably see a few more
> layers
> > > added before we retire.
> >
> > > Robert
> >
> > > On Fri, Jun 4, 2010 at 9:36 PM, Casper Bang <[email protected]>
> wrote:
> > > > Yeah but I was talking more about discrete generators at various
> steps
> > > > in the tool-chain and at runtime, not just a compiler.
> >
> > > > On Jun 4, 10:42 pm, Kevin Wright <[email protected]> wrote:
> > > > > Java --(javac)--> ByteCode --(hotspot)--> Native
> >
> > > > > Byte"Code" is not a misnomer, code generation has been common for
> years
> >
> > > > > Yes, it's common, and it's mainstream
> >
> > > > > On 4 June 2010 21:34, Casper Bang <[email protected]> wrote:
> >
> > > > > > Of course we've always had code generation and scaffolding tools,
> but
> > > > > > I get the feeling that it's gaining popularly and breaking into
> the
> > > > > > mainstream (i.e. not just Groovy, Rails etc.).
> >
> > > > > > GWT uses generation to the extreme for obvious reasons, Lombok
> uses
> > > > > > generation to make up for stale language evolution, Spring has
> always
> > > > > > been into low-level AOP kind of things, but their latest Roo
> framework
> > > > > > seems to embrace generation even further.
> >
> > > > > > So is this a general tendency all around, code generation
> becoming
> > > > > > mainstream? I've traditionally feared the day I can't do full
> round-
> > > > > > trip engineering in plain view but depend on magic generators and
> > > > > > IDE's (perhaps due to experiences with JDeveloper and the ADF
> > > > > > framework). Is this a good thing or a symptom of inferior
> languages
> > > > > > and lack of expressibility?
> >
> > > > > > --
> > > > > > You received this message because you are subscribed to the
> Google
> > > > Groups
> > > > > > "The Java Posse" group.
> > > > > > To post to this group, send email to [email protected].
> > > > > > To unsubscribe from this group, send email to
> > > > > > [email protected]<javaposse%[email protected]>
> <javaposse%2bunsubscr...@googlegroups .com>
> > > > <javaposse%2bunsubscr...@googlegroups .com>
> > > > > > .
> > > > > > For more options, visit this group at
> > > > > >http://groups.google.com/group/javaposse?hl=en.
> >
> > > > > --
> > > > > Kevin Wright
> >
> > > > > mail/google talk: [email protected]
> > > > > wave: [email protected]
> > > > > skype: kev.lee.wright
> > > > > twitter: @thecoda
> >
> > > > --
> > > > You received this message because you are subscribed to the Google
> Groups
> > > > "The Java Posse" group.
> > > > To post to this group, send email to [email protected].
> > > > To unsubscribe from this group, send email to
> > > > [email protected]<javaposse%[email protected]>
> <javaposse%2bunsubscr...@googlegroups .com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/javaposse?hl=en.
> >
> > > --
> > > Robert Castowww.IWantFreeShipping.com
> > > Find Amazon Filler Items easily!
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
--
Kevin Wright
mail/google talk: [email protected]
wave: [email protected]
skype: kev.lee.wright
twitter: @thecoda
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
