What is the use case here? Normally, a jar file is never re-opened in a java classpath after the first time it is loaded, so I'm not sure I understand what's happening here. Is GWTDesigner generating and overwriting jar files and then reloading them? How has this worked in the past, given that ResourceOracle doesn't reload jar file entries after the first time. In otherwords, I'm not sure I understand the delta here from how it was working before.
Also, it looks like it is changing the behavior of ResourceOracle, since it will now be sensitive to changes in a jar file (whereas it has not been in the past). http://gwt-code-reviews.appspot.com/1388803/diff/1/dev/core/src/com/google/gwt/dev/resource/impl/ZipFileClassPathEntry.java File dev/core/src/com/google/gwt/dev/resource/impl/ZipFileClassPathEntry.java (right): http://gwt-code-reviews.appspot.com/1388803/diff/1/dev/core/src/com/google/gwt/dev/resource/impl/ZipFileClassPathEntry.java#newcode98 dev/core/src/com/google/gwt/dev/resource/impl/ZipFileClassPathEntry.java:98: entryCache.put(location, cachedEntry); It would seem this shouldn't take up more memory than the current implementation, if I understand correctly? It looks like it's keeping track of all ZipFileClassPathEntries and allocating replaced versions if they become stale. I guess the memory hit would be if multiple versions of the same jar file are referenced?). What about multiple threads, does this master entryCache need any synchronization? http://gwt-code-reviews.appspot.com/1388803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
