Are you perchance passing backslashes (\) to JSR 269 methods expecting resource paths? Because a resource path must always be /-separated regardless of operating system.

In the case of the first exception, yes, we are passing literally "wt\fc\_NetFactor" as name to

JavaFileObject f = env.getFiler().createSourceFile(name);

and later calling

openWriter() on f.

So we're only supposed to be using forward-slashes? It's curious that neither javac nor the Eclipse compiler complain -- and NetBeans isn't very clear about what it dislikes here.

I'll get that changed and see if that resolves the issue.

From JavaFileManager javadoc:

getFileForInput(SOURCE_PATH, "com.sun.tools.javac", "resources/compiler.properties");

If the call was executed on Windows, with SOURCE_PATH set to "C:\Documents and Settings\UncleBob\src\share\classes" a valid result would be a file object representing the file "C:\Documents and Settings\UncleBob\src\share\classes\com\sun\tools\javac\resources\compiler.properties"

Please let me know if fixing the separators solved also the NPE.
Thanks

Sorry, I was mistaken.

We are calling:

JavaFileObject f = env.getFiler().createSourceFile(name);

but name is of the form "wt.fc._NetFactor" (as per the Javadoc for this API) in the case in question at least when we run our annotation processor from Ant.  This is built up from TypeElement APIs, so something is loused up in NetBeans here in any case, either the TypeElement APIs or the JavaFileObject handling.

The  "wt.fc._NetFactor" is a valid parameter to Filer.createSourceFile. Are you sure that you don't pass such a name to createResource or getResource where it's not valid?
I will add logging into FMs.

The exception is consistently arising from com.sun.tools.javac.processing.JavacFiler$FilerOutputFileObject.openWriter(JavacFiler.java:131) on the JavaFileObject resulting from Filer.createSourceFile().

I added some debug output to our annotation processor and, yes, we are definitely passing "." delimited names to Filer.createSourceFile() in the NetBeans case, so somehow the JavaFileObject implementation in NetBeans is producing backslashes from this and tripping up.

OK, thanks. I will try to get some Win box and try it.

This is exception report #373719.

Now I am able to reproduce it on Windows with my test processor.

The java.lang.IllegalArgumentException fixed.
Fixed jet-main e9ae2362b373

If the second exception happens even after the fix of this first one please report it as a new issue or reopen this one, I will create a new issue for it. Thanks
Fixed jet-main e9ae2362b373

(In reply to comment #12)
> jet-main e9ae2362b373

BTW the

  if (File.separatorChar != '/')

guard is unnecessary as s.replace(c,c) == s, so could be simply

  return getRelativePath(new File(root.toURI()), new File(fo.toURI())).
    replace(File.separatorChar, '/');

The check is done to prevent O(n) traverse through the string in replace when it's not needed.

Integrated into 'main-golden', will be available in build *201004220200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/e9ae2362b373
User: Tomas Zezula <tzezula@netbeans.org>
Log: #184503:Exceptions during source code scanning/parsing

I tried the fix -- and it resolved the IllegalArgumentException, but not the NullPointerException.

I tried to use the Exception Reporter to send the log, etc, but the current nightly has issues here -- attempts to report exceptions raise other exceptions.

I'll attach a from the 201004220200 nightly.

Created attachment 97862 [details]
NetBeans log file showing exceptions during annotation processing

A few notes on the NetBeans log I am attaching are in order.

First off, the "Annotation processing generation COMPLETE..." and "Annotation processing round..." message are from our annotation processor and can be ignored.

Secondly, there are actually 3 distinct exceptions in this log:
1) A NullPointerException in com.sun.tools.javac.main.JavaCompiler.processAnnotations().
2) An java.lang.UnsupportedOperationException (No apt root for source root: null) in org.netbeans.modules.java.source.parsing.AptSourceFileManager.getJavaFileForOutput()
3) A java.lang.NullPointerException in org.netbeans.modules.exceptions.ReportPanel.initComponents().

The last of these is clearly an issue with the Exception Reporter functionality and is distinct from the other issues.

I get the impression from the first two exceptions that the generated source tree root (ala -s in javac) may not have been initialized, but that's just a guess.  We pass -s to javac, of course, but there is currently no means to specify such a directory via free-form projects (and I thus I can only assume an internal temporary directory is used or some such).

It's better not to mix two excpetions in the single issue. I will create a new one for the NPE.
The new issue is #184734.

(In reply to comment #15)
> The check is done to prevent O(n) traverse through the string in replace when
> it's not needed.

If it's not needed, there is no traversal of the source string at all - check String.replace source.

Right, the String.replace has the same guard.
if (oldChar != newChar) {...}