Reviewers: conroy,
Description:
Using cached ZipFileClassPathEntry objects.
While this does not give benefits for DevMode, which parses jar files
only once, GWT Designer does this many times.
This gives about 15% speed up in GWT Designer.
Initial.
-
Parsing...done: 4775
refresh:
On 2011/03/20 04:45:50, fredsa wrote:
LGTM
http://gwt-code-reviews.appspot.com/1383805/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
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):
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
http://gwt-code-reviews.appspot.com/1375802/diff/9001/dev/core/src/com/google/gwt/dev/javac/PersistentUnitCache.java
File dev/core/src/com/google/gwt/dev/javac/PersistentUnitCache.java
(right):
DevMode uses single top level ModuleDef with single set of jars.
GWT Designer can open several editors with several top level ModuleDefs,
which use several may be different sets of jars, but with many
intersections.
If only we could have hashCode() and equals() for PathPrefixSet... This
would
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):
