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 134805 - Wrong error badge
Summary: Wrong error badge
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on: 170544
Blocks: 121950
  Show dependency tree
 
Reported: 2008-05-10 15:59 UTC by katox
Modified: 2009-09-04 03:55 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
FileSystem patch (13.69 KB, patch)
2009-08-13 12:56 UTC, Tomas Zezula
Details | Diff
Parsing API diff (16.80 KB, patch)
2009-08-13 14:31 UTC, Tomas Zezula
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description katox 2008-05-10 15:59:35 UTC
Steps to reproduce:

1) New project - SE project with javaapplication1 package and Main.java class
2) New class - NewClass.java
3) Add a new method to NewClass.java, for example 
   public void hello() { } 
4) add a reference to Main.main(),
   public static void main(String[] args) { new NewClass().hello();}
5) cleanbuild ok
6) Create a new package - badpackage
7) Move (without refactoring) class NewClass to badpackage.

The IDE at first shows error in NewClass.java (correct). After a second the error disappears and the Project view looks
as if there is no error (incorrect!). The NewClass package declaration has a red exclamation bulb mark with hint
incorrect package at the same time (correct).

8) IDE Cleanbuild cleans and builds the project with no error! This is the structure in the build directory:
.
./classes
./classes/badpackage
./classes/javaapplication1
./classes/javaapplication1/Main.class
./classes/javaapplication1/NewClass.class

I consider this a very serious bug - which is also very hard to find a in large project since the errorneous file could
be everywhere. This issue might be linked with 98446. 

Note: The build system in 6.1 is horribly broken - to the point when it is not usable at all! Whole packages are
vahishing from the Project view - the IDE is aware of their presence though, since the sources are compilable (and you
can't re-add them, you get an error that the package is already there). Usually it can be fixed by closing and reopening
the project or by removing .netbeans/6.1/var/cache structure. Also hint marks showing whether the project/file is
compilable or not are somewhat random - nongenerated, regular source files marked with red exclamation mark are often
compilable and source files with no sign are not. Sometimes just by opening a marked source file in IDE java editor
helps to fix this.
Comment 1 Peter Pis 2008-05-14 17:03:56 UTC
Reassigning to "java" for evaluation.
Comment 2 Jiri Prox 2008-05-15 10:01:02 UTC
It's ok that the project is compilable, the location of source file and package needn't to match.

The error annotation you can see in NewClass is hint, configured to be displayed as an error. This default configuration
was chosen, since it's very uncommon to have the source folder not matching the package and it's is in most cases
unintended.

Can you, please, provide more info about vanishing sources and the cases of wrong error badges or wrong error annotations?
Comment 3 katox 2008-05-18 18:44:23 UTC
It is okay that it is compilable (in terms that java does not require matching directory structure) - but why is the
file moved elsewhere during the build? If the structure of java sources was preserved during the build the classloader
would throw ClassNotFound error on rutime. Building a new structure based on package names completely hides this error.
Comment 4 katox 2008-05-18 19:07:35 UTC
Missing directories -- follow the steps from the original post. One or more times. Delete the project by
right-click/delete on the project name in Project view

1) create new project JavaApplication by the wizard
2) open Main.java file editor
3) create a NewClass file by wizard - the file is opened for editing
4) add the method to NewClass
5) save NewClass
6) switch to Main.Java editor
7) replace the // TODO ... with the function call
8) save and build
9) create a new package badpackage // here the package is not created in the Projects view
10) try to recreate the same package // the IDE reports an error that the package is there
                                     // which is true as you can verify via xterm outside IDE
11) create NewClass1 in badpackage via wizard (badpackage is listed as an option there)
    // still hidden in IDE
12) open NewClass1 and right-click select in Project
    // the IDE either shows the file in mysteriously found dir or asks whether to open JavaApplication project
    // if you answer YES a new project with the same name with no sources is shown 
  

The bug itself is a but non-deterministic it may be neccessary to repeat the whole project creation / deletion cycle
more than twice. Also if you make the project with shared libs it is not deleted (even if you say to delete including
sources) and you would have to delete some parts manually (already reported as bug elsewhere)

This is the simplest possible way how I managed to reproduce the defective behaviour. It seems to be cache/refresh
related. As there is no manual refresh accessible from IDE UI it is needed to go to .netbeans/6.1/var and remove the
cache completely.
  
Comment 5 katox 2008-05-18 19:28:19 UTC
Ad annotations. Try this:
1) Create JavaApplication by wizard
2) Open Main.java for editing
3) Create NewClass by wizard, it opens for editing automatically
4) add method void hello() {} to NewClass, save file
5) switch to Main.java editor
6) replace // TODO ... comment with 'new NewClass().hello();'
7) save Main.java
   // the project should clear, not compiled
8) build
   // the annotation disappears on uncompiled files
   // so far ok
9) rightclick on Source Packages and create package badpackage by wizard
10) drag and drop NewClass on badpackage -- check move without refactoring to ON
11) now the error red exclamation mark is show on Main.java, javaapplication, JavaApplication
   // why error? should be some sort of warning instead
12) switch to NewClass editor 
   // the error annotation disappars completely from Project View - the project is shown as clean
   // the error (not warning) is shown on package declaration, the file is compilable though
13) build
   // build is okay, no warning is written to console
   // the annotation "uncompiled" is still present on NewClass.java in the tab above sources and in the Project view


14) close both editor windows
15) open NewClass.java in editor
16) click on bulb at the package declaration and change the package to badpackage
17) save
   //  the error annotation is shown immediately on Main, javaapplication, Source Packages, JavaApplication
17) hit ctrl-z to undo, the package is changed back to javaapplication
18) save
   // the error annotation on Main, javaapplication, SourcePackages, JavaApplication is still there
19) build
   // successful build, no error
   // the error annotation still there
20) clean-build 
   // the same
21) close editor on NewClass
22) open Main.java editor, write whitespace somewhere
24) save
   // the error annotation disappear

This is pretty inconsistent and unhelpful.
Comment 6 Jiri Prox 2008-05-21 14:11:45 UTC
The placing .class files to folders matching the package name is matter of java compiler/classloader. Just because the
default classloade is implemented in that way.

I can reproduce the error badge problem, I guess it's another variant of class-living-else. The IDE cannot find the
class sources in expected position. The file cannot be parsed until it's opened manually in editor.

To the problem in desc5: can you please file a separate issue for it, it's probably another issue. I've tried it several
times but with no success. How often does it happen? (e.g almost eveytime, 50%, or just sometimes). Are there any
relation between the project location you wanted to create class in and position where was the class really created?
Comment 7 katox 2008-05-25 11:11:05 UTC
Files in src/web folder should preserve their structure. A developer can have a custom classloader expecting classes and
resources to be structured as in sources. I see no reason why the IDE should move them around - it will only make the
custom classloader to fail unexpectedly (and make the default classloader to find the misplaced classes as if everything
was ok). javac itself doesn't need this extra step made by IDE.

Comment 8 katox 2008-05-25 11:23:31 UTC
Ad desc5: I tried the problem from desc5 on several machines with various degree of success. I have been able to
reproduce it on some machines (with rate from 80-100%) but not on others (0%). I'm not sure what is the exact cause but
it seems that to be (netbeans) cache related.

I noticed that if the project is managed by external hg or git repository the cache corruption occurs very often. I
suspect that switching branches causes netbeans to mess up the cache. Possibly the refresh is not sufficient. Once the
cache is corrupted it results into various kind of defects including the desc5. This is however just a speculation I
haven't been able to find a clear failing testcase.
Comment 9 Jiri Prox 2008-05-27 07:13:54 UTC
I don't know if we're talking about the same thing, I've meant moving files when they are compiled, e.g. when class A,
located in ${source_root}/bar directory but declared to be in package 'foo' is compiled to ${compile_directory}/foo/A.class
This is standard java behavior and IDE does not influence it at all.

Comment 10 katox 2008-05-28 15:19:19 UTC
I see, you refer to javac -d option. The behaviour is indeed written in docs. It differs from jbuilder/eclipse output
(or manual copying the classes after compilation (without -d)) so I got confused. My fault, sorry.

So the problem narrowed to wrong annotation and "hiding packages" problem. For the first one there is a testcase in here
(maybe the issue should be renamed). 

The "hiding packages problem" in the project view is something different but I the failing scenario is still to be found
on a small testcase.
Comment 11 Jiri Prox 2008-05-29 08:36:16 UTC
ok, let's narrow the issue to the remaining problem - the wrong error badge.
For the second problem - missing node in project view - I've filed separate issue and put you on CC
Comment 12 Jan Becicka 2008-06-06 10:16:04 UTC
Should be fixed for 6.5
Comment 13 Jan Becicka 2008-06-09 08:23:50 UTC
There is no need to have 3 P2 for Error Badges. 2 P2s is enough :)
Comment 14 Rastislav Komara 2009-02-03 10:52:59 UTC
Overtake.
Comment 15 Dusan Balek 2009-08-05 16:14:00 UTC
Better support for classes living elsewhere pushed to jet-main.

http://hg.netbeans.org/jet-main/rev/728701612fea

changeset 1258f9686efd in main/nb-javac
details: http://hg.netbeans.org/main/nb-javac?cmd=changeset;node=1258f9686efd
Comment 16 Quality Engineering 2009-08-06 06:00:25 UTC
Integrated into 'main-golden', will be available in build *200908060201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/728701612fea
User: Dusan Balek <dbalek@netbeans.org>
Log: Better support for classes living elsewhere (see issue #134805).
Comment 17 Tomas Zezula 2009-08-13 12:54:56 UTC
To work properly the RU needs to order the events (move = Delete + Create not Create + Delete).
This require that RU is notified about an end of fs atomic action.
Jarda has provided following path.
Comment 18 Tomas Zezula 2009-08-13 12:56:11 UTC
Created attachment 86193 [details]
FileSystem patch
Comment 19 Tomas Zezula 2009-08-13 12:58:12 UTC
I've prototyped an event ordering in the RU using Jarda's patch.
It seems that it works fine, the only problem is with rename of files (but it's our problem not problem in the patch).
I will attach a parsing api diff later today.
Jardo, can you fill an API review for provided fs patch?
Comment 20 Tomas Zezula 2009-08-13 14:31:19 UTC
Created attachment 86198 [details]
Parsing API diff
Comment 21 Tomas Zezula 2009-08-13 14:32:12 UTC
Added patch for parsing API.
Comment 22 Tomas Zezula 2009-09-02 15:38:00 UTC
Fixed in jet-main: 8fb645ed461b
Comment 23 Quality Engineering 2009-09-04 03:55:25 UTC
Integrated into 'main-golden', will be available in build *200909032054* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/8fb645ed461b
User: Tomas Zezula <tzezula@netbeans.org>
Log: #134805:Wrong error badge