[
https://issues.apache.org/jira/browse/FELIX-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-2927.
-------------------------------
Resolution: Fixed
Fix Version/s: gogo.runtime-0.10.0
fixed by refactoring Reflective.java to give conversion cost for coercion.
> [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
> Fix For: gogo.runtime-0.10.0
>
>
> 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
