Re: [gwt-contrib] Dollar sign and binary types
On Sat, May 28, 2011 at 3:41 PM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: I cannot comment on your proposals because I don't know gwt internals enough. I decided to add a method to TypeOracle that allows me to ask if given type comes from Java or Jribble. If it's Jribble I don't try to do any conversions. This is ugly and fragile method but seems to be the only viable strategy for now. If you guys can come up with systematic solution to this problem it would be awesome. Use an annotation. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
2011/5/29 Scott Blum sco...@google.com On Sat, May 28, 2011 at 3:41 PM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: I cannot comment on your proposals because I don't know gwt internals enough. I decided to add a method to TypeOracle that allows me to ask if given type comes from Java or Jribble. If it's Jribble I don't try to do any conversions. This is ugly and fragile method but seems to be the only viable strategy for now. If you guys can come up with systematic solution to this problem it would be awesome. Use an annotation. You mean putting annotation to every Jribble type? How that would help? Also, I thought you'd enjoy this question: http://stackoverflow.com/questions/6167326/java-class-name-containing-dollar-sign Seems like javac can confuse itself about dollar sign, sigh. -- Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
You wouldn't have to hack TypeOracle. You could just look for your particular annotation to see what was a Jribble type. On Sun, May 29, 2011 at 1:47 PM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: 2011/5/29 Scott Blum sco...@google.com On Sat, May 28, 2011 at 3:41 PM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: I cannot comment on your proposals because I don't know gwt internals enough. I decided to add a method to TypeOracle that allows me to ask if given type comes from Java or Jribble. If it's Jribble I don't try to do any conversions. This is ugly and fragile method but seems to be the only viable strategy for now. If you guys can come up with systematic solution to this problem it would be awesome. Use an annotation. You mean putting annotation to every Jribble type? How that would help? Also, I thought you'd enjoy this question: http://stackoverflow.com/questions/6167326/java-class-name-containing-dollar-sign Seems like javac can confuse itself about dollar sign, sigh. -- Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
2011/5/29 Scott Blum sco...@google.com You wouldn't have to hack TypeOracle. You could just look for your particular annotation to see what was a Jribble type. The problem is that TypeOracle itself doesn't work well with types containing dollar sign so I truly need to hack it. Also, there seem to be other places in GWT code (Rebindings come to my mind) where dollar signs are problematic. What I'm doing right now is pure experimentation and hacks I'm introducing won't be kept even temporarily. I'm just trying to get bigger picture of what kind of changes will need to be applied in order to fully support Jribble. Once I gather enough of information I'll try to write some report and let you comment on it as I expect many things to be misunderstood on my side. This won't happen sonner than in two weeks, though. -- Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
2011/5/27 Scott Blum sco...@google.com The compiler internals could be coded to use binary names. Obviously, generators would do something sensible. For example, I know that rebind rules in gwt.xml are tracked by source name. Well, those could get looked up in TypeOracle and translated to the appropriate binary name and tracked that way. You would always to one-way conversions from source-binary and never back. I cannot comment on your proposals because I don't know gwt internals enough. I decided to add a method to TypeOracle that allows me to ask if given type comes from Java or Jribble. If it's Jribble I don't try to do any conversions. This is ugly and fragile method but seems to be the only viable strategy for now. If you guys can come up with systematic solution to this problem it would be awesome. -- Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
2011/5/26 Eric Ayers zun...@google.com:
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
Thanks guys for you answers. I moved on with my work-around. It would
be great if those binary names were converted to source names as soon
as possible so number of places in gwt code where we have to consider
both options is minimized.
--
Grzegorz Kossakowski
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
On Fri, May 27, 2011 at 4:45 AM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
2011/5/26 Eric Ayers zun...@google.com:
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
Thanks guys for you answers. I moved on with my work-around. It would
be great if those binary names were converted to source names as soon
as possible so number of places in gwt code where we have to consider
both options is minimized.
The problem is conversion to source names is lossy -- given Foo.Bar.Baz, you
don't know where the split between the package name, enclosing class name,
and class name is (compare to Foo/Bar$Baz and Foo/Bar/Baz). I think the
only way you could avoid this problem is if you kept a structured type with
those pieces of information rather than a simple string, but that would be
expensive in terms of allocating several additional objects for every class
name in the program, plus many uses don't care about the distinctions and
just wand the source name.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
What John said. Blame Java for the fact that with some lookup oracle, it's
impossible to distinguish the cases. We've always assumed that users would
not use '$' in class names in places where it matters.
That being said, let's assume that a user isn't allowed to have both A.B and
A$B like Toby said, as the binary names would collide. Given that, I
*think* the only place source type name really matters is resolving rebind
requests and results. So maybe it's possible we could use only binary name
or internal name everywhere and move away from using source name except in
output messages.
On Fri, May 27, 2011 at 9:50 AM, John Tamplin j...@google.com wrote:
On Fri, May 27, 2011 at 4:45 AM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
2011/5/26 Eric Ayers zun...@google.com:
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
Thanks guys for you answers. I moved on with my work-around. It would
be great if those binary names were converted to source names as soon
as possible so number of places in gwt code where we have to consider
both options is minimized.
The problem is conversion to source names is lossy -- given Foo.Bar.Baz,
you don't know where the split between the package name, enclosing class
name, and class name is (compare to Foo/Bar$Baz and Foo/Bar/Baz). I think
the only way you could avoid this problem is if you kept a structured type
with those pieces of information rather than a simple string, but that would
be expensive in terms of allocating several additional objects for every
class name in the program, plus many uses don't care about the distinctions
and just wand the source name.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
On Fri, May 27, 2011 at 10:03 AM, Scott Blum sco...@google.com wrote: What John said. Blame Java for the fact that with some lookup oracle, it's impossible to distinguish the cases. We've always assumed that users would not use '$' in class names in places where it matters. That being said, let's assume that a user isn't allowed to have both A.B and A$B like Toby said, as the binary names would collide. Given that, I *think* the only place source type name really matters is resolving rebind requests and results. So maybe it's possible we could use only binary name or internal name everywhere and move away from using source name except in output messages. I don't think that solves the problem -- let's say we store Foo/Bar$Baz internally and convert it to a source name where needed. How do we know whether the class name is Bar$Baz or Baz inside of Bar? The problem is simply if you allow $ in a class name, binary and internal names are lossy too as they no longer encode the difference. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
On Fri, May 27, 2011 at 10:12 AM, John Tamplin j...@google.com wrote: I don't think that solves the problem -- let's say we store Foo/Bar$Baz internally and convert it to a source name where needed. How do we know whether the class name is Bar$Baz or Baz inside of Bar? The problem is simply if you allow $ in a class name, binary and internal names are lossy too as they no longer encode the difference. My point is to NOT convert it to source names, do everything in binary. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
On Fri, May 27, 2011 at 12:53 PM, Scott Blum sco...@google.com wrote: On Fri, May 27, 2011 at 10:12 AM, John Tamplin j...@google.com wrote: I don't think that solves the problem -- let's say we store Foo/Bar$Baz internally and convert it to a source name where needed. How do we know whether the class name is Bar$Baz or Baz inside of Bar? The problem is simply if you allow $ in a class name, binary and internal names are lossy too as they no longer encode the difference. My point is to NOT convert it to source names, do everything in binary. So when you generate source code, how do you do that? Or let's just say you want to get the simple class name -- in the example, is it Bar$Baz or Baz? The point is you don't have the information necessary to tell. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
The compiler internals could be coded to use binary names. Obviously, generators would do something sensible. For example, I know that rebind rules in gwt.xml are tracked by source name. Well, those could get looked up in TypeOracle and translated to the appropriate binary name and tracked that way. You would always to one-way conversions from source-binary and never back. On Fri, May 27, 2011 at 1:01 PM, John Tamplin j...@google.com wrote: On Fri, May 27, 2011 at 12:53 PM, Scott Blum sco...@google.com wrote: On Fri, May 27, 2011 at 10:12 AM, John Tamplin j...@google.com wrote: I don't think that solves the problem -- let's say we store Foo/Bar$Baz internally and convert it to a source name where needed. How do we know whether the class name is Bar$Baz or Baz inside of Bar? The problem is simply if you allow $ in a class name, binary and internal names are lossy too as they no longer encode the difference. My point is to NOT convert it to source names, do everything in binary. So when you generate source code, how do you do that? Or let's just say you want to get the simple class name -- in the example, is it Bar$Baz or Baz? The point is you don't have the information necessary to tell. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
2011/5/26 Grzegorz Kossakowski grzegorz.kossakow...@gmail.com:
2011/5/26 Eric Ayers zun...@google.com:
Hi again,
Can you point out any of places where you saw this assumption? The
last time I was mucking around with binary type names I was told not
to assume that $ could not appear in source names, so it might be
unintentional.
Hi Eric,
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.
--
Grzegorz Kossakowski
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
On Thu, May 26, 2011 at 2:03 PM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com 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
Re: [gwt-contrib] Dollar sign and binary types
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 j...@google.com wrote:
On Thu, May 26, 2011 at 2:03 PM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com 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
Re: [gwt-contrib] Dollar sign and binary types
Hi again,
Can you point out any of places where you saw this assumption? The
last time I was mucking around with binary type names I was told not
to assume that $ could not appear in source names, so it might be
unintentional.
-Eric.
On Wed, May 25, 2011 at 5:51 PM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
Hi,
Poking around a bit more I found that gwtc seems to assume internally
that whenever type name contains '$' it's in binary form and if it
doesn't contain dollar sign then it can be considered to be in source
form. It's worth noting (and it's admitted in gwtc's internals) that
this condition doesn't split of all type names into disjoint union of
two respective sets.
Anyway, my question is: how much of gwt internals rely on this
distinction? I noticed that gwtc is doing handful number of
conversions between those two forms. This is particularly problematic
for my work because jribble can have dollar sign in it's type name and
this would be extremely hard to change.
Also, it looks like Java allows type names containing dollar sign:
mac-grek:javajunk grek$ echo 'class A$B {}' A\$B.java
mac-grek:javajunk grek$ javac 'A$B.java'
mac-grek:javajunk grek$ javap 'A$B'
Compiled from A$B.java
class A$B extends java.lang.Object{
A$B();
}
Is gwtc handling those cases in pure java environment properly?
--
Grzegorz Kossakowski
--
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
Re: [gwt-contrib] Dollar sign and binary types
On Wed, May 25, 2011 at 5:51 PM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
Hi,
Poking around a bit more I found that gwtc seems to assume internally
that whenever type name contains '$' it's in binary form and if it
doesn't contain dollar sign then it can be considered to be in source
form. It's worth noting (and it's admitted in gwtc's internals) that
this condition doesn't split of all type names into disjoint union of
two respective sets.
Anyway, my question is: how much of gwt internals rely on this
distinction? I noticed that gwtc is doing handful number of
conversions between those two forms. This is particularly problematic
for my work because jribble can have dollar sign in it's type name and
this would be extremely hard to change.
Also, it looks like Java allows type names containing dollar sign:
mac-grek:javajunk grek$ echo 'class A$B {}' A\$B.java
mac-grek:javajunk grek$ javac 'A$B.java'
mac-grek:javajunk grek$ javap 'A$B'
Compiled from A$B.java
class A$B extends java.lang.Object{
A$B();
}
FYI, Java does allow '$'s in class names, but IIRC javac can get confused,
for example, if you pipe in two classes into the same compile run:
class A {
static class B {
}
}
class A$B {
}
They're two distinct classes, but happen to have identical names. That said,
I think we generally try to not assign semantic information to '$'s in class
names.
Is gwtc handling those cases in pure java environment properly?
--
Grzegorz Kossakowski
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
