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.
Not sure where to put this...so I chose core, feel free to move it where it actually belongs. On OpenVMS, we are seeing the "Scanning Project Classpaths" message box repeatedly, and at unexpected times. In addiotn, we see the "Initializing scanning...please wait" multiple times in the same session. We are looking into the problem and will post more information as we have it. Meg/Isao
I would start from javacore module that does the scanning, especially when I was told that it does not use FileObject to access the files just a plain java.io.File.
Please do post more information. I did not see it on other platforms.
Yes, we'll get back to you soon. We believe it may have something to do with the case of the filespecs. We've been seeing other problems related to this same phenomenon. On VMS, the filespecs are case-insensitive. And depending on how (or who) you ask for a fielspec, it may come back with some or all parts of it capitalized. Meg
I am sorry, but what is 'filespec'?
Oh sorry, 'filespec' is shorthand for 'file specification'. For example /efs/abc/foo.bar On VMS, this same file specification could be returned by a call to a member of the File class as "/efs/abc/foo.bar" or it might be returned as "/EFS$/abc/FOO.BAR" (or some other combination of upper and lower case).
We had the same problem on Windows with J2ME Project type and SonyEricsson emulator as platform providing bootclasspath. Repeated scanning was caused by different URLs of classpath entries provided by platform and URLs of classpath entries provided by project. Some project classpath entries stayed in unresolved list and caused never-ending scanning. The root cause of this problem was usage of normalized files for construction of platform classpath entries and files without normalisation for construction of project classpath entries. The difference was in UPPER/lower case in path. The IDE once compares the entries by files (or FileObjects) and they match and once by URLs and they don't match - and this is a bug. I think that there can be similar or bigger file normalisation problem on OpenVMS.
We have a fix for this. What cvs tag should we create a diff against ? thanks /Meg,Isao
Great! Please do a diff against latest trunk. Thanks
Hi, We are submitting patches for this shortly. /Isao,Meg
Created attachment 17766 [details] Patch file for NbTopManager.java
Created attachment 17767 [details] Patch file for FileUtil.java
Created attachment 17768 [details] Patch file for NbInstaller.java
Created attachment 17769 [details] Patch file for NbClassPath.java
Created attachment 17770 [details] Patch file for FileScanner.java
Created attachment 17771 [details] Patch file for J2SEPlatformImpl.java
Tomasi, can you review path for FileScanner.java and reassign this issue to other modules to let them review patches for their code? Thanks.
The patch for the FileScanner does need to be applied. It is in fact a bug which is not directly related to using OpenVMS. It may cause problems even on windows. I will apply it.
I applied the patch for FileScanner.java only partially, since .java and .class extensions are case sensitive even on Windows (*.JAVA files do not compile - Isao, please confirm it is the case also in OpenVMS), so we do not use toLowerCase when matching them. Checking in src/org/netbeans/modules/javacore/scanning/FileScanner.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/FileScanner.java,v <-- FileScanner.java new revision: 1.8; previous revision: 1.7 done Reassigning to core to fix NbTopManager and NbInstaller.
I agree, partial patch should be ok on OpenVMS as well. thanks /Isao
I've looked at the patch of FileUtil while integrating the issue #49312 and I've found the following problems. The patch adds new public methods which are Open VMS specific. These methods will need to go to API review but it is too late fo NetBeans 4.0. It would be better to remove them and use FileUtil.normalizeFile () and add switch into the normalizeFile method for Open VMS. See the attached diff, (I am not sure if the attached diff works, I have no Open VMS access). The usage of normalizeVMSFilePath (path) will need to be replaced by FileUtil.normalizeFile ().getAbsolutePath(). Similarly for the normalizeVMSFilePaths.
Created attachment 17903 [details] Patch of FileUtil
Reassigning to get comments about changed diff.
Hi, thanks for looking into this issue and for your suggested solution. We're worried that the patch you suggest will impact NetBeans performance on VMS since File.normalizeFileOnVMS() will do the directory scan *every* time File.normalizeFile gets called. We only need to normalize the class paths returned from "sun.boot.class.path", "java.ext.dirs" and "java.home" (because of a problem in the current version of our JVM). So we have decided to workaround this problem by modifying the NetBeans launcher for VMS instead. This will eliminate the need for the patches submitted to this issue, except for FileScanner.diff. The FileScanner patch is already applied to CVS as a bug fix for other platforms as well, and we have tested it on VMS and it works. I will also update the patch for the issue 49312 so that File.normalizeFileOnVMS() won't get used. Thanks again, and sorry we didnt get this in sooner. /Isao
Fine, this would be the best solution at all. It will remove nearly all OpenVMS specific patches.
Yarda, can you please review the diff and apply it. For the platform parts at least
cvs ci -m "#48616: Applying patch by isao and tzezula to make normalizeFile behave differently on Open VMS" src/org/openide/filesystems cvs commit: Examining src/org/openide/filesystems Checking in src/org/openide/filesystems/FileUtil.java; /cvs/openide/src/org/openide/filesystems/FileUtil.java,v <-- FileUtil.java new revision: 1.117; previous revision: 1.116
Hi I explained on 2004-09-29 07:56 PDT to this issue that no patches except the FileScanner(which is already applied) are needed, and we are going to make changes in the launcher instead. Tomas also agreed. Please undo the change. Please refer to the following comments on this issue: Additional Comments From isao 2004-09-29 07:56 PDT Additional Comments From Tomas Zezula 2004-09-30 01:32 PDT /isao
cvs ci -m "Reverting the previous patch as isao does not need it anymore" cvs commit: Examining . Checking in FileUtil.java; /cvs/openide/src/org/openide/filesystems/FileUtil.java,v <-- FileUtil.java new revision: 1.118; previous revision: 1.117
no further comments - closing.