Community
Participate
Working Groups
Java 6.0, that was released on last week comes bundled with JAX-WS, that suports very easy webservice client/server development through annotations. However, while trying the following example in Eclipse: http://weblogs.java.net/blog/vivekp/archive/2006/12/webservices_in.html I noted that: 1 - I had to enable annotation processing manually on my java project settings. 2 - Although I had my java project associated with a JDK 6.0 and annotation processing enabled, it didn't generated the wrapper classes. 3 - After very much research, I found out that you have to go to the project settings -> Annotation Processing -> Factory Path -> enable project settings -> add external jar -> add tools.jar from JDK 6.0 (--> this is where the JAX-WS annotation processor is). My complaints: - (1) would be a little confusing for newbies but it is OK in my opinion. - (2) and (3) are very bad, because if you execute command line apt it recognizes the JDK's annotation processors. Why doesn't Eclipse can auto-detect this? It requires a lot of manual configuration.
Interesting. I didn't know that Sun was including any annotation processors in the JDK itself and also turning them on by default. I'm not sure that we should emulate javac in this case precisely, as it would likely slow down compilation significantly in the case of annotation processing without JAX-WS annotations, but we should consider making it easier to add and enable the processors in tools.jar
Jess, this is not handled by javac, but by Sun's apt.exe, that considers tools.jar on annotation processors computation. I think at least Eclipse's APT should do the same and provide a better out-of-box experience, zero configuration. A good argument is that it works out-of-box on Netbeans :)
(In reply to comment #2) > Jess, this is not handled by javac, but by Sun's apt.exe, that considers > tools.jar on annotation processors computation. In Java 6, annotation processing is done by javac itself. Apt.exe is only for Java 5 annotation processing, that is, processors that use the (deprecated as of Java 6) com.sun.mirror interface. Java 6 processors use the standard interface that was introduced via JSR269, in javax.lang.model and javax.annotation.processing. I imagine that the Sun JAX-WS processors in Java 6 are based on the new interface? I have not verified that, but that's certainly what they should have done. I don't know, because we've only been looking at J2SE, which does not contain any of those processors. Eclipse 3.2 does not, and will not, support the new interface. However, we are working on supporting it in Eclipse 3.3.
(In reply to comment #3) > In Java 6, annotation processing is done by javac itself. Apt.exe is only for > Java 5 annotation processing, that is, processors that use the (deprecated as > of Java 6) com.sun.mirror interface. Java 6 processors use the standard > interface that was introduced via JSR269, in javax.lang.model and > javax.annotation.processing. It is optional: http://java.sun.com/javase/6/docs/technotes/guides/javac/index.html I tried just javac and it didn't work. I have to pass a -proc:only parameter but on this case I have to explicitly specify to annotation processors. If can run apt, it compiles and process the annotations, finding the JAX-WS processors automatically. > I imagine that the Sun JAX-WS processors in Java 6 are based on the new > interface? I have not verified that, but that's certainly what they should > have done. I don't know, because we've only been looking at J2SE, which does > not contain any of those processors. I don't know. I suppose it doesn't, because I can manually associate the tools.jar from JDK 6 as a annotation processor and JDT APT recognizes the JAX-WS processor. Am I right? > Eclipse 3.2 does not, and will not, support the new interface. Just a question: supposing my above comment is correct, isn't just a matter of automatically recognize the JDK's tools.jar (and other jars, if any) as a annotation processor factories? > However, we are > working on supporting it in Eclipse 3.3. > OK, since this is a new feature that requires some work. But I highly vote to have it on 3.3 because on future there can be other annotation processor based APIs incorporated on JDK.
(In reply to comment #4) > It is optional: > > http://java.sun.com/javase/6/docs/technotes/guides/javac/index.html Java 6's javac searches for, and runs, JSR269-style annotation processors, by default (ie with nothing special on the command line). This is required by the spec; see the description of javax.annotation.processing.Processor as a starting point into the new interface. > I tried just javac and it didn't work. I have to pass a -proc:only parameter > but on this case I have to explicitly specify to annotation processors. Correct, Java 6 javac will not directly run Java 5 processors. For that you'd have to use apt. The reason there's a -proc:only and a -proc:none is because the default for javac is to both process annotations (at least, for Java 6 annotation processors) and to compile. > I can manually associate the > tools.jar from JDK 6 as a annotation processor and JDT APT recognizes the > JAX-WS processor. I just took a look at the Java 6 tools.jar, and you're right, there are Java 5-style processors defined. You can tell by looking at the META-INF/services directory; processors are declared by creating a file named "com.sun.mirror.apt.AnnotationProcessorFactory" (for Java 5 processors) or "javax.lang.annotation.processing.Processor" (for Java 6 processors). So yes, these Java 5 processors can be loaded by apt, but not by javac, and they can be loaded by Eclipse 3.2 if you explicitly add them to the factory path. > OK, since this is a new feature that requires some work. But I highly vote to > have it on 3.3 because on future there can be other annotation processor based > APIs incorporated on JDK. Essentially what you're asking for is to emulate apt's behavior of falling back to discover Java 5 processors on the compile classpath, if the factory path is not specified. To be frank with you, I'm very doubtful that we would spend time on this, although we *might* consider including it if you or someone in the community submitted it as a patch. One reason is that supporting the Java 6 standard is a much higher priority for us than supporting newly added Sun-proprietary processors on the Sun-proprietary Java 5 interface. In fact I'm a bit upset at Sun for adding new Java 5 processors in their Java 6 product; it belies their statement that developers should be switching to Java 6 processors. But more importantly: the Eclipse IDE doesn't always have a JDK at hand. A JRE, yes, but not a JDK. Therefore it doesn't have tools.jar, and Sun has not made tools.jar redistributable. So, tools.jar is not on the compile classpath by default in Eclipse; if you want to compile against classes in it you have to explicitly add it to the classpath. In fact I don't believe tools.jar is on javac's boot classpath either; it is rather interesting that they put it on apt's boot classpath. A final reason is that because it is possible to add annotation processors with plug-ins in Eclipse, and these interact with processors discovered in manually added jar files, adding the ability to auto-discover processors on the classpath means we'd have to rethink our config API and UI; since there are customers relying on those, any changes have to be backward-compatible, which makes it less simple. I hope that, if Sun adds processors to the JDK in the future, they would add Java 6 processors, which we will be better able to support. In Eclipse 3.3 we will certainly be implementing fallback to the compile classpath for Java 6 processor discovery if no processor path is specified (though, that still won't find processors in tools.jar, just as it would not in javac).
