It seems that ProviderVersionCheck.java is the only one that still has
the hardcoded 10?*
*
The other two are changed to useRuntime.version().major() call. Is this
difference intentional?
Thanks,
Valerie
On 2/3/2017 11:21 AM, joe darcy wrote:
Hello,
After the version update to "10" in
+1
Paul.
> On 3 Feb 2017, at 11:21, joe darcy wrote:
>
> Hello,
>
> After the version update to "10" in JDK 10 ( JDK-8029942 ), various libraries
> tests failed including:
>
>java/lang/module/MultiReleaseJarTest.java
>
Look good Joe
> On Feb 3, 2017, at 2:21 PM, joe darcy wrote:
>
> Hello,
>
> After the version update to "10" in JDK 10 ( JDK-8029942 ), various libraries
> tests failed including:
>
>java/lang/module/MultiReleaseJarTest.java
>
Hello,
After the version update to "10" in JDK 10 ( JDK-8029942 ), various
libraries tests failed including:
java/lang/module/MultiReleaseJarTest.java
java/security/Provider/ProviderVersionCheck.java
sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
These tests need to
On 02/03/2017 03:02 PM, Sean Mullan wrote:
On 2/2/17 7:08 PM, Stuart Marks wrote:
Hi Claes,
The text of JEP 277 [1] has the following:
Given the history of deprecation in Java SE, and the emphasis on long
term API compatibility across versions, removal of an API is a matter
of serious
On 2/2/17 7:08 PM, Stuart Marks wrote:
Hi Claes,
The text of JEP 277 [1] has the following:
Given the history of deprecation in Java SE, and the emphasis on long
term API compatibility across versions, removal of an API is a matter
of serious concern. Therefore, deprecation with the element