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
[gwt-contrib] Dollar sign and binary types
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
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