[wtp-dev] Request PMC approval for 157098 and 158329

[Nitin Dahyabhai <nitind@xxxxxxxxxx>]

I'm requesting review for these two
bugs for 1.5.2:

157098 - [hotbug_request] Repetitive
file I/O by TLDCMDocumentManager$IncludeHelper.getContents() , caching
solution provided, JSP validator slow due to repetitive parsing of fragments
This patch introduces a new internal
JSPFragmentBufferCache for use both by the JSP translator and the JSP model's
custom tag library support.  The new class keeps a string buffer in
memory as long as a model is using it and converts it into a weak
reference so that when using (e.g.
validating) multiple files that all refer to the same fragment, even if
not at the same time, disk I/O is reduced with minimal impact on memory
usage.  It also ensures that each retrieval of a fragment's contents
updates the buffer if the file was modified, so that clients always retrieve
the correct copy of the file's contents when they request it.


158329 - TaglibIndex cache files aren't
read back properly
The TaglibIndex implemented a cache
in 1.5.1 that greatly sped up the startup time by not searching the build
path for tag libraries.  To do this, it wrote out a simple table of
the build path information for each project into a UTF-16 encoded file
within its plugin's metadata folder.  In order to support continuing
development, the cache is ignored if the first line does not match the
current "version" string according to a simple string comparison.
 Reading the cache file relies on the platform's text file buffer
APIs, which as reported in bug 160614,
do not detect encodings properly for files that are not workspace resources.
 Typically this means reading the 16-bit characters as 8-bit characters
and treating the Byte
Order Mark in front as characters
at the start of the first line.  The result of this is that the cache
is never successfully reloaded because the simple string comparison fails
every time.  While this is not a catastrophic functional failure,
it does negate the huge savings that the cache provides (see bug 148649).
 The patch simply changes the reading in of the cache file to use
a more basic InputStreamReader with a fixed UTF-16 encoding.  No released
version has ever used a different encoding, making this assumption safe.


---
Nitin Dahyabhai