Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 157828 - ModuleInfo.forClass(Class)
ModuleInfo.forClass(Class)
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Module System
6.x
All All
: P3 with 1 vote (vote)
: 7.0
Assigned To: Jesse Glick
issues@platform
: API, API_REVIEW_FAST, PERFORMANCE
: 188606 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-03 10:00 UTC by puce
Modified: 2010-07-21 03:15 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Proposed patch (16.90 KB, patch)
2010-07-12 22:27 UTC, Jesse Glick
Details | Diff
Revised patch, with org.openide.modules.Modules (21.26 KB, patch)
2010-07-15 00:00 UTC, Jesse Glick
Details | Diff
Revised patch (21.88 KB, patch)
2010-07-16 21:14 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description puce 2009-02-03 10:00:48 UTC
It would be good to have a method, which returns the ModuleInfo for a class, so one doesn't
have to iterate over all instances, eg. something like:
 
public static ModuleInfo forClass(Class clazz) {
        ClassLoader cl = clazz.getClassLoader();
        if (cl instanceof Util.ModuleProvider) {
            return ((Util.ModuleProvider) cl).getModule();
        }
        return null;
        
    }

Make sure this also works for JNLP applications! (see http://www.netbeans.org/issues/show_bug.cgi?id=157798)
Comment 1 Jesse Glick 2009-02-13 16:40:33 UTC
Probably not an immediate priority.
Comment 2 Jesse Glick 2010-07-12 21:43:54 UTC
Should not have been closed.
Comment 3 Jesse Glick 2010-07-12 21:44:05 UTC
*** Bug 188606 has been marked as a duplicate of this bug. ***
Comment 4 Jesse Glick 2010-07-12 22:27:00 UTC
Created attachment 100784 [details]
Proposed patch
Comment 5 Jesse Glick 2010-07-12 22:27:24 UTC
Please review the attached API enhancement.
Comment 6 Jaroslav Tulach 2010-07-13 15:16:28 UTC
Y01 Rather than static method, introduce org.openide.modules.ModuleManager class with getDefault() and other useful methods.

Background for Y01: One of the most common things is to be notified whether a set of modules changed. This is tricky right now. Having a ModuleManager to add such listener to, would simplify quite a lot of code (ide.ergonomics, maven, etc.). If you implement Y01, I can add the the listening capability then.

Y02 If you have ModuleManager class, you probably don't need OwnershipProvider.
Comment 7 Jesse Glick 2010-07-13 15:47:28 UTC
Y01 - you can already call

Lookup.getDefault().lookupResult(ModuleInfo.class).addLookupListener(...)

What specifically are you looking for?

This sounds like a much larger scope than the RFE currently calls for and I am afraid it would block an otherwise useful and simple addition.
Comment 8 Jaroslav Tulach 2010-07-14 13:53:00 UTC
Re. lookupResult(ModuleInfo.class).addLookupListener(...): It is not enough. You also need to add listener to each ModuleInfo and listen to PROP_ENABLED. Tedious.

I don't want to complicate and block anything. I am not doing that! To rephrase my request. I am just suggesting to move the proposed static method from ModuleInfo to newly created class ModuleManager and make the method non-static.
Comment 9 Jesse Glick 2010-07-15 00:00:24 UTC
Created attachment 100839 [details]
Revised patch, with org.openide.modules.Modules

Addresses Y01. (Prefer not to use "ModuleManager" since that could cause confusion with org.netbeans.ModuleManager.)
Comment 10 Jaroslav Tulach 2010-07-15 08:49:15 UTC
OK, thanks. API is fine. Few implementation comments which you may ignore:

Y03 Modules implementation is an annonymous inner class. I'd prefer to register it as a real top level class.

Y04 As we are likely to add new methods into Modules and we might benefit from making them abstract, would it not be beneficial to enumerate list of allowed subclasses in constructor? E.g. if (!"org.netbeans.core.ModulesImpl".equals(getClass().getName())) throw new ISE();

Y05 Should not the registration of the Modules implementation be done as @ServiceProvider annotation?

Y06 Should not the ModuleManager (or anything else in o.n.bootstrap or core.startup) be the class that extends Modules?
Comment 11 Jesse Glick 2010-07-16 21:14:09 UTC
Created attachment 100895 [details]
Revised patch

Addresses Y03/Y06; and since http://bitbucket.org/jglick/qualifiedpublic does not seem able to run on JDK 6, Y04. Y05 is impossible since ModuleManager is not a singleton as far as tests are concerned.
Comment 12 Jesse Glick 2010-07-19 16:50:56 UTC
core-main #66adb7792a19
Comment 13 Quality Engineering 2010-07-21 03:15:45 UTC
Integrated into 'main-golden', will be available in build *201007210001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/66adb7792a19
User: Jesse Glick <jglick@netbeans.org>
Log: Issue #157828: new client method ModuleInfo.forClass avoids linear search.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo