[nbusers] Re: libraries and classpath

  • From: netbeans enthusiast < >
  • To:
  • Subject: [nbusers] Re: libraries and classpath
  • Date: Mon, 7 Jan 2013 18:07:20 -0500

Since the bundle itself is public API, right?

http://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/NbBundle.html

We're piercing together of (API) bundle keys using non-API utility classes which act as a kind of gate keeper to the bundle...




On Mon, Jan 7, 2013 at 3:51 PM, netbeans enthusiast < " target="_blank"> > wrote:
Tell you why I asked.  In  org.netbeans.modules.java.testrunner.GuiUtils there are defined a bunch of public static final Strings. The values of these Strings have a dependency (they must be equivalent to) strings found in the evaluation of this line:

NbBundle.getBundle(GuiUtils.class);

which bundle itself is located in module Java Testrunner package org.netbeans.modules.java.testrunner.

This is a "public" package (little lock icon unlocked in Projects) and GuiUtils.java is a public class however, it's not a "public" API which means despite all that aforementioned publicness, utilizing that class in a (public) API is questionable.

To get around this fact (apparently) in NB source defines an interface GuiUtilProvider whose implementation - org.netbeans.modules.java.testrunner.providers.JavaGuiUtilsProvider provides a way for callers of some of its methods to utilize those values indirectly (it itself references them directly internally ).

The exposure is done through a map whose key is a *similar* set of Strings and whose values are the strings themselves.

The keys, those *similar* strings which callers of GuiUtilsProvider use to indirectly access the Strings in GuiUtils (and which have to be the same as a partial string in the bundle) aren't actually exported to callers in any way, instead, the same String is just typed in raw when and where it's needed.

Some questions pertaining to this situation arose.

It would be nice to just directly use the public static  Strings in GuiUtils rather than go through so many levels of indirection and just flat out "type the same string right-hereness" . I *tried* to import GuiUtils into CommonTestsCfgOfCreate where those Strings are needed but  to do that I would have had to import a (non-public, broadly considered) non-API class into a public API.

But the reality of it is, that non-public API IS imported into the  public API however you want to look at it by the coincidence of String names that gets driven through the code everywhere. It may compile if that dependency is broken, but it won't run without blowing up. The dependency starts at the bundle k/v pairs and proceeds through GuiUtils and then to GuiUtilsJavaProvider and GuiUtilsProvider and finally to the undocumented, unenforceable by the compiler coincidence of arbitrary but duplicated Strings that need to be just typed, raw, into invoking methods because they happen to be keys somewhere else in the code......

All this begs for some rationalization, no? If all of the above was no-fun and hard to read, believe me it was less fun and harder to understand. It's not my place to contravene where the public / non-public API line has been drawn by the architects  but if I could just understand better what is and is not public API and what the specific motivations for making specific classes part of the public API and others not maybe something could be worked out or at east better understood.

It should be said that all this in service of extending unti testing to include private methods and inner classes. That's the overlying motivation for even considering these classes in the first place.

HTH


On Mon, Jan 7, 2013 at 2:45 PM, netbeans enthusiast < " target="_blank"> > wrote:
Thanks g. Yeah my gmail sends out email drafts for some reason... I did not mean public module  I meant (public) API modules. Netbeans uses this terminology; see attached.

I am wondering if there is some naming convention which distinguishes the two so that when I am using the modules I can tell which is which. Using non-public (as in non-published / non-supported) API from within API classes is a mistake .. I think I read that in one of the NB books at some point.

thanks... 

On Mon, Jan 7, 2013 at 2:27 PM, Geertjan Wielenga < " target="_blank"> > wrote:
On 01/07/2013 08:25 PM, netbeans enthusiast wrote:
In the Projects view, each considered module has a libraries folder which contains a platform and a list of other modules. Is the sum of those libraries the effective classpath for the considered module?

Is there some way of knowing if a module is a "public module" or a "non-public module" by looking at its FQN or representation in the projects view?
Join " target="_blank"> and ask your NetBeans Platform questions there.

You'll find that there's no such thing as a public/non public module, but a public/non public package -- if you work through the NetBeans Platform Learning Trail.

Gj





[nbusers] libraries and classpath

netbeans enthusiast 01/07/2013

[nbusers] Re: libraries and classpath

Geertjan Wielenga 01/07/2013

[nbusers] Re: libraries and classpath

netbeans enthusiast 01/07/2013

[nbusers] Re: libraries and classpath

netbeans enthusiast 01/07/2013

[nbusers] Re: libraries and classpath

netbeans enthusiast 01/07/2013

[nbusers] Re: libraries and classpath

netbeans enthusiast 01/07/2013

Project Features

About this Project

www was started in November 2009, is owned by jpirek, and has 21 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20140418.2d69abc). © 2013, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close