Yes, corrupted class file bugs (Absent Code attribute, Duplicate method name etc.) was the one major problem for me going from NetBeans 8.2 to 9.0.
> I'd try to make a fix, but this is one of those bugs that involves an > interaction between several far-flung components (maven project plugin, > java.source.nbjavac OnePassCompileWorker, nb-javac, possibly java.source.base > CacheClassPath), and I really don't know enough about the architecture of > compilation to even say which one is at fault. A fix would be really lovely. There's a related patch at https://github.com/apache/incubator-netbeans/pull/504 ; if I understand correctly, that one does not solve the underlying problem, but rather makes NetBeans handle class file corruption bugs more gracefully. That patch might touch some of the same source files, so it might be useful to look at that patch and the associated discussion, as a starting point. -- Eirik -----Original Message----- From: Jeffrey Morlan <[email protected]> Sent: Wednesday, November 21, 2018 7:18 PM To: [email protected] Subject: NetBeans 9+ frequently corrupting target .class files in large Maven projects Hi, There's a bug in NetBeans 9 and 10 that I think deserves some attention: https://issues.apache.org/jira/browse/NETBEANS-531 Between 8.2 and 9, the Maven project plugin changed such that the compilation classpath now includes the current project's own compiled classes. With the "SuperOnePassCompileWorker" strategy used when compiling small numbers of files, this doesn't seem to cause any problems, but with the "OnePassCompileWorker" strategy used when compiling 500+ files, the inclusion of previous compilations on the classpath can pollute the resulting class files with bogus members. The usual symptom is a "Duplicate method name" ClassFormatError, from a lambda or other synthetic method, but I've also seen "Absent Code attribute" from a code-less static initializer method (unclear where it came from; the class in question is typically an interface that doesn't have any static initializers) So whenever 500 or more files are compiled, usually because of a pom.xml change, the target/classes/ directory is effectively corrupted and the project needs a manual Maven clean+rebuild. This is the main issue that keeps us stuck with NetBeans 8.2. I'd try to make a fix, but this is one of those bugs that involves an interaction between several far-flung components (maven project plugin, java.source.nbjavac OnePassCompileWorker, nb-javac, possibly java.source.base CacheClassPath), and I really don't know enough about the architecture of compilation to even say which one is at fault. Anyone know what the proper approach to fixing this would be? Thanks, Jeffrey
