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.
In order to fully migrate to use of the Classpath API, there are several things historically defined in core/openide which need to be deprecated, and suitable replacements found, perhaps in the java/api module. 1. TopManager.currentClassLoader assumes that Repository == default ClassPath. It should probably be deprecated. This functionality could equally be implemented in a module anyway; java/api would be a reasonable candidate, as it would permit definition of user-mode classloaders based on a particular classpath, optionally with a facility to automatically refresh the loader after a change to classes it has already loaded. 2. nbrescurr: and nbrescurrloc: protocols are wrappers for currentClassLoader and so suffer from the same problem. Ideally the identity of the classpath should be somehow encoded in the URL. 3. All of the constructors of NbClassLoader (and so, probably, the whole class) should be deprecated since they either use FileSystemCapability.EXECUTE, or assume that classpath roots are filesystem roots. There should be a constructor accepting a ClassPath, or at least a FileObject[] of roots. 4. InstanceDataObject currently permits the class for .instance to be loaded from the repository (i.e. currentClassLoader). This should be changed to use systemClassLoader. Unfortunately, the Form Editor relies on this functionality. Probably compatibility cannot reasonably be retained, so suggest a new object type (.userinstance? .bean?) which encodes not just a class name, but a class path too. The Component Palette would need to begin using the new extension (and $userdir/system/Palette/**/*.instance somehow upgraded?). 5. ThreadExecutor might survive with only impl (not API) changes - if execute(ExecInfo) is changed to throw NotImplementedException, and execute(DataObject) is changed to find the classpath for the data object and create an NbClassLoader from that.
Ad (2): If sufficient, those protocols may be changed to nbrescurr:/ProjectName/project-path-to-resource Ad (4): being tracked separately as issue #27123.
OK.
Ad. (1) I was thinking about a "compatiblity" module on AutoUpdate that would add classpathitems from all opened modules as hidden treefs with execution/compilation capability on. That would solve the problem for currentClassLoader too.
made this issue block NB platform's issue 26921 "Implement Projects requirements on NB Platform". I think to resolve this one we need to do something in core/openide
The TM.currentClassLoader should be handled compatibly, described in issue 27386.
Svata, could this be (partially) implemented for 3.5? Could you add a method: ClassLoader ClassPath.getClassLoader (); that would work in similar way as core.deprecated.ClassLoaderSupport? Thanks.
Suggest that ClassPath.getClassLoader take a boolean param 'cached'. If true, the CP object would try to keep a (soft?) reference to the class loader, but it would clear this reference if any *.class or *.properties file loaded by the prior loader were changed on disk (more or less as the old ClassLoaderSupport did). If false, a new ClassLoader would always be returned. Also suggest again that all existing constructors of NbClassLoader be deprecated, and replaced with one new constructor which takes a FileObject[] of classpath roots, and a second one which additionally takes an InputOutput. I could supply a possible patch if you are interested.
Any plans about ClassLoader ClassPath.getClassLoader?
Do you mean the NbClassPath constructor change for 3.5 ?
Hmm... pretty close to feature freeze huh? :-) It would be *nice* for there to be nondeprecated replacements for all missing TopManager calls in the 3.5 release. I think we could live without it, just depends on how much time you have.
NbClassLoader stuff, will be modified as Jesse says, but that is not necessary for ClassPath.getClassLoader() - better to do it after that. So if you Svata can add the getClassLoader (....), as it is the basic functionality we need as replacement of TM.currentClassLoader.
ClassPath.getClassLoader(boolean) is already there.
ClassPath.getClassLoader is however wrong as written AFAICT, since it ignores the actual classpath roots and just uses the roots of the filesystems they are contained on, which will not work at all if cp != filesystems. In order to be written correctly it needs a NbClassLoader(FileObject[]) constructor. I see you override findClass as a workaround (ugly - clobbers careful impl in NbClassLoader) but findResource will still not be correct. Note that ClassPath.getClassLoader will probably need to also take an InputOutput arg so that Internal Execution can be implemented correctly later. I also noticed this code: propListener = WeakListener.propertyChange (this, null); cp.addPropertyChangeListener(propListener); which is not ideal - the 2nd arg to WL.pC should be cp.
Note that in NB-3.5, there can be (still) no other ClassPath instances than those created by ClassPath.getClassPath(), which always returns roots of filesystems. I coded ClassLoaderSupport to use FileSystems so that I don't need changes in NbClassLoader ;-) If there is a constructor in 3.5, I'll change ClassLoaderSupport's implementation. As for overriden findClass() - I shamelessly copied the code from core/deprecated classloader impl. I do not understand your comment, sorry; please elaborate. I'll add the I/O parameter.
Alright, well let's just add the NbClassLoader(FileObject[],InputOutput) constructor - it should be very easy to implement, and will help make sure that there is a complete replacement for currentCL for 3.5. Re. overriding findClass - sorry, did not notice you were calling super, so that part is OK. I was complaining that if for any reason cp != filesystems, findResource will not be right. Anyway org.netbeans.core.ClassLoaderSupport was never right re. bundles. Suggest that: 1. ClassLoaderSupport.findClass be deleted (do not override). 2. ClassLoaderSupport.findResource override NbClassLoader.fR: call super; check for a FileObject if result != null; if fo has exts ".class" or ".properties" (any others likely to be cached by global mechanisms? maybe ".gif" etc. because of Toolkit.loadImage caching) then attach a file listener as now (to reset the loader if the file changes).
Svato and others, what is the status of this task? It seems to me that the projects related part is done; I am not sure about the core/openide stuff. I would suggest to split it to several tasks and assign them to appropriate modules.
BTW ClassPath.getClassLoader is still missing a variant which accepts a ClassLoader parent, which is a serious omission; e.g. the Ant module in the trunk cannot use this method because it needs to pass a specific parent loader.
Removed PROJECTS keyword since the projects prototype has been canceled. For more details see http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss
I think this is done now.