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.
The scala.editor module provides a JavaSourceProvider, but the provider returns non-null value for all files from forFileObject. This is wrong, as the Java support then tries to process the content of the files as Java sources, wasting time (and causing exceptions like in issue #114318). Please return non-null value from JavaSourceProvider.forFileObject only when necessary. The "getSupportedExtensions" method is not used by JavaSourceProvider, sorry. I am also making the semantic highlighter more robust, so it will not throw the exception, but that won't be part of 6.5.
In some cases I need to get JavaSource instance for .scala file: 1. Scala's debugger is implemented on NetBeans' JPDA modules, which will call JavaSource#forFileObject to get an JavaSource instance when editor try to eval the value of variable/expression that user moving mouse over, if it returns null, will throw NPE. To let JavaSource#forFileObject return an instance, I have to provider a JavaSourceProvider. I cannot find an easy way to resolve it currently. 2. I need to enable Java's indexing for Scala files, so, the Scala's class/method will be visible for Java files in the same project, for this purpose, I may need to provide JavaSourceProvider for Scala So, I'm wondering that in which cases, will the implementation of JavaSourceProvider causes throwing such exceptions, or, why these exceptions happen when editing a Java file? Any idea?
BTW, I noticed that issue #114318 is re-opened with NetBeans IDE Dev (Build 200810160201), and mostly when open an properties file, which happened before I added Scala's JavaSourceProvider implementation at Oct 19 (http://hg.netbeans.org/main/contrib/rev/e80b375a1c4d)
I just verified, it's caused by ScalaVirtualSourceProvider.java
I've committed a fix: contrib/rev/a2f68866ef28, which only return JavaSourceProvider for .scala files. This resolves issue #114318 But the scala.editor's JavaSourceProvider is still not correctly implemented. Or, should there be better way that can avoid JavaSource#forFileObject call on .scala files? Leave it open.
Sorry if my original report for confusing. The problem mostly was/is that the return value from JavaSourceProvider.forFileObject(...).filterCharSequence(...) is expected to be Java source, and originally the scala.editor returned the content of any file from this method. So, the Java infra was trying to parse e.g. the content of the properties file as a Java source, and was trying to run Java semantic highlighter on it (which failed for properties, because the Java semantic highlighter expects that there are lexer tokens for the given file, but there are no lexer tokens for properties - it still uses the old Syntax to perform syntax highlighting. The Java semantic highlighting was changed to ignore files without lexer tokens.) The situation should be much better after your fix, thanks. The only problem is that the Java infra will (likely) still try to parse the scala source as if it was Java, and perform Java semantic highlighting and mark occurrences on it. Not sure what exactly needs the Java debugger from the JavaSource, but it would be good if we found the smallest possible Java code that is acceptable for the debugger (maybe even the empty string?). The scala.editor's filterCharSequence would then return this Java code. Returning -1 from the position conversion methods would be good too (this would prevent the Java semantic highlighter and mark occurrences to paint "randomly" into a scala file). For #2, the JavaSourceProvider is not used - the VirtualSourceProvider is used for these purposes, so any content from the JavaSourceProvider shouldn't be a problem (hopefully).
contrib/rev/f903e5605ea1 Let JavaSourceProvider's implementation return -1 or ""