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.

Bug 113518 - NPE from Attr.visitMethodDef
Summary: NPE from Attr.visitMethodDef
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Dusan Balek
: 114789 115045 119432 129134 (view as bug list)
Depends on:
Reported: 2007-08-22 16:01 UTC by Jesse Glick
Modified: 2008-03-04 14:00 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Exception thrown immediately after, when trying CC on "f.sets" (2.63 KB, text/plain)
2007-08-22 16:03 UTC, Jesse Glick
Dump file (2.50 KB, text/plain)
2007-08-22 16:08 UTC, Jesse Glick
Log file excerpt (2.74 KB, text/plain)
2007-08-23 15:58 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2007-08-22 16:01:54 UTC
070821 (but observed occasionally for some time now), JDK 6, new j2seproject. Sometimes when I accept the import hint,
e.g. as here:

public class X {
    public static void main(String[] args) throws Exception {
        JFrame f = new JFrame();

nothing happens. The combined error-and-lightbulb glyph in the gutter flashes momentarily and reappears, and that is all.

C-S-I displays "Imports fixed" in the status line and also does nothing.

I doubt this is trivially reproducible; usually the imports hint works fine. I don't know what circumstances cause it to
do nothing. Presumably you can put in some kind of logging to figure out why an action which is supposed to make a
source edit in fact does nothing.
Comment 1 Jesse Glick 2007-08-22 16:03:59 UTC
Created attachment 47073 [details]
Exception thrown immediately after, when trying CC on "f.sets"
Comment 2 Jesse Glick 2007-08-22 16:08:15 UTC
After a restart, still does not work. After a restart with a deleted var/cache/, still does not work, and still get NPE.
Comment 3 Jesse Glick 2007-08-22 16:08:44 UTC
Created attachment 47077 [details]
Dump file
Comment 4 Jesse Glick 2007-08-22 16:14:37 UTC
Seems it is not so random after all. In a fresh userdir, I cannot reproduce the nonfunctioning of the hint, though not
the subsequent NPE. Also forgot to mention: in my own userdir, when trying CC for setSize, it shows the params as "arg1,
arg2" though I have in my JDK. In the fresh userdir, they are shown correctly as "width, height".

BTW with the new exception reporter, it would be a better idea for java/source to include all the dump information in
the actual detail message of the stack trace, so you could just click Report Problem and have everything of interest
sent. I also do not want my log dir filling up with *.dump files (currently I have dozens of them and there is nothing
to rotate them).
Comment 5 Jan Lahoda 2007-08-22 19:36:56 UTC
The problem with fix imports seems like a possible duplicate of issue #111976 (unless you actually saw it on a top-level
class, which I have never seen myself). The exception is likely to be a different problem. What JDK are you exactly
using (output from java -version would be helpful). Thanks.
Comment 6 Jesse Glick 2007-08-22 19:41:16 UTC
JDK 6u2, and this was on a top-level class.
Comment 7 Jan Lahoda 2007-08-22 20:24:39 UTC
Aha, I can reproduce the non-functioning hint for toplevel class - it happens to me if there is neither package clause
nor  import section in the file. Presumably some bug in the codegen.

The exception is more interesting, as it may be connected to our recent upgrade of javac - unfortunately I was not able
to reproduce it so far.
Comment 8 Jan Lahoda 2007-08-23 08:04:12 UTC
For the non-working import please see issue #113356. 
Comment 9 Jesse Glick 2007-08-23 15:57:45 UTC
Right, changing summary of this therefore.

I think I may have found something. I normally run on JDK 7 but have been forced to go back to JDK 6 for a while due to
critical AWT bugs. However I still have JDK 7 sources associated with my default platform. I can reproduce this bug in
my current userdir.
Comment 10 Jesse Glick 2007-08-23 15:58:31 UTC
Created attachment 47182 [details]
Log file excerpt
Comment 11 Jan Lahoda 2007-08-24 14:26:18 UTC
Yes, I can reproduce too, with rt.jar from JDK1.6 and from JDK1.7. When the sources do not match the binaries,
we may not be able to make it work 100% (parameter names, etc.), but we should not throw the exception, I think. Dusan,
could you please take a look.

My JDK versions:
java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
Java HotSpot(TM) Server VM (build 1.6.0_02-b05, mixed mode)

java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b18)
Java HotSpot(TM) Server VM (build 1.7.0-ea-b18, mixed mode)

1. Start the IDE with a clean userdir on JDK1.6
2. In Tools/Java Platforms change the associated sources to JDK1.7
3. In this source:
package javaapplication6;

import javax.swing.JFrame;

public class Main {

    public static void main(String[] args) {
        JFrame f = new JFrame();


call CC at the place marked with '|'.
Comment 12 Jan Lahoda 2007-09-10 12:34:56 UTC

*** This issue has been marked as a duplicate of 114789 ***
Comment 13 Jan Lahoda 2007-09-10 12:36:16 UTC
Comment 14 Jan Lahoda 2007-09-10 12:36:46 UTC
*** Issue 114789 has been marked as a duplicate of this issue. ***
Comment 15 Jan Lahoda 2007-09-10 12:37:01 UTC
*** Issue 115045 has been marked as a duplicate of this issue. ***
Comment 16 tfrysinger 2007-09-15 20:09:59 UTC
I was most recently able to reliably get this error with the daily from September 14, 2007 when I did the following:

Opened a smaller project that had the latest JDK 5.0 for OSX defined as the JDK for the project via Tools | Java
Platforms. In this platform definition, I have the location of the JDK source also defined.

In one source file, I created a new inner class, which extends JDialog. 

I wanted to double-check some implementation specifics of JDialog, so I highlighted 'JDialog' in this line:

  class ImportErrorDialog extends JDialog 

Did a right-click, chose Navigate | Go To Source.

When the JDialog source file was opened - bang. I got the error.
Comment 17 tfrysinger 2007-09-15 20:14:51 UTC
I just tried this again from scratch, and got a slightly different error. In this case, when I opened up NB 6, the
JDialog .java source file was already open from the last time, but not the selected tab (the source file with the inner
class that extends JDialog was the default open tab).

I closed the JDialog tab.

I again double-clicked on the 'JDialog' token on this line:

  class ImportErrorDialog extends JDialog

Right-clicked on chose the menu option Navigate | Go To Source

This time I got:

	at org.netbeans.modules.swingapp.AppFrameworkSupport.getApplicationClassName(
	at org.netbeans.modules.swingapp.AppFrameworkSupport.isFrameworkEnabledProject(
	at org.netbeans.modules.swingapp.ActionManager.getActionManager(
	at java.util.concurrent.Executors$
	at java.util.concurrent.FutureTask$Sync.innerRun(
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
	at java.util.concurrent.ThreadPoolExecutor$
[catch] at

This is on Mac OSX, latest patches applied to OS, on latest JDK 5.0 for that platform.
Comment 18 Dusan Balek 2007-10-22 10:09:33 UTC
*** Issue 119432 has been marked as a duplicate of this issue. ***
Comment 19 Jan Lahoda 2007-10-29 13:29:54 UTC
The last exception by tfrysinger is probably a different issue (in AppFrameworkSupport.getApplicationClassName), please
report if separately.
Comment 20 Dusan Balek 2008-02-07 12:47:21 UTC
Fixed together with issue #102857.
Comment 21 Jan Lahoda 2008-03-04 14:00:30 UTC
*** Issue 129134 has been marked as a duplicate of this issue. ***