<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 22, 2019, 5:53 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 22/01/2019 4:48 am, Robert Marcano wrote:<br>
>> :<br>
>><br>
>> So the question now is, why signed jars could affect the memory usage <br>
>> of an application (we aren't doing JAR verification on our custom <br>
>> launcher, yet), just by being on the java.class.path? IIRC the <br>
>> initial application classpath JARs were never verified previously (by <br>
>> the java launcher alone, without JNLP around).<br>
>><br>
>> Note: Tested with JARs signed with a self signed certificate and with <br>
>> one signed with a private CA. At most, signing the JARs could slow <br>
>> down the start up if it is now expected to these being verified by <br>
>> the java launcher (is it true?) but not higher memory usage and no <br>
>> reductions after a GC cycle but constants heap size increases.<br>
Signed JARs can be expensive to verify, esp. on first usage as the <br>
verification is likely to result in early loading of a lot of security <br>
classes and infrastructure. If you can narrow down the apparently memory <br>
leak to a small test case with analysis to suggest it's a JDK bug then <br>
it would be good to get a bug submitted.<br><br>
-Alan</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Greeting. Sure, I will work on a distributable reproduction of the problem today but it is new to me that the java launcher do JARs verification now. If it is doing it I doesn't make sense to me, because a self signed or unrecognized  CA doesn't trigger a validation error.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>