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 12440 - In a multistage compiler, ExternalCompiler proceeds before the previous stage is finished.
Summary: In a multistage compiler, ExternalCompiler proceeds before the previous stage...
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: anovak
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-05-25 21:44 UTC by richard.everhart
Modified: 2008-12-22 18:44 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Zip containing test module, short readme and other files. (25.15 KB, application/octet-stream)
2001-07-20 20:30 UTC, richard.everhart 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description richard.everhart 2001-05-25 21:44:27 UTC 
Suppose that the first stage of a multistage compiler takes some file, A, and
turns it into file B.  The second stage is responsible for taking file B and
compiling it into file C.  

The first stage compiler will compile file A, but the second stage will begin
compiling file B before the IDE recognizes that it exists.  The will cause an
NullPointerException to be thrown from ExternalCompilerGroup (listed below).  

If file A is compiled again the stage two compiler will succeed in compiling B
into C because file B will exist at this time.  Here is the stack trace from the
test module I wrote (it also happens from within my module):

Fri May 25 12:19:43 PDT 2001: java.lang.NullPointerException: null
java.lang.NullPointerException
        at
org.openide.compiler.ExternalCompilerGroup.getStatusLineText(ExternalCompilerGro
up.java:156)
        at
org.openide.compiler.CompilerExecutor$CERunnable.run(CompilerExecutor.java:147)
[catch] at
org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:118)

I've noticed this happening on Linux, kernel 2.2.14 and 2.4, and on Solaris 8,
running both FFJ 2.0 CE and NetBeans 3.2.
Comment 1 richard.everhart 2001-05-25 22:07:26 UTC 
Created attachment 1440 [details]
Zip containing test module, short readme and other files.
Comment 2 anovak 2001-08-21 17:32:06 UTC 
I have just fixed the exception, however, I have find two more
problems in the provided sources.

1) TestCompilerType.DEFAULT should contain a space between classpath
and files, e.g:
" {" + ExternalCompilerGroup.Format.TAG_FILES + '}'
^^ this is the place

2) StageOneCompilerGroup uses TestLib.generate, which in turn
generates a file (java.io.File). But NetBeans FileSystems
(LocalFileSystem) and actual disk content are not always in sync!!!

So you create a File, but NetBeans will know about that File about 10
or 15 s later, after a refresh. Now look at
ExternalCompilerGroup.start(). Each ExternalCompiler is asked to give
the name of the resource it represents. It is done through getFileName().

The getFileName method (in ExtCompiler) in turn invokes 
fileNameProducer.getFileName. fileNameProducer can be one of several
implementations, but in this case, when the resource of the
ExternalCompiler is a String, it is something like:

FileObject fo = fs.findResource (resourceName);
if (fo == null) {
  return ""; // NOI18N
}
File f = NbClassPath.toFile (fo);
if (f == null) {
  return ""; // NOI18N
}
return f.toString ()

Remember that fs is still likely out of sync, so findResource will
return null!!!
So I believe that it would be much better to either:
a) always use FileSystems for all IO operations
b) forcing a FileSystem to refresh after using a File
Comment 3 Quality Engineering 2003-07-01 15:45:43 UTC 
Resolved for 3.4.x or earlier, no new info since then -> verified.
Comment 4 Quality Engineering 2003-07-01 16:34:14 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.