RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java

[Eamonn McManus]

OK. In that case I would suggest removing the checkVersion variable since
it is now always true, along with the logic from ImplVersionCommand for
when it is false.

Éamonn

2016-01-05 5:52 GMT-08:00 Jaroslav Bachorik <jaroslav.bachorik at oracle.com>:

> On 4.1.2016 21:26, Eamonn McManus wrote:
>
>> I think this test should either be deleted or reduced to a simple check
>> that the MBeanServerDelegate's ImplementationVersion attribute is equal
>> to System.getProperty("java.runtime.version"). The whole business of
>> starting up a separate process and checking things with security
>> managers and so on is completely obsolete.
>>
>
> I would leave this for SQE to decide. Removing the security manager part
> would change the semantics of the test.
>
> I would suggest dealing with this in a separate issue not to block the
> effort of removing references to 'sun.boot.class.path' for jigsaw.
>
> -JB-
>
>
>> Éamonn
>>
>> 2016-01-04 2:20 GMT-08:00 Jaroslav Bachorik
>> <jaroslav.bachorik at oracle.com <mailto:jaroslav.bachorik at oracle.com>>:
>>
>>     Please, review the following simple change
>>
>>     Issue : https://bugs.openjdk.java.net/browse/JDK-8143047
>>     Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00
>>
>>     The patch removes the special path taken when jmxrmi.jar is present
>>     on the bootclasspath. There are two reasons for this cleanup:
>>     1. Bootclasspath will not be available (or meaningful) in Jigsaw
>>     2. We haven't been testing with an external jmxrmi.jar for ages -
>>     since JMX was included into JDK in JDK 5.
>>
>>     The modified test is still passing.
>>
>>     -JB-
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160105/a6b19b3f/attachment.html>