JSR-14 (WAS: [OT] thoughts on Java pre processor)

[Tim Moore <tm...@blackboard.com>]

This is tangential to the point of the thread, but there is an early
access prototype for a JSR-14 compatible compiler.

http://developer.java.sun.com/developer/earlyAccess/adding_generics/

I think there's still some promise that this will be added in JDK 1.5
(slated for mid-2003).
-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


> -----Original Message-----
> From: Colin Sharples [mailto:sharples@nz1.ibm.com] 
> Sent: Wednesday, March 06, 2002 3:13 PM
> To: Jakarta Commons Developers List
> Subject: Re: [OT] thoughts on Java pre processor
> 
> 
> 
> > 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.
> 
> Yah - I backtracked pretty quickly once I thought about it :-)
> 
> > > 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...
> 
> Both JSR-14 and JSR-65 look pretty stalled. I thought I saw 
> somewhere that JSR-65 was originally intended for Merlin, but 
> got shelved because of time constraints. Hmm. Both of these 
> are fairly piecemeal additions. It seems to me that you're 
> suggesting something more like a generic way to add 
> pre-processor type additions to the language - something that 
> would cope with parameterized types, array literals, event 
> handling etc. All of these things are basically saying that 
> there are standard bits of code that could be expressed more 
> concisely (and safely) using some abbreviated syntax. The 
> property one is actually a good example - I've been bitten a 
> couple of times because of some small deviation from the 
> JavaBeans conventions over property naming meaning that a 
> bean property is not recognised. Being able to explicitly 
> declare an attribute as a JavaBean property would get round that.
> 
> > 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.
> 
> Sadly I got pulled off that project onto another one, so I 
> didn't get round to combining Messenger and Workflow as I 
> intended. If I get some bench time soon I would still like to 
> have a look at that, coz it seemed like a good idea.
> 
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>