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.
This issue was reported manually by sdedic. It already has 1 duplicates Build: NetBeans IDE 7.1.1 (Build 201203012225) VM: Java HotSpot(TM) 64-Bit Server VM, 22.0-b10, Java(TM) SE Runtime Environment, 1.7.0_02-b13 OS: Windows 7 User Comments: GUEST: I have 3 Hashmaps HashMap<String, SummaryStatistics> ... which produce a compile error as they are later referred to as HashMap<String, s.th.else> Sure, this produces a compile error which is okay. But during refactoring, the IDE sometimes scans and pretty lags Stacktrace: java.lang.Exception: Scan canceled. at java.lang.Thread.getStackTrace(Thread.java:1567) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:74) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:67) at org.netbeans.modules.parsing.api.indexing.IndexingManager.addIndexingJob(IndexingManager.java:430) at org.netbeans.modules.parsing.api.indexing.IndexingManager.refreshIndex(IndexingManager.java:178) at org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.run(IncorrectErrorBadges.java:172)
Created attachment 117662 [details] stacktrace
Any reasons why it was filed for persistence? I see some exceptions in persistence, but not sure it's related. Slowdown may be caused by exceptions logging also, may it have sense to cut some part of ex ceptions from annotation processors? May be just message on INFO level and show full dump in FINE case?
Why to reassign ? The erroneous annotation processor is here (see logs at http://statistics.netbeans.org/exceptions/exception.do?id=569891): java.lang.RuntimeException: javax.annotation.processing.FilerException: Attempt to recreate a file for type de.intelliad.db.intellibo_login_temp.RawTrackingImpressions_ at org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor.process(eclipselink-2.3.0.jar:407) at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(javac-impl-nb-7.0-b07.jar:827) The proper fix is not to mask out errors from annotation processors, but to actually work around them or solve them. The performance penalty is paid at the time of exception throw, when Stacktrace[] elements are populated, not so much when logging such an exception. Also note that aborted compilation probably causes some processing to be restarted, so the exception is unwanted in the first place.
it's user configuration error then, annotation processor just do not support generation of entities from several pu in one place, but we shouldn't be affected so much by user errors, even if persistence wizards will add subpackage automatically user will be able to create pu manually or use persistence.xml from another projects etc and in this case ap will produce these traces. I suppose it may cause problems as logging to message.log may be time consuming and it's not "hidding" to log less especially as it';s not severe(I hope) for nb itself.
ok, miss logging may not cause much penalty, but it still impossible to have no fix all cases wich may cause ap to throw exceptions (on nb side)
Ok, as part fix, the best I see not is to show warning badge either on project level or on persistence.xml level if there are more then one pu and no usage of subpackage and annotation processing is turned on. Then it may be reassigned back to persistence area, feel free.
The reason is: at java.lang.Thread.getStackTrace(Thread.java:1567) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:74) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:67) at org.netbeans.modules.parsing.api.indexing.IndexingManager.addIndexingJob(IndexingManager.java:430) at org.netbeans.modules.parsing.api.indexing.IndexingManager.refreshIndex(IndexingManager.java:178) at org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.run(IncorrectErrorBadges.java:172) at org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.run(IncorrectErrorBadges.java:70) at org.netbeans.modules.java.source.JavaSourceAccessor$CancelableTaskWrapper.run(JavaSourceAccessor.java:324) The errors come from EL, the waring persistence.xml is good. I can even filter out the errors generated by AP (EL) from the check. Will it help to you? If so, I can do it, just reassign back to me (java/source/tzezula). Thanks
ok, will try first with warning implementation.
it's also a duplicate of issue 183779, and if compile on save produce this ouput, usual compilation should fail also. 183779 also mention subpackage automatic addition as a way to handle on nb side. *** This bug has been marked as a duplicate of bug 183779 ***