It looks like Ted didn't like my AOP JSR suggestion. Though Ted misunderstands the JCP process a little. The JCP process is just that, a process. It can define an API that can be used on any JDK version it wishes. A JSR does not have to tie itself or integrate itself into any of the big API bundles (JDK or J2EE). Also there is no fixed time schedule, so there's no need to rush things to force a standard.
All of Ted's criticisms are actually criticisms of Sun's bundling policy with the JDK. I agree with you here Ted. Another example is the JSR for logging - which is next to useless as few developers can still assume all their clients are JDK 1.4 or greater (backwards compatibility is important). So instead people stick with log4j or commons logging (a lightweight facade, not tied to a particular JDK, which can use log4j, logkit or JDK 1.4 logging).
A note about pull parsing; there is a pull parsing JSR, StAX and its making great progress. The expert group combined various people, from some open source projects (XPP and dom4j) and BEA who'd created a pull parser as well as learning from MS's pull parser. So far its looking pretty good. Its not tied to any particular JDK.
Also I don't see how having a standard API to, say, an interceptor could somehow disallows competition. Indeed I think if there was a standard API to define interceptors, AOP could take off in an even bigger way. There's still plenty of room for innovation on how pointcuts work & how bytecode is swizzled and such like.
Anyways, back to the AOP JSR. I agree we maybe still don't know enough about AOP just yet; though there does seem a lot of common ground over at least the interceptor side of things. If the AOP JSR took place then it would be a forum to try find some common ground and it would be up to the AOP experts to collectively decide if there was any common ground and if so what it is. If the AOP JSR expert group decides there is no common ground, then thats fine too at least we tried.
7:45:25 AM 
|
