commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: [OT] thoughts on Java pre processor
Date Wed, 06 Mar 2002 14:06:45 GMT
Hey Colin

----- Original Message -----
From: "Colin Sharples" <sharples@nz1.ibm.com>
> > 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. .
>
> But using a decent IDE such as Eclipse* eliminates the need for all that
by
> automating the generation of boilerplate code using templates. Using a
> pre-processor to avoid typing code is pretty pointless, IMHO. Just get a
> better tool.

Its not the generation I'm concerned about - I know there are tools to do
this. Its the fact that spitting out all this code becomes harder to
maintain. e.g. its very common for the javadoc comments on the member
variable, getter & setter of a property to get stale or even meaningless.
Tools usually spit out pretty crap javadoc comments. So its more about easy
maintainability & readability than just creating reams of code in a
wizard-like way. If there was just one javadoc comment describing a property
or event, its more likely to be written & kept up to date.


> Where pre-processor type activity *is* useful is for adding things like
> generic types - in other words, where you are changing the semantics of
the
> code by enriching an existing concept. Having a generic (parameterized)
> type means that you can enforce type-safety of of single-type collections,
> e.g. declare a list of Strings that will throw an exception if you try to
> add an Integer. JSR-14 is working on this already, so it could be
> counter-productive to come up with something similar.

No I agree, parameterized types are another extension. Though I've no idea
when JSR-14 is actually gonna be a reality. Pizza & GJ have been around for
ages; I was even musing about adding these extensions to GJ...


> Okay, I'm being a bit harsh - the JavaBean property example is valid
> enough, as is the event listener. I think the main thing is to distinguish
> between shortcuts just to save typing (like the foreach) and real patterns
> (like events and properties).

Yes good point. Its the real patterns I'm more interested in really.

> Another proposal that is more like your "syntactic sugar" usage is
JSR-65 -
> concise object array literals, which would convert:
> ArrayList al = new ArrayList({ "foo", 10, 0.75});
> into:
> ArrayList al = new ArrayList(new Object[] { "foo", new Integer(10), new
> Double(0.75)});

Agreed.

BTW how's the JMS/workflow stuff going Colin? I'm starting to turn my
attention more to SOAP/JMS workflow thoughts these days, just wondered how
you were doing.

James

> * Yes, I know there are other good IDEs out there. Emacs JDE, for example.
> I believe there also something called NutBones or something like that :-)
>
> Regards
>
> Colin M Sharples
> I/T Architect
> IBM Global Services New Zealand
>
> email: sharples@nz1.ibm.com
> phone: 64-4-5769853
> mobile: 64-21-402085
> fax: 64-4-5765616
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message