[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
On 2011/05/03 18:57:36, scottb wrote: I mean only super-sourced. Does Object come through as 'com/google/gwt/emul/java/lang/Object.java' or merely 'java/lang/Object.java'? Sigh.. no. I just got this up in the debugger and saw that RerootedResource re-writes com/google/gwt/emul/java/Util/Collections.java to java/util/Collections.java. http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
I mean only super-sourced. Does Object come through as 'com/google/gwt/emul/java/lang/Object.java' or merely 'java/lang/Object.java'? On Tue, May 3, 2011 at 2:56 PM, wrote: > On 2011/05/03 18:45:15, scottb wrote: > >> LGTM. Like Toby said, this is much better. >> > > Can you confirm that re-rooted resources retain their original >> > (non-rerooted) > >> path location? >> > > What do you mean by re-rooted resources? super sourced resources? One > thing I looked at was that generated resources create their path from > the type name, but I don't think they get re-rooted if what you mean > that is items that have been super sourced. > > > > http://gwt-code-reviews.appspot.com/1428805/ > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
On 2011/05/03 18:45:15, scottb wrote: LGTM. Like Toby said, this is much better. Can you confirm that re-rooted resources retain their original (non-rerooted) path location? What do you mean by re-rooted resources? super sourced resources? One thing I looked at was that generated resources create their path from the type name, but I don't think they get re-rooted if what you mean that is items that have been super sourced. http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
LGTM. Like Toby said, this is much better. Can you confirm that re-rooted resources retain their original (non-rerooted) path location? http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
LGTM Nice change. I like this better. (This failed last time. This might be a duplicate). http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
LGTM Nice change. I like this better. http://gwt-code-reviews.appspot.com/1428805/diff/1/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java File dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java (right): http://gwt-code-reviews.appspot.com/1428805/diff/1/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java#newcode147 dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java:147: try { On 2011/04/30 16:08:28, jbrosenberg wrote: Actually, this won't open the file, it will only parse the URL string, and return the name part, which is the substring after the '!'. It's probably not necessary to construct a JarEntry intermediate value. You can just do connection.getEntryName(). You're right. It's not really obvious that's what's happening though (and I've implemented my own URLConnection and URLStreamHandler). http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
LGTM Nice change. I like this better. http://gwt-code-reviews.appspot.com/1428805/diff/1/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java File dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java (right): http://gwt-code-reviews.appspot.com/1428805/diff/1/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java#newcode147 dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java:147: try { On 2011/04/30 16:08:28, jbrosenberg wrote: Actually, this won't open the file, it will only parse the URL string, and return the name part, which is the substring after the '!'. It's probably not necessary to construct a JarEntry intermediate value. You can just do connection.getEntryName(). You're right. It's not really obvious that's what's happening though (and I've implemented my own URLConnection and URLStreamHandler). http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
LGTM Nice change. I like this better. http://gwt-code-reviews.appspot.com/1428805/diff/1/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java File dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java (right): http://gwt-code-reviews.appspot.com/1428805/diff/1/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java#newcode147 dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java:147: try { On 2011/04/30 16:08:28, jbrosenberg wrote: Actually, this won't open the file, it will only parse the URL string, and return the name part, which is the substring after the '!'. It's probably not necessary to construct a JarEntry intermediate value. You can just do connection.getEntryName(). You're right. It's not really obvious that's what's happening though (and I've implemented my own URLConnection and URLStreamHandler). http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
I should also mention that this makes a follow-on patch to check contentId in case jar file timestamps update a little bit easier when updating the cached unit. http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
I decided to back out the original patch and go with using the output of resource.getPath() as the key for the cache. This should differentiate between source and super-source but not include any special prefixes for .jar files or generated files. http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
LGTM http://gwt-code-reviews.appspot.com/1428805/diff/1/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java File dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java (right): http://gwt-code-reviews.appspot.com/1428805/diff/1/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java#newcode147 dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java:147: try { Actually, this won't open the file, it will only parse the URL string, and return the name part, which is the substring after the '!'. It's probably not necessary to construct a JarEntry intermediate value. You can just do connection.getEntryName(). http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Discards the jar file name in the resource location. It isn't necessary, and (issue1428805)
http://gwt-code-reviews.appspot.com/1428805/diff/1/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java File dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java (right): http://gwt-code-reviews.appspot.com/1428805/diff/1/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java#newcode80 dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java:80: * The key is resource location. Update the doc for the key. http://gwt-code-reviews.appspot.com/1428805/diff/1/dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java#newcode147 dev/core/src/com/google/gwt/dev/javac/MemoryUnitCache.java:147: try { Is there any way to do this cheaper? This seems like a lot of work (opening up a Jar file and getting an entry), for every single cached unit. http://gwt-code-reviews.appspot.com/1428805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors