The same happens when expanding myProject/Libraries node in Projects window.

Probably related to the fact that the project is having library references by "../mylib.jar". Note the the jar is not located there.

Increasing to P2 since it is reproducible on various machines and affects the exchanging of JavaFX projects with relatively located libraries between users.

This seems as an issue inside org.netbeans.api.java.classpath.ClassPath.getRoots() method. Firstly I obtain the compile classpath by "ClassPath.getClassPath(fo, ClassPath.COMPILE);" and then I call "getRoots()" method on the obtained classpath.
I am not sure if I am supposed to normalize the paths inside the obtained classpath or if it should be the responsibility of org.netbeans.api.java.classpath.ClassPath class.
Please, evaluate and dispatch accordingly.

The ClassPath just takes the URL it got from the SPI (PathResourceImpl) and converts them into FileObjects + Files to use by FU.addFileChangeListener(). It does not do normalization as it will be expensive (all instances of CP will do it, the SPI is responsible to do it - it does it just once).
Who provides the ClassPathImplementation? JavaFX project?

*** Bug 186362 has been marked as a duplicate of this bug. ***

After debugging, we have discovered that the issue is in FileUtil.normalizeFile method.

When being on Linux machine, calling:
FileUtil.normalizeFile (new File ("/home/dave/NetBeansProject/ABCD/", "../../../../../XYZ"))
will return File with path:
"/../XYZ"

This is actually called from:
FileUtil.resolveFile(new File ("/home/dave/NetBeansProject/ABCD/"), "../../../../../XYZ");

May be related to:
FileUtil.normalizeFileOnUnixAlike method.

What do you think shall be the return value of 

FileUtil.normalizeFile (new File ("/home/dave/NetBeansProject/ABCD/",
"../../../../../XYZ"))

? I have a feeling returning "/../XYZ" is the best what the method can do. Are not you, by a chance, calling the method with wrong arguments?

I am closing as invalid, as (from platform/filesystems perspective), it is not at all clear what is wrong or what shall be done.

If the FileUtil.normalizeFile() is OK then FileUtil.addFileChangeListener () should not throw the IllegalArgumentException when such a normalized file is passed to it.

But the "../../../../../XYZ" is invalid! How can you go five times up when the you are in four directory deep directory?

Based on comment #6, sounds like a bug in javafx code - creating a nonsensical file path.

Could you, please, provide a reproducible case how to create a project referencing a library to located out of the file system (5 levels up in a 4 level deep project path)?
If the project has been moved, don't you experience a broken reference?
Is this a P2 priority issue if you operate with a project with broken references and receive some exceptions?

Here are reproducible steps:
1) Have a JavaFX project created on a Windows machine in a directory:
c:\documents and setttings\myuser\my documents\netbeans\mysampleproject
2) On the same machine, you have some libraries that you want to include in your project. They are located at:
c:\program files\sun\javadb\lib\derby.jar
3) Use your library into your project
4) Pack (using .zip) the project and send it to a friend.
5) The friend has a Linux and he extract the project into:
/tmp
folder.
6) When the project is opened from that location. It is opened with a broken-reference to the library. That's correct.
7) ERROR - but meanwhile there is an exception dialog shown the stack trace listed above.

Reopening the issue again.

So the file path is invalid but it represents valid project state when moved to a new location.
None expects listen to such file and none expects that such file path can be normalized, but the exception should not be thrown.

I see five options:
- make the file path normalized anyway and do not produce /.. 
- throw an exception during the normalization (and catch it on all places where it can happen)
- ignore such case during the FileChangeListener registration (as the file is normalized - even it is wrong)
- detect such file before the FileChangeListener registration
- catch these IAEs around any call of the FileChangeListener registration 
 
But I see no way how can I help from the project classpath provider. The invalid file reference seems to be a valid use case.

I think the problem is in AntProjectHelper.resolveFile().
The user code does something like:

File root = theAntProjectHelper.resolveFile(thePropertyEvaluator.getProperty("path_property"))

When the property is relative and the path has more prents ("..") as there is in path to root of fs. The file like "/../XYZ" is created.

Guys, if you have a unit test not involving ClassPath API or project.ant API, feel free to assign to openide.filesystems. Until then, I don't want to disturb your argument with my defense. Assigning to ide meanwhile. Dispatch it as you want. I'll just have to add that without some isolated way to simulate the issue in openide.filesystems, I would close this as invalid from openide.filesystems point of view.

reassign back to filesystems, just because this issue came from that place.

ide/Code is used just as temp for "don't know where to report issue" and not as a trash for all not yet decided or all issues we haven't found conclusion where/how to solve yet.

I will create a test later today.
I don't persist on filesystems.
If File ("/a/../../b") is invalid => bug in project.ant which creates such a file. If it's valid it's in filesystem. It depends on your decision. On Unix it's a valid path as "/.." == '"/".

filesystems are not trash either.

Still undetermined where the fault lies. project.ant does call normalizeFile before returning any result from resolveFile, so even if the path is something useless like /../foo it should not trigger errors. ClassPath.RootsListener.addRoots is the immediate source of the unnormalized File; perhaps an assert could be added here.

The test is quite simple (has to be performed on Unix not Mac).

public void testWrongNormalization() throws Exception {
        final File file = new File ("/../../tmp/");
        final File normalizedFile = FileUtil.normalizeFile(file);
        FileUtil.addFileChangeListener(new FileChangeAdapter(){}, normalizedFile);
}

The problem is in in FileUtil.Holder.locateCurrent() which iterates over path = path.getParentFile() and asserts that path == FU.normalizeFile(path).
But normalizeFileOnUnixAlike() does
   
    if (file.getAbsolutePath().equals("/..")) { // NOI18N
            // Special treatment.
            file = new File("/"); // NOI18N
     }
   
so
FU.normalizeFile("/..") returns "/" which != "/.."

core-main#b41e6ddd0c01

A candidate for 6.9.1? Marking as such for now.

Is the fix safe and can it be verified working?

Integrated into 'main-golden', will be available in build *201006170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/b41e6ddd0c01
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #186359: /../tmp is /tmp

verified

main #b41e6ddd0c01 transplanted to release691 #402488c699b8