Best way to share object instances between modules?

[Sergio Lopes-3]

Hi,
I have an application divided into several modules and I need to share
on object that represents my application module between other modules.
I have created a module name "Catalog" which implements all the
features needed by my application, but I need other module to access
one particular instance. How can I share this particular instance? Is
there any suggested way?

--
Sem mais e com os melhores cumprimentos,

Sérgio Lopes

[bruehlicke]

Lookup - for sure.

You can use the global lookup if you like or create your own - see Wade's example under http://wadechandler.blogspot.com/2007/12/central-lookup-creating-central.html

B-)

On Wed, Apr 30, 2008 at 10:33 AM, Sergio Lopes <knitter.is@...> wrote:

Hi,
I have an application divided into several modules and I need to share
on object that represents my application module between other modules.
I have created a module name "Catalog" which implements all the
features needed by my application, but I need other module to access
one particular instance. How can I share this particular instance? Is
there any suggested way?

--
Sem mais e com os melhores cumprimentos,

Sérgio Lopes

[Sergio Lopes-3]

Lookup is something I have been looking at, but it doesn't look simple
to add normal objects to the lookup.
I'm now faced with the doubt of where/when can/must I put my object
instance in the lookup?

The catalog module has a class, CatalogEngine, that provides
everything I need to do with my application, it is the model in an
typical MVC structured application.
I need the Gui module to access this class. I don't know where to
instanciate it. One other problem is that I have an option to create
new catalogs, that will need to override the CatalogEngine instance
being used.
The code to create a new catalog engine is placed inside a dialog
window that is open through the menu.

So I need to know two things:
- Where should I instantiate my model and put it into a lookup?
- How can I notify other TopComponents that exist in the GUI module
and that need to display data from the model, CatalogEngine?

I think my doubts came from not understanding the platform, I would
easily implement this in a normal MVC application.

--
Sem mais e com os melhores cumprimentos,

Sérgio Lopes

[tomwheel]

On 5/12/08, Sergio Lopes <knitter.is@...> wrote:
> Lookup is something I have been looking at, but it doesn't look simple
> to add normal objects to the lookup.
> I'm now faced with the doubt of where/when can/must I put my object
> instance in the lookup?

Hi Sergio,

The Lookup may seem tough at first, but it's actually quite simple and
flexible.  Let me give a quick example.  Imagine that you are writing
an application that will calculate someone's income tax.  This should
break down into three modules:

Module 1: API
    - contains com.example.tax.IncomeTaxCalculator interface
    - has no dependency on any other module

Module 2: implementation
    - contains com.example.tax.ConcreteIncomeTaxCalculator class which
implements the com.example.tax.IncomeTaxCalculator interface
    - depends only on the API module
    - has a file
src/META-INF/services/com.example.tax.IncomeTaxCalculator which
contains only a single line the name of the class implementing that
interface (com.example.tax.ConcreteIncomeTaxCalculator in this case)

Module 3: UI
    - has a UI that gets user input, calculates tax and displays the result
    - depends only on the API module
    - Looks up implementation at runtime like this:

     IncomeTaxCalculator calc =
Lookup.getDefault().lookup(IncomeTaxCalculator.class);

Note that you do not ever need to directly instantiate any type of
IncomeTaxCalculator.  No code, aside from that in Module 2, should
even know the name of the IncomeTaxCalculator implementation class --
everything should use the interface.

--
Tom Wheeler
http://www.tomwheeler.com/

[Sergio Lopes-3]

>      IncomeTaxCalculator calc =
>  Lookup.getDefault().lookup(IncomeTaxCalculator.class);
>
>  Note that you do not ever need to directly instantiate any type of
>  IncomeTaxCalculator.  No code, aside from that in Module 2, should
>  even know the name of the IncomeTaxCalculator implementation class --
>  everything should use the interface.
The way you're describing it implies that there has to be a module
with an interface and another with the implementation. I have no such
thing.

What I have is something in the lines of:
- Module Catalog provides the application logic, it exposes, through
public methods, all available actions.
- Module GUI provides all interface options, top components, dialogs,
actions, and so on. It must access the CatalogEngine class, inside the
module Catalog, in order to send user input and request all the data
to display.
- Module GUI depends on Module Catalog, that in turn depends on some
other modules that wrap various libraries I need.

I have tried to look for an instance of the class CatalogEngine, the
lives inside the Catalog module, in one of my TopComponent's subclass,
that lives inside the GUI module. I tried that because I read
somewhere, either in the wiki or the API docs, that I could pass an
Interface or a Class, but I always get null.
I have tried to get the instance in various places, an installer class
on the GUI module, various constructors for classes inside the GUI
module. The result is always null.

--
Sem mais e com os melhores cumprimentos,

Sérgio Lopes

[Wade Chandler]

--- Sergio Lopes <knitter.is@...> wrote:

> >      IncomeTaxCalculator calc =
> >  Lookup.getDefault().lookup(IncomeTaxCalculator.class);
> >
> >  Note that you do not ever need to directly instantiate any type of
> >  IncomeTaxCalculator.  No code, aside from that in Module 2, should
> >  even know the name of the IncomeTaxCalculator implementation class --
> >  everything should use the interface.
> The way you're describing it implies that there has to be a module
> with an interface and another with the implementation. I have no such
> thing.
>
> What I have is something in the lines of:
> - Module Catalog provides the application logic, it exposes, through
> public methods, all available actions.
> - Module GUI provides all interface options, top components, dialogs,
> actions, and so on. It must access the CatalogEngine class, inside the
> module Catalog, in order to send user input and request all the data
> to display.
> - Module GUI depends on Module Catalog, that in turn depends on some
> other modules that wrap various libraries I need.
>
> I have tried to look for an instance of the class CatalogEngine, the
> lives inside the Catalog module, in one of my TopComponent's subclass,
> that lives inside the GUI module. I tried that because I read
> somewhere, either in the wiki or the API docs, that I could pass an
> Interface or a Class, but I always get null.
> I have tried to get the instance in various places, an installer class
> on the GUI module, various constructors for classes inside the GUI
> module. The result is always null.
>

It sounds to me like you have a misunderstanding of the way lookup works. I might be wrong, and
maybe you are not trying to use Lookup to find an instance of CatalogEngine, but it  sounds to me
you are expecting CatalogEngine to be mystically put into the Lookup.

Some how you have to make your module put this class in the Lookup. You can do this different
ways, but a couple of workable solutions:

1) use InstanceContent as the data for your Lookup and either expose it directly to your modules
classes which will be manipulating or hide it behind some methods.

2) use the layer file system and then use Lookups.forPath. See:
http://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/doc-files/api.html#folderlookup

for more information, but it works well, and you can get really flexible with this as well.
Notice what happens if those instances are assignable to Lookup...they are also proxied in Lookup
calls. So, you can get real powerful there building your own layer API for looking up content and
getting it into lookups.

Anyways, I'm inferring that you are having problems centered around not being able to get your
instance into the lookups you are looking for them in, and this is how. If I'm wrong, then sorry
for misunderstanding.

You have to provide the lookup which you are accessing. In the case of option 2 above you aren't
necessarily providing Lookup as much as you are asking for one to be created from a hierarchy on
your behalf which may actually contain other Lookup instances which can also be proxied in your
calls.

Wade


==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org

[Sergio Lopes-3]

I'm really not understanding this, it doesn't look difficult but
somehow I'm not getting this thing to work.
I hadn't seen that page, thanks for the link, but I can't even make
the simplest way work.

I haded the following code to the layer.xml file in the Catalog module
in order to load the CatalogEngine class it contains:

<file name="de-berlios-jfindmyfiles-catalog-CatalogEngine.instance">
    <attr name="instanceClass"
stringvalue="de.berlios.jfindmyfiles.catalog.CatalogEngine"/>
</file>

That doesn't work :(, I tried adding a file with the class name and
the minus sign but even that doesn't create an instance in the lookup.

>  It sounds to me like you have a misunderstanding of the way lookup works. I might be wrong, and
>  maybe you are not trying to use Lookup to find an instance of CatalogEngine, but it  sounds to me
>  you are expecting CatalogEngine to be mystically put into the Lookup.
I don't want it to magically be there, I want to know how to put it
there and understand how this works :D
I don't understand this, and to make things worse it looks like it's
quite simple!

--
Sem mais e com os melhores cumprimentos,

Sérgio Lopes

[Wade Chandler]

--- Sergio Lopes <knitter.is@...> wrote:

> I'm really not understanding this, it doesn't look difficult but
> somehow I'm not getting this thing to work.
> I hadn't seen that page, thanks for the link, but I can't even make
> the simplest way work.
>
> I haded the following code to the layer.xml file in the Catalog module
> in order to load the CatalogEngine class it contains:
>
> <file name="de-berlios-jfindmyfiles-catalog-CatalogEngine.instance">
>     <attr name="instanceClass"
> stringvalue="de.berlios.jfindmyfiles.catalog.CatalogEngine"/>
> </file>
>
> That doesn't work :(, I tried adding a file with the class name and
> the minus sign but even that doesn't create an instance in the lookup.
>

Sergio,

Can you attach your layer.xml file? I'll have a look at it. Do you have a folder defined?

Wade

==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org

[Sergio Lopes-3]

>  Can you attach your layer.xml file? I'll have a look at it. Do you have a folder defined?
File is not that big, though I believe you must have better things to
do than look at my code ;)
These are the two variations I tried following the documentation
<filesystem>
    <folder name="CatalogEngine">
        <file name="de-berlios-jfindmyfiles-catalog-CatalogEngine.instance">
            <attr name="instanceClass"
stringvalue="de.berlios.jfindmyfiles.catalog.CatalogEngine"/>
        </file>
    </folder>
</filesystem>

or

<filesystem>
    <file name="de-berlios-jfindmyfiles-catalog-CatalogEngine.instance">
        <attr name="instanceClass"
stringvalue="de.berlios.jfindmyfiles.catalog.CatalogEngine"/>
    </file>
</filesystem>

This is on the layer file of the Catalog module, I'm trying to look
for the instance on the GUI module.

--
Sem mais e com os melhores cumprimentos,

Sérgio Lopes

[Wade Chandler]

--- Sergio Lopes <knitter.is@...> wrote:
> >  Can you attach your layer.xml file? I'll have a look at it. Do you have a folder defined?
> File is not that big, though I believe you must have better things to
> do than look at my code ;)

Sure, I have a lot to do, but I think once I show you this you'll have it down, and I won't have
to explain the whole thing to you again. You can start playing around with this stuff and help
some others when they ask ;-).

> These are the two variations I tried following the documentation
> <filesystem>
>     <folder name="CatalogEngine">
>         <file name="de-berlios-jfindmyfiles-catalog-CatalogEngine.instance">
>             <attr name="instanceClass"
> stringvalue="de.berlios.jfindmyfiles.catalog.CatalogEngine"/>
>         </file>
>     </folder>
> </filesystem>
>

This should work fine, though you might want to include some uniqueness in the name such as

<folder name="com-yourdomain-CatalogEngine">

just in case others have modules you want to use which might have a CatalogEngine of some kind
using the same name. You'd know more about your application and what you are using.

Also note that

<file name="de-berlios-jfindmyfiles-catalog-CatalogEngine.instance"/>

is all you need in this case. The instance attribute stuff is so you could just have the name be
"CatalogEngine" or "CatalogEngineImpl" and not worry about the .instance. The files with a name
ending in .instance are instantiated. The .instance on the end is a command to NB.


> or
>
> <filesystem>
>     <file name="de-berlios-jfindmyfiles-catalog-CatalogEngine.instance">
>         <attr name="instanceClass"
> stringvalue="de.berlios.jfindmyfiles.catalog.CatalogEngine"/>
>     </file>
> </filesystem>
>

Now, you can make this work, but it is going to be a big lookup including "everything" from the
system...and I mean more than the default lookup as the default is based on META-INF/services.

> This is on the layer file of the Catalog module, I'm trying to look
> for the instance on the GUI module.
>

Sure, I think now we need to look at the code where you are creating your Lookup. It should be
like this for the entry above with the folder:

Lookup lu = Lookups.forPath("/CatalogEngine");
CatalogEngine ce = lu.lookup(CatalogEngine.class);

and for the one with no folder:

Lookup lu = Lookups.forPath("/");
CatalogEngine ce = lu.lookup(CatalogEngine.class);

Just be sure and store this Lookup off some where. That way when you need to use it you can use
it without having to recreate the entire thing over and over. Then as data changes in your folder
you can have different instances etc changed in your lookup without having to create the whole
thing again.

If you want to have the idea of a merged set of CatalogEngines then you can name your folder
CatalogEngines and loop over each one looking to see if one contains what you are trying to find.
You would use Lookup.lookupResult or lookupAll for this.

Anyways, if this doesn't get you going let me know, but remember what Tom was telling you about
interfaces. With Lookup you can have a folder or tree with instances inside it and have things
implement interfaces so you can change out the implementation or as I said with CatalogEngine
have multiple ones which you can query...this would work sort of like the JDBC connection manager
or the NB editor and data loader stuff.

Wade


==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org

[Paul Richardson-2]

Hi,

Is this the same as inserting an interface into META-INF/services?

Currently, we have been developing by doing the following:
Module A
/src/package1/IEngineHolder (interface)

Module B (depends on Module A)
/src/package4/EngineHolderImpl (implements IEngineHolder)
/META-INF/services/package1.IEngineHolder (text file with path to
EngineHolderImpl inside it)

Module C - uses getLookup().getDefault().lookup (new
Template(IEngineHolder);

Rereading the below post it would seem that use the layer.xml is
quicker? Is this the case?

Any info appreciated.

Regards

Paul

-----Original Message-----
From: Wade Chandler [mailto:hwadechandler-nb@...]
Sent: 13 May 2008 15:34
To: dev@...
Subject: Re: [openide-dev] Best way to share object instances between
modules?

--- Sergio Lopes <knitter.is@...> wrote:
> >  Can you attach your layer.xml file? I'll have a look at it. Do you
have a folder defined?
> File is not that big, though I believe you must have better things to
> do than look at my code ;)

Sure, I have a lot to do, but I think once I show you this you'll have
it down, and I won't have to explain the whole thing to you again. You
can start playing around with this stuff and help some others when they
ask ;-).

> These are the two variations I tried following the documentation
> <filesystem>
>     <folder name="CatalogEngine">
>         <file
name="de-berlios-jfindmyfiles-catalog-CatalogEngine.instance">
>             <attr name="instanceClass"
> stringvalue="de.berlios.jfindmyfiles.catalog.CatalogEngine"/>
>         </file>
>     </folder>
> </filesystem>
>

This should work fine, though you might want to include some uniqueness
in the name such as

<folder name="com-yourdomain-CatalogEngine">

just in case others have modules you want to use which might have a
CatalogEngine of some kind using the same name. You'd know more about
your application and what you are using.

Also note that

<file name="de-berlios-jfindmyfiles-catalog-CatalogEngine.instance"/>

is all you need in this case. The instance attribute stuff is so you
could just have the name be "CatalogEngine" or "CatalogEngineImpl" and
not worry about the .instance. The files with a name ending in .instance
are instantiated. The .instance on the end is a command to NB.


> or
>
> <filesystem>
>     <file
name="de-berlios-jfindmyfiles-catalog-CatalogEngine.instance">
>         <attr name="instanceClass"
> stringvalue="de.berlios.jfindmyfiles.catalog.CatalogEngine"/>
>     </file>
> </filesystem>
>

Now, you can make this work, but it is going to be a big lookup
including "everything" from the system...and I mean more than the
default lookup as the default is based on META-INF/services.

> This is on the layer file of the Catalog module, I'm trying to look
> for the instance on the GUI module.
>

Sure, I think now we need to look at the code where you are creating
your Lookup. It should be like this for the entry above with the folder:

Lookup lu = Lookups.forPath("/CatalogEngine");
CatalogEngine ce = lu.lookup(CatalogEngine.class);

and for the one with no folder:

Lookup lu = Lookups.forPath("/");
CatalogEngine ce = lu.lookup(CatalogEngine.class);

Just be sure and store this Lookup off some where. That way when you
need to use it you can use it without having to recreate the entire
thing over and over. Then as data changes in your folder you can have
different instances etc changed in your lookup without having to create
the whole thing again.

If you want to have the idea of a merged set of CatalogEngines then you
can name your folder CatalogEngines and loop over each one looking to
see if one contains what you are trying to find.
You would use Lookup.lookupResult or lookupAll for this.

Anyways, if this doesn't get you going let me know, but remember what
Tom was telling you about interfaces. With Lookup you can have a folder
or tree with instances inside it and have things implement interfaces so
you can change out the implementation or as I said with CatalogEngine
have multiple ones which you can query...this would work sort of like
the JDBC connection manager or the NB editor and data loader stuff.

Wade


==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner,
NetBeans Dream Team Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org

______________________________________________________
Reg. Office: VEGA Group PLC, 2 Falcon Way, Shire Park, Welwyn Garden City, Herts AL7 1TW, UK

Registered in England, Number 1393778
______________________________________________________

[Wade Chandler]

--- Paul Richardson <Paul.Richardson@...> wrote:

> Hi,
>
> Is this the same as inserting an interface into META-INF/services?
>
> Currently, we have been developing by doing the following:
> Module A
> /src/package1/IEngineHolder (interface)
>
> Module B (depends on Module A)
> /src/package4/EngineHolderImpl (implements IEngineHolder)
> /META-INF/services/package1.IEngineHolder (text file with path to
> EngineHolderImpl inside it)
>
> Module C - uses getLookup().getDefault().lookup (new
> Template(IEngineHolder);
>
> Rereading the below post it would seem that use the layer.xml is
> quicker? Is this the case?
>
> Any info appreciated.
>

It really depends on what you are trying to do. I would imagine the default lookup for all
services lookup would be slower than a single folder or a
Lookups.metaInfServices(YourModuleInstall.class.getClassLoader()) call would be, but not enough
to matter.

For instance, a services lookup using a metaInfServices lookup based on your modules classes
class loader is only going to examine the classpath which your module actually uses. If you use
the default then it will use all the main class loader and thus examine all services.

In the case of a folder lookup it will only examine instances created through that folder in the
layer, so again, it will be limited in scope, and thus should be faster/quicker, but remember,
faster is relative to the initial load of the lookup; so mainly concerned with initialization
time. The rest of a speed and time analysis will mostly break down along hash and index lookup
times which are relatively fast no matter the size per the way buckets are used...see:
http://en.wikipedia.org/wiki/Hash_table

and any proxy lookup calls.

The thing to keep in mind from my perspective is memory usage. The default lookup is going to be
used at some point whether you use it directly or not as it is a common API. However, creating
one from the path of "/" is different than what the default lookup does as the default is
narrowed to META-INF/services where as "/" will create a new lookup which will include all the
instances.

Wade


==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org

[Casper Bang]

Does anyone know how I can programatically obtain the color of a given
Java token, used within the NetBeans editor? I suppose it has to do with
LexerEditorKit, but my attempts at getting the colors out have not been
successful.

Any help greatly appreciated,
/Casper

[Emilian Bold]

FontColorSettings fcs = (FontColorSettings)
((MimeDataProvider)Lookup.getDefault().lookup(MimeDataProvider.class)).getLookup(MimePath.get("text/java")).lookup(FontColorSettings.class);

Color color = (Color)fcs.getTokenFontColors("KEYWORD").getAttribute(StyleConstants.Background)

Emilian

On Tue, May 13, 2008 at 10:40 PM, Casper Bang <casper@...> wrote:
> Does anyone know how I can programatically obtain the color of a given Java
> token, used within the NetBeans editor? I suppose it has to do with
> LexerEditorKit, but my attempts at getting the colors out have not been
> successful.
>
>  Any help greatly appreciated,
>  /Casper
>



--
Emilian Bold
[phone]
http://www.emilianbold.ro

Java and NetBeans Platform-loving consulting services from Timisoara, Romania.

[Casper Bang]

Whoa that's a whole lot of indirection, would've never figured that out.
Thanks! :)

/Casper

Emilian Bold wrote:

> FontColorSettings fcs = (FontColorSettings)
> ((MimeDataProvider)Lookup.getDefault().lookup(MimeDataProvider.class)).getLookup(MimePath.get("text/java")).lookup(FontColorSettings.class);
>
> Color color = (Color)fcs.getTokenFontColors("KEYWORD").getAttribute(StyleConstants.Background)
>
> Emilian
>
> On Tue, May 13, 2008 at 10:40 PM, Casper Bang <casper@...> wrote:
>  
>> Does anyone know how I can programatically obtain the color of a given Java
>> token, used within the NetBeans editor? I suppose it has to do with
>> LexerEditorKit, but my attempts at getting the colors out have not been
>> successful.
>>
>>  Any help greatly appreciated,
>>  /Casper
>>
>>    
>
>
>
>  

[Paul Richardson-2]

> -----Original Message-----
> From: Wade Chandler [mailto:hwadechandler-nb@...]
> Sent: 13 May 2008 18:46
> To: dev@...
> Subject: RE: [openide-dev] Best way to share object instances
> between modules?
>
> --- Paul Richardson <Paul.Richardson@...> wrote:
> > Hi,
> >
> > Is this the same as inserting an interface into META-INF/services?
> >
> > Currently, we have been developing by doing the following:
> > Module A
> > /src/package1/IEngineHolder (interface)
> >
> > Module B (depends on Module A)
> > /src/package4/EngineHolderImpl (implements IEngineHolder)
> > /META-INF/services/package1.IEngineHolder (text file with path to
> > EngineHolderImpl inside it)
> >
> > Module C - uses getLookup().getDefault().lookup (new
> > Template(IEngineHolder);
> >
> > Rereading the below post it would seem that use the layer.xml is
> > quicker? Is this the case?
> >
> > Any info appreciated.
> >
>
> It really depends on what you are trying to do. I would
> imagine the default lookup for all services lookup would be
> slower than a single folder or a
> Lookups.metaInfServices(YourModuleInstall.class.getClassLoader
> ()) call would be, but not enough to matter.
>
> For instance, a services lookup using a metaInfServices
> lookup based on your modules classes class loader is only
> going to examine the classpath which your module actually
> uses. If you use the default then it will use all the main
> class loader and thus examine all services.
>
> In the case of a folder lookup it will only examine instances
> created through that folder in the layer, so again, it will
> be limited in scope, and thus should be faster/quicker, but
> remember, faster is relative to the initial load of the
> lookup; so mainly concerned with initialization time. The
> rest of a speed and time analysis will mostly break down
> along hash and index lookup times which are relatively fast
> no matter the size per the way buckets are used...see:
> http://en.wikipedia.org/wiki/Hash_table
>
> and any proxy lookup calls.
>
> The thing to keep in mind from my perspective is memory
> usage. The default lookup is going to be used at some point
> whether you use it directly or not as it is a common API.
> However, creating one from the path of "/" is different than
> what the default lookup does as the default is narrowed to
> META-INF/services where as "/" will create a new lookup which
> will include all the instances.
>
> Wade
>

Cheers Wade, nice and comprehensive.

Regards

PGR

______________________________________________________
Reg. Office: VEGA Group PLC, 2 Falcon Way, Shire Park, Welwyn Garden City, Herts AL7 1TW, UK

Registered in England, Number 1393778
______________________________________________________

[Casper Bang]

How would one generally go about accessing the semantics of Java code,
inside NetBeans. Through org.netbeans.api.lexer I can uptain full access
to the tokens, but at a very rudimentary level, i.e. no way to
distinguish whether an IDENTIFIER is local or member-wide. I'd rather
avoid parsing manually over the tokens and would expect there to be
*something* already I can use in NetBeans?!

Thanks in advance,
Casper