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.

Bug 27112 - Deprecate currentClassLoader-related functionality
Summary: Deprecate currentClassLoader-related functionality
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Classpath (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker with 1 vote (vote)
Assignee: Tomas Zezula
URL:
Keywords: API
Depends on: 27123 27386
Blocks: 26921
  Show dependency tree
 
Reported: 2002-09-07 05:11 UTC by Jesse Glick
Modified: 2004-08-13 12:11 UTC (History)
7 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-09-07 05:11:19 UTC
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.
Comment 1 Svata Dedic 2002-09-09 10:45:21 UTC
Ad (2): If sufficient, those protocols may be changed to
nbrescurr:/ProjectName/project-path-to-resource

Ad (4): being tracked separately as issue #27123.
Comment 2 Jesse Glick 2002-09-09 14:07:18 UTC
OK.
Comment 3 Jaroslav Tulach 2002-09-10 07:38:08 UTC
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.
Comment 4 _ ttran 2002-09-10 20:46:15 UTC
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
Comment 5 Jaroslav Tulach 2002-09-20 09:14:04 UTC
The TM.currentClassLoader should be handled compatibly, described in
issue 27386.
Comment 6 Jaroslav Tulach 2003-02-07 14:01:55 UTC
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.
Comment 7 Jesse Glick 2003-02-07 15:42:33 UTC
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.
Comment 8 Jaroslav Tulach 2003-02-13 09:29:47 UTC
Any plans about ClassLoader ClassPath.getClassLoader?
Comment 9 Svata Dedic 2003-02-21 17:20:32 UTC
Do you mean the NbClassPath constructor change for 3.5 ?
Comment 10 Jesse Glick 2003-02-21 18:56:44 UTC
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.
Comment 11 Jaroslav Tulach 2003-02-24 09:43:56 UTC
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.
Comment 12 Svata Dedic 2003-02-24 09:52:28 UTC
ClassPath.getClassLoader(boolean) is already there.
Comment 13 Jesse Glick 2003-02-24 22:28:54 UTC
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.
Comment 14 Svata Dedic 2003-02-25 10:28:36 UTC
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.

Comment 15 Jesse Glick 2003-02-25 15:15:39 UTC
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).
Comment 16 Vitezslav Stejskal 2003-04-07 14:30:19 UTC
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.
Comment 17 Jesse Glick 2003-07-17 15:15:48 UTC
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.
Comment 18 Jan Pokorsky 2003-11-27 13:54:44 UTC
Removed PROJECTS keyword since the projects prototype has been
canceled. For more details see
http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss
Comment 19 Jesse Glick 2004-04-02 21:35:01 UTC
I think this is done now.