This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Sorry if this is a wrong component. I created a Java Application and used Entity From DB wizard to generate some entities (eg. Customer from default sample DB). It results besides other things in addition of EclipseLink jars to project classpath. Now if I use Code Completion I'm offered Customer_ class which is generated if EclipseLink annotation processor is run, but because source level is 1.5 annotation processor is not executed and Customer_ is not generated and therefore I would think that code completion should not include Customer_ neither. What do you think?
Right David, The component is wrong. :-) The problem is following. The JDK 1.5 supports only implicit APs, JDK 1.6 supports implicit and explicit. The APQI (IDE) does exactly this. The problem is that the build script does not do it as it's not trivial to do it in Ant.
Disabling the annotation processing for sl 1.5 is another possible but wrong solution.
All I'm after is consistency between content of code completion and compilation - code completion should not offer something what build script is not going to compile.
Which I agree with, but. >code completion should not offer something what build script is not going to compile I disagree that NB's build-impl.xml should override compiler behavior, even it's strange. Suppose you have project over existing sources used both by NB and Eclipse users. If each IDE does something other then the compiler does the interoperability will be impossible.
(In reply to comment #4) > I disagree that NB's build-impl.xml should override compiler behavior Neither. I would leave build-impl.xml as is and run javac task as is - that is in its default form. It is IDE code completion which needs to be changed. It offers something what's not produced by javac.
We probably don't understand each other. So let me reformulate my previous post, maybe it's misleading. There is no special code in the code completion showing these classes. It just shows types after scan, save, editor modification, etc. The scan just runs the javac with options provided by the project. The difference among the output of the ant build and internal javac comes from the fact that the internal compiler supports implicit processors on JDK 1.5 (the JDK 1.5 supports implicit processors - those which are registered in the META-INF/services but has no options to pass explicit processors) but the build-impl.xml does not support it as it's ugly ant code. There are two possible solutions 1st) Fix the build-impl.xml to support it - non trivial. 2nd) Disable even the implicit APs for JDK 1.5 but this will cause the problems with project shared with different IDE as described in previous post.
I do not think complete consistency between the internal model and the ant build is reasonably possible. The problem is that pre-JDK 6 javac does not have any annotation processor related command line options, so the ant build script cannot pass any of them to it. The JDK 6+ javac has the command line options and can run APs regardless of the source level (at least AFAIK). It is however very difficult to detect the javac version inside the build script (esp. with non-default Java platform). So the current build scripts (at least J2SE project's build script) do not pass any AP-related options for source levels < 1.6. Consequently, if the project is being built with JDK 6 but source level = 1.5, the "implicit"(*) APs are still run (because that is the default behavior of the javac). If we wanted to emulate the same behavior inside the IDE, we would need to check the actual JDK implementation selected for the project and rebuild all caches for the project if the implementation changes, which seems like too much trouble for little gain (I would expect that most people that care about AP run on JDK 6+ and have implicit APs). What I think we could try to do is: -change the AnnotationProcessingQueryImpl to disable running of explicit APs when source level < 1.6 -add some texts to the project properties dialog to lead the user to source level >= 1.6 if explicit APs or processor path is needed (*) APs registered in the META-INF/services and located on the compile classpath passed to the compiler.
Thanks for the explanation. I had thought I'm missing something and now it is much clearer. I agree that it is not worth to fix it - it is problem only for 1.5 source level or JDK 1.5 and they will eventually disappear. And not many people use annotation processors anyway. Would it make sense actually to set new projects source level to 6 by default? That would further minimize that users bump into this issue.
Tomas, how it will work if I will try to compile sources with javac from command line with all jars (including one with META-INF/services) on classpath with two options source JDK5 or source level 1.5 and JDK6? Will result be different from one created by nb ant projects, is it the issue you are talking about?
(In reply to comment #9) > Tomas, how it will work if I will try to compile sources with javac from > command line with all jars (including one with META-INF/services) on classpath > with two options source JDK5 or source level 1.5 and JDK6? Will result be > different from one created by nb ant projects, is it the issue you are talking > about? I will try to answer that just to test my understanding: No. Running javac from command line and nb ant is the same. Run nb ant in verbose mode and you will see that standard javac is called with bunch of parameters. What is different is *internal javac* (whatever that is) used to parse Java files in the IDE. And from what Tomas said it sounds like the same internal javac is used also by other tools like eg. Eclipse. How this internal javac differs from command line javac in JDK 1.5 is that it processes implicit APs by default. So let say you have project for JDK1.5 and source level 1.5 with JPA2 entities and EclipseLink with implicitly registered AP. If you build it from NB or from command line you will never get Java classes generated by EclipseLink AP - there is no command line parameters for it in javac. I guess you would have to run some other JDK tool to get that, like apt. BUT internal javac *if* executed without any parameters will by default execute EclipseLink AP because it is implicit AP and therefore code completion will show auto generated classes like "Customer_". What I was arguing is that in this case internal javac should be told not to process implicit APs. The problem is that we do not currently store in project information about version of javac which will be used to compile project. All we have is project source level, but it can be JDK6 or JDK1.5 compiler. If we knew version of javac we would still have two problems: #1) according to Honza sources would have to be reparsed if version changes; and #2) according to Tomas we would fail to compile code which passed in Eclipse IDE. Re. 1 - I agree that gain would be minimal; on the other hand I would not expect user to change versions often so project would be most likely parsed just once in JDK version user chosen. Re. 2 - even if we keep the internal javac parsing the same as in Eclipse the project compilation via Ant (or command line) will fail. I do not care that much about JDK 1.5 anymore and in 6 with source level 6 it should be OK. Did I get it right or ... ? :-)
To Sergey: The result will be the same from cmd line and NB.
The internal javac is a bit enhanced JDK 7.0 javac and it runs the implicit APs for source level 1.5. This is the difference among compiler > 1.5 and 1.5 compiler. It's not IDE specific. >#1) according to Honza sources would have to be reparsed if version changes; and Same as if you change source level in project >#2) according to Tomas we would fail to compile code which passed in Eclipse IDE. Or on any other compiler newer then 1.5 even with -source 1.5 >I do not care that much about JDK 1.5 anymore and in 6 with source level 6 it should be OK. Right. For JDK 6 it's OK. Maybe project customizer should show warning when cp contains jar with AP and source level == 1.5
What's your opinion on this Tomas: > Would it make sense actually to set new projects source level to 6 by default?
As JDK 6 is now mainstream I agree. Originally we didn't do it because of shareability (sharing project with someone with JDK 5). Also JDK 6 does not bring any language features (except of change in APs) so there was no reason for it. As far as I remember originally we set target to 1.6 to benefit from a new preverifier, but we have to give it up as people complained about shareability. But now it should not be problem (or at least not as big) because most of users are using JDK 6 http://statistics.netbeans.org/analytics/graph/osandjvm.jsp The JDK 5 is something about 7%. The Mac OS X 10.5 has JDK 5 as default but JDK 6 can be installed.
If you think that we should do it please let me know, we should be consistent in j2se and j2ee. Thanks
+1, make JDK 6 the default.
If David also agrees I will switch the default for J2SE project tomorrow.
(In reply to comment #15) > If you think that we should do it please let me know filed as issue 194283. thanks.
No more valid. Supported source level start with 1.6