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 182529

Summary: Smaller openide.util for use in projects that may or may not be used from modules
Product: platform Reporter: _ tboudreau <tboudreau>
Component: -- Other --Assignee: _ tboudreau <tboudreau>
Status: NEW ---    
Severity: normal CC: err, hmichel, jglick, jtulach, mkleint
Priority: P3    
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:

Description _ tboudreau 2010-03-22 21:38:31 UTC 
Would like to split org.openide.util to separate out very general-purpose classes (justification below).

One key question for any patch:  Which strategy is preferable:
 - Have org.openide.util be a shared package across several modules
 - Use META-INF/netbeans/translate.names and actually repackage things?

Reposting from dev@platform:
I've run into an issue several times of wanting to use a few general-purpose classes from the Utilities API in non-module projects.  We're running into a particular issue with this in the Validation API project, because it builds against stub versions of NbBundle and a few other classes:  We want to convert it to Maven, which means a single build artifact (currently the Ant build creates one standalone JAR that bundles the stub classes, for general use, and another JAR which does not).  That would make a mess if it bundled its stubbed version of a few classes from org.openide.util, or an unsatisfied dependency otherwise.

Any other external project which is useful by itself but is designed to be used in NetBeans has the same problem - you either have to copy these classes, or copy the same code to use them reflectively with a fallback, or use some other mechanism to do the same thing which doesn't have, for example, the memory-management advantages of NbBundle.  Or you have to carry around a copy of org.openide.util, which contains a lot of classes that are less useful outside of NetBeans.

I'm thinking a solution would be to split org.openide.util further.  The things I've found myself using in external projects:
Frequently:
NbBundle
Exceptions
ImageUtilities
Utilities.getOperatingSystem() / Utilities.isMac() (could make a nice little enum - OperatingSystem.getOperatingSystem())

Less frequently:
NbCollections
EditableProperties
Comment 1 Jesse Glick 2010-03-22 21:45:34 UTC 
(In reply to comment #0)
> Use META-INF/netbeans/translate.names and actually repackage things?

translate.names is only useful for renaming implementation classes used in serialized objects. It is useless for API classes.

I think it will be rather difficult to pin down which classes in org.openide.util are "generally useful" enough to deserve inclusion. There is no clear criterion here.
Comment 2 _ tboudreau 2010-03-22 22:05:59 UTC 
Agreed, there's no clear demarcation - I'm basing this on what I've needed to stub out in several projects already.

There are a few demarcations available, though:

 - "useful outside of NetBeans" versus "useless outside of NetBeans" (w/o supporting infrastructure anyway - ExClipboard, ActionPerformer, HelpCtx)

 - Area of concern vs. general-purpose:
  - Localization (NbBundle)
  - Error Handling (Exceptions, ErrorManager, Parameters, misc Exception subclasses)
  - Threading (RequestProcessor, Task, Mutex)
  - Actions (*Action, Action*,
  - Clipboard operations (ExClipboard, 
  - I/O (*Stream)
  - Various collection extensions (WeakSet, NbCollections, Enumerations)

 - Rarely used versus frequently used (NbBundle vs., say, NbMarshalledObject)

Since we're unlikely to split out all such concerns into separate modules, any such split is going to involve making some arbitrary decisions.  I don't think the lack of ideal natural boundaries means we can do nothing - that would be rather making the perfect the enemy of the good.

But if such a change is more attractive if I do split up those things that have natural separation of concerns, I can certainly do that too.

Once I have something to commit, it will appear in the prototypes repo on branch openide-util-split-182529
Comment 3 Jesse Glick 2010-03-22 22:43:29 UTC 
(In reply to comment #2)
>   - Localization (NbBundle)

This doesn't offer much value unless you are using NB's branding facility; otherwise you could just use ResourceBundle.

>   - Error Handling (Exceptions

Intended for use with the core's logger impl; otherwise not all that useful.

> ErrorManager

De facto deprecated.

> Parameters

Mildly useful in general.

> misc Exception subclasses)

Probably not useful.

>   - Actions (*Action, Action*,

Generally not useful outside of the Platform.

>   - I/O (*Stream)

Rarely used even in NB (mainly useful for old serialized settings), could probably be moved to some autoload some day.

>   - Various collection extensions (WeakSet, NbCollections, Enumerations)

These are of general utility. (Of course it would be better if the JRE included them.)

> Once I have something to commit, it will appear in the prototypes repo on
> branch openide-util-split-182529

OK, but for this kind of change the decisions about what goes where are better made by regular conversation; the code changes are likely to follow naturally from those decisions.
Comment 4 Jaroslav Tulach 2010-03-23 13:56:48 UTC 
Y01 Please make sure that either the old module org-openide-util.jar or the new module is not in platform/lib, but in platform/modules. 

I do not want additional modules on java -cp, the less we load with classical ClassLoaders, the better.