NetBeans 9+ frequently corrupting target .class files in large Maven projects

[Jeffrey Morlan <je...@everlaw.com>]

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

RE: NetBeans 9+ frequently corrupting target .class files in large Maven projects

[Eirik Bakke <eb...@ultorg.com>]

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 <je...@everlaw.com> 
Sent: Wednesday, November 21, 2018 7:18 PM
To: dev@netbeans.incubator.apache.org
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