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 50433 - java parsing progress dialog gets into neverending loop
Summary: java parsing progress dialog gets into neverending loop
Status: CLOSED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Martin Matula
URL:
Keywords:
: 50599 51405 (view as bug list)
Depends on: 50431
Blocks:
  Show dependency tree
 
Reported: 2004-10-14 15:44 UTC by David Konecny
Modified: 2007-09-26 09:14 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Konecny 2004-10-14 15:44:12 UTC
Try this on Windows:
* start IDE with clean userdir (I'm using Build
041014)
* create new JavaApp project
* add some jar to the project classpath which do
not lie under project directory
* shutdown IDE
* open nbproject/private/private.properties of the
project and there should be property pointing to
the jar. Change the drive letter to lowercase.
* restart IDE

After that I get parsing progress dialog which
finishes parsing and hides, appeares again, hides,
appeares again, hides, etc. The IDE is forever
unusable and I have to kill it.

Couple of things:
* this problem happens only when user customize
project by hand and use filename which is not
normalized (see FileUtil.normalizeFile for more
details) and threfore this is P2 although it is P1
because IDE is unusable
* the original cause of the problem is not in
Java, but in project which do not normalize files
before creating classpath. I filed it as issue
50431. But Java should be more robust and survive
this too. Perhaps it will help you to reveal some
other problem.
Comment 1 Martin Matula 2004-10-14 17:48:06 UTC
Making javacore more robust would introduce more complexity and
possibly more performance overhead. So given that this is caused by a
known bug in some other module, I would prefer if the bug can be fixed
rather than creating workarounds in javacore to handle possibility of
this kind of problems.
So I think this issue should be closed as soon as issue 50431 is resolved.
Comment 2 David Konecny 2004-10-15 09:09:45 UTC
It is up to you. To be honest, my opinion on this is:
* I do not care much what you do with this. I just wanted to help by
reporting easily reproducible problem.
* I do not believe you when you say fix would add "more complexity and
possibly more performance overhead"
* I believe there is a simple bug in your code to be fixed. And
possibly it will manifest itself again whenever somebody else will
pass you invalid input. So the result is like this: instead of telling
your client very early that he is passing your wrong input or at least
surviving invalid input gracefully everything will look OK from client
point of view but becasue of this "bug" in java/MDR they will blame you.
Comment 3 Martin Matula 2004-10-15 10:10:04 UTC
IMO the problem should be handled (reported to clients very early) by
ClassPath API, not by Java/MDR, since Java/MDR is just one of
potentially several clients that may break when the ClassPath API does
not return correct results. So as opposed to putting hacks and checks
into all the ClassPath API clients I would prefer if the issue could
be fixed/checked/reported at a single location.
What I dislike about this report is that it claims that a code that is
currect, but unprepared for some kind of bugs in some other code is a
P2 defect. There are zillions of situations where we could add checks
whether some API really does what it is supposed to do. Taking this
bug as a precedence, we potentially have zillions of P2 defects.
Anyway, I will see what I can do...
Comment 4 David Konecny 2004-10-15 15:37:01 UTC
"So as opposed to putting hacks and checks into all the ClassPath API
clients I would prefer if the issue could be fixed/checked/reported at
a single location." - sure, this is the rule to follow. But I do not
know where exactly is the problem. Tomas might know more. I would
expect that if classpath is created from URLs which cannot be
converted to FileObject (what is this case) the classpath will never
report valid FileObject root for such an URL. But you are using
directly URL your own way I guess (put aside that it is exactly what
classpath API already does for you). But I might be wrong, I do not
know the details.

"What I dislike about this report is that it claims that a code that
is currect, but unprepared for some kind of bugs in some other code is
a P2 defect." - I understand but it was your parser progress dialog
which got crazy and made my IDE suddenly totally unusable. Or I could
do is to kill it. That's why I think it deserve at least P2. It took
me some time to diagnose the problem. Originally I though it is
random, broken MDR caches, broken something else who knows what...
Comment 5 Martin Matula 2004-10-15 16:39:56 UTC
OK, I see a painless way how this could be fixed.
Comment 6 Martin Matula 2004-10-15 18:17:48 UTC
Fixed. Javacore should now display an error message indicating that an
invalid URL was returned from the classpath, and ignores the given
classpath root.

Checking in src/org/netbeans/modules/javacore/JMManager.java;
/cvs/java/javacore/src/org/netbeans/modules/javacore/JMManager.java,v
 <--  JMManager.java
new revision: 1.64; previous revision: 1.63
done
Comment 7 David Konecny 2004-10-18 14:09:04 UTC
Thanks. Way better.
Comment 8 Martin Matula 2004-10-19 15:09:20 UTC
*** Issue 50599 has been marked as a duplicate of this issue. ***
Comment 9 Martin Matula 2004-11-11 11:53:48 UTC
*** Issue 51405 has been marked as a duplicate of this issue. ***
Comment 10 Quality Engineering 2007-09-20 10:49:37 UTC
Reorganization of java component