Unfortunately, I tried removing the replace('$',".") and it failed
miserably. Looking at it in the debugger, those really are binary names.
e.g.:
com.google.gwt.core.client.impl.AsyncFragmentLoader$LoadingStrategy
On Thu, May 26, 2011 at 2:24 PM, John Tamplin <[email protected]> wrote:
> On Thu, May 26, 2011 at 2:03 PM, Grzegorz Kossakowski <
> [email protected]> wrote:
>
>> > The problematic place for me is ReplaceBindings.java, lines 154-155:
>> >
>> > // Rebinds are always on a source type name.
>> > String reqType = type.getName().replace('$', '.');
>>
>> Any comment on that one? Working-around it is possible but quite
>> involved. I'd love to know if I need some solid work-around or just
>> hack to keep me going because this will be removed upstream.
>
>
> There is a common place for these in c.g.g.dev.util.Name, that provides
> all the conversions between different name types. So, this should be:
>
> String reqType = Name.BinaryName.toSourceName(type.getName())
>
> However, that doesn't solve your problem.
>
> The main problem is that once you get to a binary class name as a string,
> you can no longer distinguish these cases. You would have to have package,
> enclosing class, and class broken out separately in order to do anything
> more useful with this, or at least have an oracle of possible classes you
> can look up (though that would still fail if A.B and A$B were both present).
> JReferenceType just takes a single string, so you can't get that
> information.
>
> However, I think in this case there is no need to replace $, since despite
> the lack of documentation I believe type.getName() is actually a source name
> (we have been really sloppy with the 3 types of names - a year or two ago I
> started to rewrite it all with type-safe wrappers but that was rejected
> because it dramatically increased memory usage in the compiler). For
> example, if you look at ReferenceMapper.createType, it takes a JDT
> ReferenceBinding.compoundName and creates the names by simply joining the
> components with dots. My guess is if you simply remove the .replace from
> that line, it will work fine (and in fact is removing a bug). I wouldn't
> get your hopes up that that is the last time you will run into a problem,
> because anyplace that calls Name.isSourceName, for example, will fail on a
> class name with an embedded $.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
--
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
