felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Baum (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FELIX-2927) [gogo] coercion mechanism invokes foo(String) instead of foo(int) - even with explicit int argument
Date Thu, 21 Apr 2011 12:58:05 GMT
[gogo] coercion mechanism invokes foo(String) instead of foo(int) - even with explicit int
argument
---------------------------------------------------------------------------------------------------

                 Key: FELIX-2927
                 URL: https://issues.apache.org/jira/browse/FELIX-2927
             Project: Felix
          Issue Type: Bug
          Components: Gogo Runtime
    Affects Versions: gogo.runtime-0.8.0
            Reporter: Derek Baum
            Assignee: Derek Baum


Equinox 3.7.M6 supports OSGi R4.3 which adds the overloaded method BundleContext.getBundle(String).

This causes gogo startup to fail, as it expects to invoke getBundle(int) but actually invokes
getBundle(String).

Prior to R4.3, the gogo command: bundle 1
resulted in the String "1" being coerced into a long, so that getBundle(long) could be invoked.

Now that getBundle(String) exists, the result depends on the order that methods are returned
from Class.getMethods(), which varies between platforms:

On Mac java version "1.6.0_24":

g! type bundle
bundle is Bundle context:bundle(long)
bundle is Bundle context:bundle()
bundle is Bundle context:bundle(String)


On Windows 2003 server, java version "1.6.0_24":
g! type bundle
bundle is Bundle context:bundle()
bundle is Bundle context:bundle(String)
bundle is Bundle context:bundle(long)

The first "exact" match wins, where "exact" just means that all supplied arguments are used.
On the Mac, getBundle(long) still wins, but on Windows getBundle(String) wins and the gogo
startup scripts fails.

What's worse, is that even when you realise what is happening, it is still not possible to
invoke getBundle(long):

g! 1L = new Long 1
g! bundle $1L

because in this case the long is coerced to a String to invoke get Bundle(String) and the
getBundle(long) method is ignored.


There are at least two problems here:

1. the gogo coercion mechanism simply invokes the first method it can, regardless of whether
any arguments needed to be converted.

It should instead try to score each method, perhaps adding to the score each time an argument
needs to be converted,
then it could invoke the method with the lowest score.
However, there may still be occasions when two methods have the same score and gogo needs
to behave deterministically
and allow either method to be invoked by supplying less ambiguous arguments.

2. all arguments in gogo start out as Strings, which make it awkward to prefer a method that
takes an integer:
for example: g! bundle (new Long 1)

getBundle(long) is the most likely target method, but gogo does not any syntax to indicate
that arguments should be treated as numbers rather than Strings. One possibility would be
to recognize numbers in gogo's Tokenizer similar to the way that true/false are handled:

g! t = true
true
g! tt = 'true'
true
g! set t
Boolean       t               true
String          tt              true

The above shows that the bare word: true is tokenized as a Boolean, where as the quoted word
'true' is tokenized as a String.
So bare numbers could be tokenized as Numbers, and the existing coercion mechanism would convert
them back to Strings as needed;
alternative by quoting something that looks like a number, you force it to be tokenized as
a String.















--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message