Bug 141921

This seems to clear up if I uncheck the compile on save option and do a clean/build all.
Which begs the question, do we really need the compile on save option?
If so, then on check/uncheck there needs to be a build all since NB can have jars in various states of compilation.

Does it occur only while debugging the project? What about when you just run it. I would expect the same result.

Product Version: NetBeans IDE Dev (Build 200807290201)
Java: 1.6.0_10-rc; Java HotSpot(TM) Client VM 11.0-b14
System: Windows Vista version 6.0 running on x86; Cp1250; cs_CZ (nb)

Observed: With COS checked i can't start debugging via "step into" it is only functioning right after i invoked clean
and build - in all other cases the debugging session ends instantly and following the lines at the end of this post are
written in output.

Steps to reproduce: have some java application set as main project -> invoke debug main project -> end the debugging
session -> invoke step into -> see the output

init:
deps-jar:
compile:
java.lang.NoClassDefFoundError: examples/advanced/MemoryView
Caused by: java.lang.ClassNotFoundException: examples.advanced.MemoryView
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
Could not find the main class: examples.advanced.MemoryView.  Program will exit.
Exception in thread "main" 
Java Result: 1
debug-stepinto:
BUILD SUCCESSFUL (total time: 0 seconds)

Created attachment 65914 [details]
messages.log

The java.lang.NoClassDefFoundError: examples/advanced/MemoryView
Caused by: java.lang.ClassNotFoundException: examples.advanced.MemoryView also pops into output on run action.

Steps to reproduce: Have some java project as main project(with COS checked) -> invoke debug main project -> finish
debugging -> step into -> uncheck compile on save -> step into -> clear the output to see that it is written after
invocation of run -> run

Product Version: NetBeans IDE Dev (Build 200807290201)
Java: 1.6.0_10-rc; Java HotSpot(TM) Client VM 11.0-b14
System: Windows Vista version 6.0 running on x86; Cp1250; cs_CZ (nb)

Reassigning for evaluation.

Several separate problems described here:
1. the ClassFormatError: I am afraid we will need steps to reproduce this problem (e.g. source code which leads into the
corrupt .class file).
2. check/uncheck forcing clean build: it works this way for J2SE Project - if you uncheck the checkbox, "clean build"
will be forced on next build.
3. step into not working for CoS. Fixed by:
http://hg.netbeans.org/main?cmd=changeset;node=ea461be64d35
4. ClassNoFoundException in some specific scenarios: related to the "Track Java Dependencies" checkbox and the enforced
clean build. Fixed by:
http://hg.netbeans.org/main?cmd=changeset;node=5e809326fd1d

Integrated into 'main-golden', available in build *200808081401* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/5e809326fd1d
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #141921: Disabling includes="nothing whatsoever" when build/classes has been filled with NB autobuild.

I am also getting this with 6.5beta

Projects that were working perfectly with 6.5M1 and 6.1 now frequently give the message
   
    Exception in thread "main" java.lang.ClassFormatError: Absent Code attribute in method that is not native or
abstract in class file ***

Forcing a clean and build does NOT fix the issue. 
If I make a redundant change to the offending class' .java file (e.g. insert and remove a space) then that class is
fixed the next time a run or debug the project.. but usually there are several more classes that fail and I need to
'touch' them all one at a time until the run works.

I have no idea what triggers the problem as it only happens to some of the classes in the project and in some cases
there were no changes to the project at all - simply upgrading to 6.5beta and trying to run results in the errors.  It
is very odd that a clean and build does not fix this, yet touching the source file does.

I'm using JDK1.6.0_10rc-b28 on Win XP SP2

I am compiling with Java: 1.6.0_06; Java HotSpot(TM) 64-Bit Server VM 10.0-b22
with source compatibilty 1.4 turned on. (If that make a difference)

I´ve the same problem.
Yesterday I updated to 6.5 beta an now I can´t debug my project (java.lang.ClassFormatError: Absent Code attribute in
method that is not native or abstract in class file mysourcefile.java).
System:
NB 6.5 beta on WindowsXP
Java: 1.6.0_07
Cmpatibilty 1.4 turned on

After Turning off "Compile on save" it works fine.

Is it understood why CoS affects Clean and Build?  I can't see how it should.  I can confirm that the Clean and Build
only fixes the problem after disabling CoS

*** Issue 147755 has been marked as a duplicate of this issue. ***

Is this issue actively being worked on?  Why the INCOMPLETE keyword?  What information do you need?  I ask because this 
bug is preventing me from using CoS (in build 200810011401) and if you would like me to collect some data, I'm up for 
it.  (It appears to be 100% reproducible.)

Let me illustrate how I can reproduce this and how strange it is:

I turn OFF CoS
Do a clean and build
Hit debug 

- everything works -

turn on CoS

Hit debug WITHOUT touching a single source file.
I encounter the bug 

- not on the main class, some other small class that is loaded in a constructor for a larger object that is created by 
my main class.  It is always the same class that fails and I see no way that the failing class is special.

Why did the .class file change at all?  I just made sure all the classes were up-to-date.

I've encountered this problem as well (on Windows), also in 6.5 beta.

In my case though, I wasn't debugging my project.  I was just deploying a web project to Tomcat.  The class it's balking
on is not even in the same project, though.  It's a separate project that's been added as a compile-time library.  I've
tried every combination of "Compile on Save" (for the library) and "Deploy on Change" (for the web project), and I get
this exception every time I try to deploy.

I'm going to upgrade to one of the nightly builds and see if anything changes.

Output from:
javap -s -l -private
for the given bad class would be a good start. The source code that causes this problem might be useful too. Thanks.

Are you able to reproduce the ClassFormatError even with clear caches (var/cache/index subdirectory of your userdir)?

Clearing the cache seems to have fixed it! Thanks.

Fixed.

changeset f0c9e777d854 in main/nb-javac
details: http://hg.netbeans.org/main/nb-javac?cmd=changeset;node=f0c9e777d854
changeset cbcaea3d04bf in main
details: http://hg.netbeans.org/main?cmd=changeset;node=cbcaea3d04bf

Just curious... why a target milestone of 7.0 if it's part of [65cat]?

The code for 6.5 was frozen yesterday and branched from current trunk, so the fix will be included in next version -
7.0, we will consider adding this fix to patch1 for 6.5

Integrated into 'main-golden', will be available in build *200810141401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/cbcaea3d04bf
User: Dusan Balek <dbalek@netbeans.org>
Log: Issues #141921 and #144633 fixed.

I cannot reproduce the exception by following steps to reproduce -> v.

The fix has been ported into the release65_fixes repository.

http://hg.netbeans.org/release65_fixes/rev/d8f4f67b0efd

verified in patch1

Doesn´t work with NB6.5 Patch1.
Same Error!

Could you please provide specification version of org.netbeans.libs.javacimpl from your IDE log after the applied patch? Just please select menu View -> IDE 
Log, find the row with the text org.netbeans.libs.javacimpl and paste the row to this issue. Thank you.

org.netbeans.libs.javacimpl/1 [0.9.2.7 7 200812031904]

Yes, this is correct number from the patch. The problem is in the fix itself.

> Yes, this is correct number from the patch. The problem is in the fix itself.
Fine, but it doesn´t work.

Have you cleared your caches (var/cache/index subdirectory of your userdir) after installing the patch?

-) Now I´ve cleared my Cache-Dir.
-) Then I activated the "Compile on save" - Option
-) After that I´ve started a Debug-Session
-> Some Classes are destroyed, but not all.

Next Trial:
-) Clean and Build on the project
-) Then started a new Debug-Session
-> The same Class is destroyed

Trial 3:
-) Deactivate "Compile on Save"
-) Clean and Build on the project
-) Started a new Debug-Session
-> It works

Windows XP, Source-Code-Level 1.4
 

Could you please attach the destroyed class?

Created attachment 74862 [details]
The corrupt Class-File

Could you please attach also the messages.log? Thanks.

Created attachment 75001 [details]
Message-Log: Started the IDE; activated the "Compile on Save"; Started a Debug-Session; Closed the IDE

Could you please attach also the ClassFormatError that corresponds to the destroyed class file (I don't see any in the
messages.log)? Thanks.

Exception in thread "AWT-EventQueue-0" java.lang.ClassFormatError: Absent Code attribute in method that is not native or
abstract in class file Softline/StammTables/Debitor
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
...

It is a bit strange - according to the output from javap - there are two methods without the code attribute in the
attached Debitor.class file:

public java.lang.Integer getIdkommgruppe();
public java.lang.String getSscctrennung();

I expect that both are just simple getters of their corresponding fields (without any magic or errors in the source file)?

Is this situation reproducible on your sources? I mean, if you clean your project, destroy your caches, and run your
IDE, do you get the same error in the same class file?

> public java.lang.Integer getIdkommgruppe();
> public java.lang.String getSscctrennung();
>I expect that both are just simple getters of their corresponding fields 
> (without any magic or errors in the source file)?
This is really strange!
The Methods getIdkommgruppe, getSscctrennung are not in my locale Source-Code-Version.
This two Methods are only in the Server-Version (on classpath).

Maybe the Method-Compile works with classpath (But not on file level but on level methods) ?!?

> Is this situation reproducible on your sources? 
> I mean, if you clean your project, destroy your caches, and run your
> IDE, do you get the same error in the same class file?
Yes

Isn't there the Debitor.dump file in the /var/log subdirectory of your userdir containing some CouplingErrors?

No

> The Methods getIdkommgruppe, getSscctrennung are not in my locale Source-Code-Version.
> This two Methods are only in the Server-Version (on classpath).

Tell me more about your project classpath. Is Softline/StammTables/Debitor on the classpath twice? Why? Is it in a form
of source/class files? What is relation between them?

Also, is it possible to attach your project.properties file?

> Tell me more about your project classpath. 
> Is Softline/StammTables/Debitor on the classpath twice? 
Yes

> Why? 
> What is relation between them?
It´s ab big project and on the classpath are the cvs-checked-in files (with cruise control, unit tests, ...).
After the Cruise-Control has finished, the source and class-file are copied to server-directory and this directory is in
my project as Classpath-dir. 

> Is it in a form of source/class files?
What do you mean?

Created attachment 75027 [details]
Project - Properties - File

>> Is it in a form of source/class files?
> What do you mean?
I can imagine a situation that could lead to your problems:
Debitor.class (containing problematic methods) exists on your project classpath and it is newer (comparing timestamps)
than Debitor.java (that doesn't contain the methods).
Is it necessary to have the the server-directory on your project classpath (what happens if you remove it from the
classpath)? This duplication seems to be dangerous - if there is a inconsistency (like in this case) which version is
the correct one (which version you compile against)?

Well, ant is aware of timestamps, but the compiler itself isn't, right?

I don't think the duplication is dangerous.  The compiler will expect the class it's compiling to override the included
class...  That's my understanding, at least.

> Debitor.class (containing problematic methods) exists on your project classpath and it 
> is newer (comparing timestamps) than Debitor.java (that doesn't contain the methods).
This shout no be a problem, or?

>Is it necessary to have the the server-directory on your project classpath 
>(what happens if you remove it from the classpath)? 
I need the classes on Classpath (because I didn´t checkout the complete repository).

> This duplication seems to be dangerous - if there is a inconsistency 
> (like in this case) which version is the correct one (which version you compile against)?
Classpath-Order: Project-Files and then the server-side-files (read-only).

Unfortunately, it is a problem. When compiling a class that has some dependencies, javac tries to compile against
already compiled class files (if they are up-to-date i.e. they are newer than their sources). Now imagine the following
scenario:
There are two sources A.java and B.java (A uses B). Both sources exist as server-side-files and also as your local
copies. Now, someone else adds a method to the B.java on a server side and compiles whole server side (A.class and
B.class are created on a server side). Now you try to compile your local copies. Starting with A.java, javac by default
compiles it against server side B.class (A.java uses class B, B.class file exist and it is up-to-date - it is newer than
your local B.java). So locally created A.class can access the newly added method in B (it was compiled against
server-side B.class). Then your B.java is compiled. However, since your local B.java does not contain the newly added
method also the locally created B.class does not contain it. What happens if you try to locally run your A.class?

Anyway - to get rid of ClassFormatErrors, the CoS mechanism is modified to throw RuntimeExceptions when touching a 'non
existing' method instead.

changeset 4f5369ff501a in main/nb-javac
details: http://hg.netbeans.org/main/nb-javac?cmd=changeset;node=4f5369ff501a
changeset 8dab5355c3fa in main
details: http://hg.netbeans.org/main?cmd=changeset;node=8dab5355c3fa

>Starting with A.java, javac by default compiles it against server side B.class 
>(A.java uses class B, B.class file exist and it is up-to-date - it is newer than your local B.java)
Sorry, but I can´t believe it, because
1.) When I make a "Clean and Build" - Action, the CoS should work?
2.) Why the classpath-order is correct without CoS?

Could you please try my latest patch before reopening the issue? Thanks.

I'm curious to hear the answer to stefan79's question, dbalek.  His local B.class will have a more recent timestamp if
he's doing a clean build.  Can you explain what should happen in that situation?

Try it yourself (outside of IDE - from command line):

1) Create A.java:

package test;
public class A {
    public static void main(String... args) {
        B b = new B();
        b.test();
    }
}

and B.java:

package test;
public class B {
    public void test() {}
}

2) compile both files
3) remove method test() from your B.java
4) touch both class files created in step 2) to make them 'newer' than sources and move them to ServerSide.jar.

Now the setup is completed, so try 'incremental' compilation:

5a) run javac -classpath ServerSide.jar A.java. A.class is created without problem (even if B.java doesn't contain
test() method now).
6a) run javac -classpath ServerSide.jar B.java. B.class is created.
7a) Try to locally run your application (java test.A) - NoSuchMethodError is reported.

However, if you try to compile your application in a 'batch' mode:

5b) run javac -classpath ServerSide.jar A.java B.java - you get the compilation error (cannot find symbol: method op())
immediately.

That is the difference - while CoS mechanism is inherently 'incremental', without CoS, IDE uses ant to build the sources
which operates in the 'batch' mode.

> 5a) run javac -classpath ServerSide.jar A.java. A.class is created without problem (even if B.java doesn't contain
The order should be:
"javac -classpath MyUserDir/build/classes/;ServerSide.jar A.java

There are no classes yet in MyUserDir/build/classes/ before running javac in 5a). A.class is created in 5a) B.class in 6a)

This isn´t my case.

My Steps:
1) I make a clean on my project "Myuserdir"
2) Activate CoS
3) Then I start a Debug-Session. -> The Classes are compiled to build/classes.
Isn´t this an ant-build?

Timestamps:
Myuserdir/src/Debitor.java:            2008-12-16 10:48
Myuserdir/build/classes/Debitor.class: 2008-12-18 14:35
ServerDir/Debitor.class                2008-12-18 10:42

Why the Myuserdir/build/classes/Debitor.class has the Method "getIdkommgruppe"?
I don´t understand this!

Fine.

There are no classes in Myuserdir/build/classes/ after cleaning your project in step 1). So you have

Myuserdir/src/Debitor.java:            2008-12-16 10:48
ServerDir/Debitor.class                2008-12-18 10:42

Now, imagine that you compile some Other.java file that uses Debitor. What is the correct Debitor version that the
compiler should compile against (Debitor.class containing 'getIdkommgruppe()' or Debitor.java that does not contain it)?
Note that the class file is newer than the source file (thus compiler assumes it was created by compiling the source).
So compiler compiles your Other.java against Debitor.class. Then Debitor.java itself is compiled. Due to performance
reasons the same instance of javac is used to do so. Thus CoS mechanism knows that there was a method
'getIdkommgruppe()' (that could be used from Other.class) which is not in source. The CoS solution in this case is to
add the missing method into the class file and let it throw a RuntimeException everytime it is accessed. 

BTW; Have you tried my patch?

I tried latest Build 200812171401.
Is this the correct version (because I have the same error)?

Probably not - usually "Integrated into 'main-golden', available in build *????*" message appears in the issue when the
fix is available in the official build.

Integrated into 'main-golden', will be available in build *200812221122* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/8dab5355c3fa
User: Dusan Balek <dbalek@netbeans.org>
Log: Issue #141921: ClassFormatError while debugging a project (CoS) - fixed.

Looks good.

Thanks
Stefan