You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Strachan <ja...@yahoo.co.uk> on 2002/03/06 02:55:25 UTC
[OT] thoughts on Java pre processor
This is kinda off topic but I've been musing lately about a preprocessor for
Java. One of the early attractions to me about Java some 5-6 years ago
coming from a mostly C++ background was that there was no pre processor and
obfuscation, so Java code was very easy to read.
However in theses groovy days of having Ant to do all our building, JUnit
for unit testing and the various logging packages for logging, we rarely
need much from an IDE these days but a basic editor (does anyone even use
debuggers any more?), so maybe diverging from the Java Language spec
wouldn't be too bad. .
So I was thinking that maybe a preprocessor might now gain momentum since
* it can be an Ant task and integrate seamlessly into any build
* it can spit out regular Java code so even though the pre processor would
be 'non standard' it could become useful.
So the aim of the preprocessor would be to allow us to add some syntax
suguar to Java to save us some typing and avoid redundancy. I just wondered
what others thoughts are. Here's a couple of ideas for some syntax sugar...
Easier properties
============
Imagine a typical property definition in a Java bean....
/**
* This is a foo property
*/
private Foo foo;
/**
* Gets the value of the foo property
*
* @return the foo property
*/
public Foo getFoo() {
return foo
}
/**
* Sets the value of the foo property
*
* @param foo the new value of the foo property
*/
public void setFoo(Foo foo) {
this.foo = foo;
}
Its quite a lot to type and takes up quite a bit of code. Also notice the
redundancy in the javadoc comments. We should be able to just describe the
property and the javadoc could be generated. I'd quite like some syntax
sugar (similar to in C#) to allow the property to be javadoc commented just
once and to save typing. e.g.
/** This is a foo property */
private property Foo foo {
get {
return foo;
}
set {
this.foo = value;
}
}
For most simple properies this could be simplified as just
/** This is a foo property */
private property Foo foo;
Maybe even extending this to provide 'lazy construction' properties which
expand to look like this...
/**
* @return the value of the foo property
* which will be created lazily if it is null
*/
public Foo getFoo() {
if ( foo == null ) {
foo = createFoo();
}
return foo;
}
/**
* Factory method to create a new Foo object
* which allows derived classes to override this
* behaviour
*/
protected Foo createFoo() {
return new Foo();
}
This could maybe appear as syntax sugar as....
private lazy property Foo foo {
create {
return new Foo();
}
}
The get & set methods could be defaulted if not specified.
Easier events
=========
Similar techniques to the above could be done to avoid developers having to
manage event listeners and write code to fire them etc.
foreach?
======
To help avoid repetive code of the form...
for ( Iterator iter = something.iterator(); iter.hasNext(); ) {
Foo foo = (Foo) iter.next();
foo.bar();
}
maybe introduce a C#-like foreach statement...
foreach( Foo foo in something.iterator() ) {
foo.bar();
}
Just thinking aloud here (as always ;-). Thoughts?
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Mar 06, 2002 at 01:55:25AM -0000, James Strachan wrote:
...
> So the aim of the preprocessor would be to allow us to add some syntax
> suguar to Java to save us some typing and avoid redundancy. I just wondered
> what others thoughts are. Here's a couple of ideas for some syntax sugar...
...
> foreach?
> ======
> To help avoid repetive code of the form...
>
> for ( Iterator iter = something.iterator(); iter.hasNext(); ) {
> Foo foo = (Foo) iter.next();
> foo.bar();
> }
>
> maybe introduce a C#-like foreach statement...
>
> foreach( Foo foo in something.iterator() ) {
> foo.bar();
> }
and maybe throw in some logging syntax, which can be compiled to log4j,
the Commons logger or compiled out altogether.
--Jeff
(who once did write a preprocessor to let you embed declarative XML
statements like <debug level="1">This is a debug statement</debug> in
Java. It worked by converting the marked up .java to XML, then applying
stylesheets ala XSP to transform <debug> to code, then stripping the XML
tags to get .java again. I thought it was neat :)
>
>
> Just thinking aloud here (as always ;-). Thoughts?
>
> James
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
> > It seems to me that this has already been done. Take a look at AspectJ:
> >
> > http://aspectj.org/
> >
> > Aspect Oriented Programming (AOP) applied to Java.
>
> I see how Aspects can be added to Java code using aspectj but I don't see
> how it can be used to provide higher level macros like more concise
property
> & event code in a bean. Any ideas?
>
> James
>
It lets intercept methods to fire events, introduce Listeners .... .
It is very good idea.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by James Strachan <ja...@yahoo.co.uk>.
----- Original Message -----
From: "Martin Cooper" <ma...@tumbleweed.com>
> It seems to me that this has already been done. Take a look at AspectJ:
>
> http://aspectj.org/
>
> Aspect Oriented Programming (AOP) applied to Java.
I see how Aspects can be added to Java code using aspectj but I don't see
how it can be used to provide higher level macros like more concise property
& event code in a bean. Any ideas?
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by Martin Cooper <ma...@tumbleweed.com>.
It seems to me that this has already been done. Take a look at AspectJ:
http://aspectj.org/
Aspect Oriented Programming (AOP) applied to Java.
--
Martin Cooper
----- Original Message -----
From: "James Strachan" <ja...@yahoo.co.uk>
To: "Jakarta Commons Developers" <co...@jakarta.apache.org>
Sent: Tuesday, March 05, 2002 5:55 PM
Subject: [OT] thoughts on Java pre processor
> This is kinda off topic but I've been musing lately about a preprocessor
for
> Java. One of the early attractions to me about Java some 5-6 years ago
> coming from a mostly C++ background was that there was no pre processor
and
> obfuscation, so Java code was very easy to read.
>
> However in theses groovy days of having Ant to do all our building, JUnit
> for unit testing and the various logging packages for logging, we rarely
> need much from an IDE these days but a basic editor (does anyone even use
> debuggers any more?), so maybe diverging from the Java Language spec
> wouldn't be too bad. .
>
> So I was thinking that maybe a preprocessor might now gain momentum since
>
> * it can be an Ant task and integrate seamlessly into any build
> * it can spit out regular Java code so even though the pre processor would
> be 'non standard' it could become useful.
>
> So the aim of the preprocessor would be to allow us to add some syntax
> suguar to Java to save us some typing and avoid redundancy. I just
wondered
> what others thoughts are. Here's a couple of ideas for some syntax
sugar...
>
>
> Easier properties
> ============
> Imagine a typical property definition in a Java bean....
>
> /**
> * This is a foo property
> */
> private Foo foo;
>
> /**
> * Gets the value of the foo property
> *
> * @return the foo property
> */
> public Foo getFoo() {
> return foo
> }
>
> /**
> * Sets the value of the foo property
> *
> * @param foo the new value of the foo property
> */
> public void setFoo(Foo foo) {
> this.foo = foo;
> }
>
>
> Its quite a lot to type and takes up quite a bit of code. Also notice the
> redundancy in the javadoc comments. We should be able to just describe the
> property and the javadoc could be generated. I'd quite like some syntax
> sugar (similar to in C#) to allow the property to be javadoc commented
just
> once and to save typing. e.g.
>
>
> /** This is a foo property */
> private property Foo foo {
> get {
> return foo;
> }
> set {
> this.foo = value;
> }
> }
>
>
> For most simple properies this could be simplified as just
>
> /** This is a foo property */
> private property Foo foo;
>
>
> Maybe even extending this to provide 'lazy construction' properties which
> expand to look like this...
>
> /**
> * @return the value of the foo property
> * which will be created lazily if it is null
> */
> public Foo getFoo() {
> if ( foo == null ) {
> foo = createFoo();
> }
> return foo;
> }
>
> /**
> * Factory method to create a new Foo object
> * which allows derived classes to override this
> * behaviour
> */
> protected Foo createFoo() {
> return new Foo();
> }
>
>
> This could maybe appear as syntax sugar as....
>
> private lazy property Foo foo {
> create {
> return new Foo();
> }
> }
>
> The get & set methods could be defaulted if not specified.
>
>
> Easier events
> =========
> Similar techniques to the above could be done to avoid developers having
to
> manage event listeners and write code to fire them etc.
>
> foreach?
> ======
> To help avoid repetive code of the form...
>
> for ( Iterator iter = something.iterator(); iter.hasNext(); ) {
> Foo foo = (Foo) iter.next();
> foo.bar();
> }
>
> maybe introduce a C#-like foreach statement...
>
> foreach( Foo foo in something.iterator() ) {
> foo.bar();
> }
>
>
> Just thinking aloud here (as always ;-). Thoughts?
>
> James
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Henri Yandell" <ba...@generationjava.com>
> Because I've never understood this, what is with the habit of using
> Enumeration and Iterators in for loops?
>
> What does it have over the while loop version? Just the fact it keeps the
> 'iter' variable in the loops scope?
Yes. So I think this is possible
for ( Iterator iter = foo.iterator(); iter.hasNext(); ) {
..
}
for ( Iterator iter = bar.iterator(); iter.hasNext(); ) {
..
}
> [as for foreach, I would love to have one. It should also handle Maps a la
> foreach(Object key, String value in map) {
> ...
> }
> and handle the cast to a String automatically.
> ]
Agreed - that'd be nice.
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by Henri Yandell <ba...@generationjava.com>.
Because I've never understood this, what is with the habit of using
Enumeration and Iterators in for loops?
What does it have over the while loop version? Just the fact it keeps the
'iter' variable in the loops scope?
[as for foreach, I would love to have one. It should also handle Maps a la
foreach(Object key, String value in map) {
...
}
and handle the cast to a String automatically.
]
> foreach?
> ======
> To help avoid repetive code of the form...
>
> for ( Iterator iter = something.iterator(); iter.hasNext(); ) {
> Foo foo = (Foo) iter.next();
> foo.bar();
> }
>
> maybe introduce a C#-like foreach statement...
>
> foreach( Foo foo in something.iterator() ) {
> foo.bar();
> }
>
>
> Just thinking aloud here (as always ;-). Thoughts?
>
> James
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by Henri Yandell <ba...@generationjava.com>.
Because someone has to do it. How about a C# to bytecode compiler :) The
opposite of MS' J# plugin for VisStudio.
On Wed, 6 Mar 2002, James Strachan wrote:
> I was more thinking of should we try define a Java++ language but I take
> your point.
>
> James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Jon Scott Stevens" <jo...@latchkey.com>
> This is the perfect job for Velocity. :-)
>
> Just use Velocity to generate your .java code.
I guess I walked right into that one ;-)
I was more thinking of should we try define a Java++ language but I take
your point.
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by Jon Scott Stevens <jo...@latchkey.com>.
This is the perfect job for Velocity. :-)
Just use Velocity to generate your .java code.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/5/02 8:55 PM, "James Strachan" <ja...@yahoo.co.uk> wrote:
> To help avoid repetive code of the form...
>
> for ( Iterator iter = something.iterator(); iter.hasNext(); ) {
> Foo foo = (Foo) iter.next();
> foo.bar();
> }
>
> maybe introduce a C#-like foreach statement...
>
> foreach( Foo foo in something.iterator() ) {
> foo.bar();
> }
>
>
> Just thinking aloud here (as always ;-). Thoughts?
We'd prefer if you'd refer to it as a "Velocity-like foreach statement"
;)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by bob mcwhirter <bo...@werken.com>.
> Just thinking aloud here (as always ;-). Thoughts?
My only thought is the lack of a directive to allow the compiler to tell
you the file/line of any errors. I'm rusty on my C++, but I seem to
recall they had a #file directive, so that the post-processed file, when
compiled, could signal errors with regards to pre-processed source files.
It'd be strange to have one of your 15-line files, and have the compiler
report an error on line 38 (after expansion).
What you're really doing is defining a new syntax to generate valid
bytecodes, not unlike PythonJ (or whatever it's called).
Why not just avoid the javac step, and emit bytecodes from your new
syntax anyhoo. Sure, we miss out standard compiler optimizations,
which could suck, but for the simple Easy-To-Write-JavaBean example,
it may be sufficient. Or, maybe just glue a front-end onto the
IBM Jikes back-end, where all we do is some AST translation into
what the backend normally expects.
-bob
(I like to parse)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] thoughts on Java pre processor
Posted by Henri Yandell <ba...@generationjava.com>.
I would like to see the ability to return multiple objects. Not sure if
this would be easy to do as it would require the preprocessor to work
across files, but I would like to do:
int i;
String str;
(i, str) = runCode();
I would also like to see a preprocessor for mathematical Java that can
happily handle:
x=5 PI * i
y=x^7 + 2x
z=x + yi
and turns it into Java which accepts that 'i' is passed in, PI is a
constant and the a + bi syntax means a complex number (using JNL).
Actually, it would need to be written in unicode thus allowing all
mathematical symbols to be used.
Anyway, this isn't quite what James is after, but I think it would be
sweet. Mathematics could plug into Java without having to lose its beauty
in Java's ugly syntactical world.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>