On 2016-03-25 17:53, Paul Sandoz wrote:
On 25 Mar 2016, at 17:37, Claes Redestad wrote:
Interesting, my only concern is we'd add more code/complexity, but it seems the
shift will always be == len when not matching a character in src (the proof is
left out as an exercise), so this can be sim
> On 25 Mar 2016, at 17:37, Claes Redestad wrote:
>
> Interesting, my only concern is we'd add more code/complexity, but it seems
> the shift will always be == len when not matching a character in src (the
> proof is left out as an exercise), so this can be simplified further to:
>
> byte c =
On 2016-03-25 16:03, Paul Sandoz wrote:
On 25 Mar 2016, at 13:56, Claes Redestad wrote:
You've replaced the precomputed good suffix shift which i think makes the Math.max in math a
bit harder to read. A comment or just move a local for "j < len - 1 ? len : 1"
would make it a bit easier to
Hi,
A minor nit on the comment
> + * Since there are no repeated substrings in our search strings,
> + * the good character shifts can be replaced with a comparison.
Probably should be “good suffix shifts”.
Steve
> On 25 Mar 2016, at 13:56, Claes Redestad wrote:
>
>>
>> You've replaced the precomputed good suffix shift which i think makes the
>> Math.max in math a bit harder to read. A comment or just move a local for "j
>> < len - 1 ? len : 1" would make it a bit easier to read.
>>
>> It would be go
On 2016-03-25 11:40, Alan Bateman wrote:
On 25/03/2016 01:06, Claes Redestad wrote:
Hi,
the integration of the multi-release jar feature[1] caused a number
of startup regressions, the primary cause of which was determined to
be due to parsing manifests into java.util.jar.Manifest only to ch
> On 25 Mar 2016, at 02:06, Claes Redestad wrote:
>
> Hi,
>
> the integration of the multi-release jar feature[1] caused a number of
> startup regressions, the primary cause of which was determined to be due to
> parsing manifests into java.util.jar.Manifest only to check for the
> Multi-Rel
On 25/03/2016 01:06, Claes Redestad wrote:
Hi,
the integration of the multi-release jar feature[1] caused a number of
startup regressions, the primary cause of which was determined to be
due to parsing manifests into java.util.jar.Manifest only to check for
the Multi-Release attribute.
This
Hi,
the integration of the multi-release jar feature[1] caused a number of
startup regressions, the primary cause of which was determined to be due
to parsing manifests into java.util.jar.Manifest only to check for the
Multi-Release attribute.
This can be avoided by reusing the logic already
