Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Scout » CODES.getAllCodeTypes(..)
CODES.getAllCodeTypes(..) [message #1038789] Thu, 11 April 2013 10:22 Go to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1252
Registered: October 2011
Senior Member
Hi,

A question about CODES.getAllCodeTypes(..):

Consider 2 codes types class:
* <app: shared plugin name>.services.code.ACodeType;
* somepackage.shared.services.code.BCodeType;

Where <app> is the name of the shared plugin.

Have a look at this code:
    ACodeType acode = CODES.getCodeType(ACodeType.class);
    if (acode != null) {
      System.err.println("ACodeType:ok");
    }
    else {
      System.err.println("ACodeType:null");
    }

    BCodeType bcode = CODES.getCodeType(BCodeType.class);
    if (bcode != null) {
      System.err.println("BCodeType:ok");
    }
    else {
      System.err.println("BCodeType:null");
    }

    ICodeType[] allCodeTypes = CODES.getAllCodeTypes("");
    for (ICodeType c : allCodeTypes) {
      System.err.println("AllCodeType>" + c.getClass().getCanonicalName());
    }


The AllCodeTypes function do not find the BCodeType. See the the console:
ACodeType:ok
BCodeType:ok
AllCodeType>org.eclipsescout.demo.minifigcreator.shared.services.code.ACodeType


This is because of the BundleBrowser call in CodeService (line 154):
BundleBrowser bundleBrowser = new BundleBrowser(bundle.getSymbolicName(), bundle.getSymbolicName());


Do you think this is a bug?
Re: CODES.getAllCodeTypes(..) [message #1038792 is a reply to message #1038789] Thu, 11 April 2013 10:28 Go to previous messageGo to next message
Ivan Motsch is currently offline Ivan MotschFriend
Messages: 154
Registered: March 2010
Senior Member
No bug.
CODES.getAllCodeTypes() is a convenience wrapper for ICodeService.getAllCodeTypes().

And the default scout implemementation CodeService.getAllCodeTypes() contains a default implementation that tries to optimize the trade-off between expensive full-code spidering and best coding practice.

However i would recommend to use a custom CodeService in such cases that subclass scout CodeService or fully implement ICodeService.
This is also useful to adapt code caching and discovery needs to the project needs.
Re: CODES.getAllCodeTypes(..) [message #1039394 is a reply to message #1038792] Fri, 12 April 2013 05:45 Go to previous messageGo to next message
Beat Schwarzentrub is currently offline Beat SchwarzentrubFriend
Messages: 202
Registered: November 2010
Senior Member
I do not quite agree. The default implementation's intention is surely good (speed!), but if you are not aware of the behaviour you can easly spend lots of time debugging your code... I think the least one could have expected is, that this "tweak" is documented. All I could find (Scout 3.8 ) is the JavaDoc on ICodeService.getAllCodeTypeClasses(classPrefix) that says "returns all codetype classes from bundles with classPrefix". This clearly does not hold for the default implementation when you pass "" as classPrefix.

Besides, how much of a performance boost is it really? Can we really save time by not looking at classes that do not start with the bundle symbolic name? (Especially if you follow the convention to always prefix your classes with the BSN.)

If I missed something here, please comment.

Beat
Re: CODES.getAllCodeTypes(..) [message #1042215 is a reply to message #1039394] Tue, 16 April 2013 06:05 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1252
Registered: October 2011
Senior Member
What do we need to do?
Update the Javadoc? Fix the code?

I had a discussion about performance:
I you want to boost your startup time, you can filter the bundle in your CodeService (by filtering all the bundle where you are sure there is no CodeType).
Re: CODES.getAllCodeTypes(..) [message #1048333 is a reply to message #1042215] Wed, 24 April 2013 10:16 Go to previous messageGo to next message
Ivan Motsch is currently offline Ivan MotschFriend
Messages: 154
Registered: March 2010
Senior Member
Thanks for the comments. Good points.
However in order to help I need at least a proposals for a change or a javadoc enhancement.
Otherwise it will stay as is (see post from Thu, 11 April 2013 12:28)
Maybe the javadoc enhancement would be a good point to start.
If agreed, please create a bugzilla with specific content.
Re: CODES.getAllCodeTypes(..) [message #1048629 is a reply to message #1048333] Wed, 24 April 2013 18:52 Go to previous message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1252
Registered: October 2011
Senior Member
Imagine the following:

Bundle symbolic name (BSN): com.myapp.shared.core
Code type class:
* com.myapp.shared.core.services.code.CodeType1
* com.myapp.shared.core.services.other.CodeType2
* com.myapp.codes.CodeType3

With the current implementation:

The result of CodeService#getAllCodeType(String) is the same:
* CodeType1 and CodeType2 are found,
* CodeType3 is not found

This is independently from the classPrefix value:
* ""
* "com.myapp"
* "com.myapp.shared.core.services.code"
* "com.myapp.shared.core.services.other"
* "com.myapp.shared.core.nowhere"

Meaning that classPrefix parameter is totally ignored when it comes to look for the CodeType classes.

The contract of the ICodeService#getAllCodeType(String) defined on the interface is not clear. The problem is this classPrefix String parameter. This should be defined independently form the current CodeService implementation (and the optimization choices that have been made there).

We can say:
1. The String parameter is a "context" speeding up the bundle lookup by providing some context (approximate name of the bundle). It can be ignored by the class implementing the Interface. [This is more or less the semantic today]
OR:
2. All the founded classes need to have their absolute name starting with this prefix. [this would be a semantic modification]

Additionally to that, the default CodeType Service makes the choice to implement the contract by ignoring the classes that are not located in a java package that is a subpackage of the BSN (bundle symbolic name). This is acceptable because it is a good practice. We just need to document it properly in order to let people know (and avoiding time lost like for myself).

Can you tell what you think/know? It will help for the redaction of the bug.
Previous Topic:different icons in outline tree
Next Topic:Large RemoteFile
Goto Forum:
  


Current Time: Thu Mar 28 09:49:31 GMT 2024

Powered by FUDForum. Page generated in 0.04701 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top