jmx-dev [Fwd: Fix compiler problem]

I don't know if the JMX team or the JavaBeans maintainers are on the core-libs-dev mailing list. --- Begin Message --- When trying to compile OpenJDK with the Eclipse compiler, I noticed two compiler errors related to generics. It turned out that the code there is invalid and only javac (inco

jmx-dev Need reviewer for 6888179: Separate out dependency on CORBA

As you know, we need to do some re-organization of code in preparation for the jdk build generating modules. One dependency that I would like to separate out is the dependency on RMI-IIOP and CORBA in the JSR-160 implementation. The motivation is a possible "management" module that wouldn't r

jmx-dev Need reviewer for 6888171: JMX Monitor API should not require JavaBeans to be present

The JMX Monitor API is specified to use the Java Beans introspector for complex types others than CompositeData or arrays. This dependency is undesirable because JavaBeans is very tied to AWT. I'd like to address this dependency. The main observation is that if explicit information is availab

Re: jmx-dev 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value

David Holmes wrote: Dmytro, It looks like this was actually fixed under 6840305 back in July 2009: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300 This CR was not updated however. Does the problem still exist? David Holmes I think this is separate and 6853676 is about co

Re: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties

On 14/09/2012 06:25, Mandy Chung wrote: : I'm not sure I fully understand. Are there no other cases where packages are split across modules? Our goal is to remove all split packages. Yes, as Mandy said, we want to keep things as clean as possible and that means aligning the modules on packag

Re: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties

On 18/09/2012 23:05, Mandy Chung wrote: Eamonn, I filed a RFE that the serviceability team can follow up your suggestion: 7199353: Allow ConstructorProperties annotation from any package Alan - I modified the fix to throw InternalError instead of AssertionError. It's great to have this stat

Re: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently

On 19/09/2012 13:39, Jaroslav Bachorik wrote: The ExecutorTest.java fails in cca. 30-40% of runs with NPE in the part testing IIOP connection. The failure is caused by the JMX notification processing - ideally, once the RMIConnector is closed the client JMX notification processing should quit as

Re: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently

On 19/09/2012 14:16, Jaroslav Bachorik wrote: : Not really - the NPE is thrown within the IIOP generated TIE class. I really don't feel like sticking my fingers into the CORBA code. The application code just receives the NPE. For the record I think it would be better to address the real issue

Re: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently

On 20/09/2012 17:02, Eamonn McManus wrote: Changing the generated RMI/IIOP code so that it no longer causes this exception, or so that it catches it and rethrows a RemoteException, sounds as if it ought to be fairly straightforward, and that's probably what I would do if it were up to me. I think

Re: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently

On 02/10/2012 09:33, Jaroslav Bachorik wrote: : The generated TIE class is inherently thread-unsafe. The internal state (the target field) can be manipulated without any enforced synchronization - eg. it is valid to set the target field to null by calling the deactivate() method after the _invoke

Re: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently

On 04/10/2012 16:28, Jaroslav Bachorik wrote: : This is a follow-up. I've prepared the patch and put it on github - https://github.com/jbachorik/openjdk-patches/tree/master/webrevs/7195779 I wonder who else should be included in the review process since I am changing the IIOP generator code. Als

Re: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently

On 05/10/2012 09:10, Jaroslav Bachorik wrote: I have updated the patch to reflect Alan's remarks. The webrev is at the same location - github takes care of versioning ... -JB- Thanks Jaroslav, I grabbed it from here: https://raw.github.com/jbachorik/openjdk-patches/master/webrevs/7195779/corb

Re: jmx-dev [PATCH] JDK-6705499: Bad JMXConnectorProvider class name prevents all connections - even with standard RMI connector

On 24/10/2012 15:15, Jaroslav Bachorik wrote: I am looking for review and a sponsor. Webrev is available at http://cr.openjdk.java.net/~jbachorik/JDK-6705499/webrev.00/ The issue is caused by the way the java.util.ServiceLoader treats the service registration with incorrect class names. Such a

Re: jmx-dev [PATCH] JDK-6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated

On 24/10/2012 14:50, Jaroslav Bachorik wrote: I am looking for review and sponsor. Webrev is available at http://cr.openjdk.java.net/~jbachorik/JDK-6976971/webrev.00 This is a simple fix - just adding back the test that used to fail due to changes in URI spec. The changes were rolled back befor

Re: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently

On 03/12/2012 19:34, shanliang wrote: Webrev: http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.00/ I haven't reviewed the changes but just an FYI that this test is excluded (see jdk/test/ProblemList.txt) so you need to remove it from the file to re-enable it on all platforms. -Alan

Re: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently

On 03/12/2012 20:36, Dmitry Samersoff wrote: Alan, I would recommend don't do it unless JTREG supports client-server tests natively. -Dmitry I don't understand your mail. Are you recommending that we keep it excluded so that it is never run? I don't think jtreg is the issue, it's just a simp

jmx-dev 8001048: Allow IIOP transport to be optional

I hope this mail doesn't cause Éamonn to choke on his coffee. The JMX Remote API specifies that the RMI connector support the IIOP transport (in addition to the default RMI transport, JRMP). This is highly problematic for our efforts to modularize the platform because of the dependency on COR

Re: jmx-dev 8001048: Allow IIOP transport to be optional

On 14/12/2012 21:38, Dmitry Samersoff wrote: Alan, Does it make sense to move the check if (!IIOPHelper.isAvailable()) inside IIOPHelper.exportObject/unexportObject ? -Dmitry That would be cleaner, I can do that. The highest priority for now is the javadoc, we need to make sure that the mi

Re: jmx-dev 8001048: Allow IIOP transport to be optional

On 15/12/2012 12:35, Daniel Fuchs wrote: Hi Alan, I have just two small suggestions concerning your changes in the tests: AddressableTest.java: == The test used to print a trace: System.out.println(">>> Test successed for "+protocols[i]); and System.out.println(">>> Test failed f

Re: jmx-dev 8001048: Allow IIOP transport to be optional

On 14/12/2012 21:33, Alan Bateman wrote: : http://cr.openjdk.java.net/~alanb/8001048/webrev/index.html I've refreshed this webrev to take account of some of the comments from Dmitry and Daniel. Specifically, I've changed com.sun.jmx.remote.internal.IIOPHelper (which we add

Re: jmx-dev 8001048: Allow IIOP transport to be optional

On 14/12/2012 21:33, Alan Bateman wrote: : The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8001048/webrev/index.html I've refreshed this webrev to take account of some of the comments from Dmitry and Daniel. Specifically, I'

Re: jmx-dev 8001048: Allow IIOP transport to be optional

On 17/12/2012 14:17, Daniel Fuchs wrote: Hi Alan, Looks OK. However I noticed something strange in MissingClassTest.java, which I hadn't seen before. In this test, it seems that the "iiop" protocol is simply skipped (line 114). It was already like that before your changes - but it seems the te

Re: jmx-dev 8001048: Allow IIOP transport to be optional

On 18/12/2012 06:52, Mandy Chung wrote: I looked at the source changes that look good to me. I believe RMIConnector.connect() will throw IOException("iiop not supported") if the given JMXServiceURL specifies iiop protocol but the implementation doesn't support iiop. Do you think it's worth c

Re: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException

On 24/12/2012 14:08, shanliang wrote: webrev: http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.00/ The test is correct, it was implemented to verify the fix for bug 4911721, but in addition it detects luckily another problem within the method ServerNotifForwarder.snoopOnUnregister The p

Re: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException

On 26/12/2012 15:07, shanliang wrote: Yes should use a cop[y, it is a mistake to use a unmodifiable view. Here is the new webrev: http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.02/ I have added a new test to reproduce the bug in an almost sure way. Thanks, Shanliang Thanks for the u

Re: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException

On 27/12/2012 11:33, shanliang wrote: Thanks for all comments, here is the new webrev: http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.03/ Indeed, no need to have @run for the test. Shanliang Thanks, it looks okay to me now. -Alan

Re: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException

On 27/12/2012 18:19, Stuart Marks wrote: I hate to contradict Alan on this It's true that one can omit the @run tag and single-file tests like this one will get built and run by default. My advice, however, is to use the @run tag even when one isn't strictly required. My comment was on th

Re: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException

On 28/12/2012 03:22, Stuart Marks wrote: : Alan, you've fixed a bunch of tests that were missing @run tags at least twice in the past [1], [2]. I observe that this recent changeset [3] removed an @run tag that was necessary to run the test. It's not quite the same pathology, but it demonstrat

jmx-dev Update MXBeans to allow for the possibility that ConstructorProperties is ignored?

With the Compact Profiles proposal [1], there will be a subset Profile of Java SE that has JMX but not java.beans. This creates a challenge for the MXBean spec where a constructor to reconstitute a type may be used if it has the java.beans.ConstructorProperties annotation. For code that is c

Re: jmx-dev Update MXBeans to allow for the possibility that ConstructorProperties is ignored?

On 15/01/2013 14:34, Alan Bateman wrote: : I'm wondering whether to add a clarification to the MXBean on this. It would essentially amount updating the rules under "Reconstructing an instance of Java type J from a CompositeData" so that it's clear that rule 2 does app

Re: jmx-dev Update MXBeans to allow for the possibility that ConstructorProperties is ignored?

I've put a webrev here with the proposed changes here: http://cr.openjdk.java.net/~alanb/8006524/webrev/ In summary, it makes it clear that @ConstructorProperties is not applicable when the runtime does not have this annotation. In the future then it might may be desirable to consider adding

Re: jmx-dev Update MXBeans to allow for the possibility that ConstructorProperties is ignored?

On 24/01/2013 07:12, Mandy Chung wrote: I'm fine with the proposed spec change and look into the addition of javax.management.ConstructorProperties later. For now, to register such a MXBean on a runtime of compact3 profile (without java.beans), it will fail with NotCompliantMBeanException t

Re: jmx-dev [PATCH] Review request for 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1)

On 14/03/2013 04:18, Eric Wang wrote: Hi, Please help to review the fix for bug 7183800 . those tests failed on Ubuntu 12.04. http://cr.openjdk.java.net/~ewang/7183800/webrev.01/ Thanks, Eric This looks good to me, I will push this for you to

Re: jmx-dev [PATCH] Review request for 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1)

On 14/03/2013 09:42, Chris Hegarty wrote: Eric, Alan, This one is confusing me some what. I see the problem, but don't understand why when sending to 127.0.1.1, the from address is 127.0.0.1. Is this behavior specific to Linux, or simply that Linux (12.04) just started to have this configurat

Re: jmx-dev [PING] Re: [PATCH] JDK-7199324: IPv6 JMXConnectorServer.getConnectionIDs() return IDs contradicting address grammar

On 25/04/2013 15:35, Jaroslav Bachorik wrote: Reviving the review process. I still need an official openjdk reviewer for this. Thanks, -JB- Just so I understand, the issue is that RemoteServer.getClientHost is returning a String with an IPv6 literal address so you need to enclose it in [] wh

Re: jmx-dev [PING] Re: [PATCH] JDK-7199324: IPv6 JMXConnectorServer.getConnectionIDs() return IDs contradicting address grammar

On 02/05/2013 11:39, Jaroslav Bachorik wrote: On Čt 25. duben 2013, 16:49:52 CEST, Alan Bateman wrote: On 25/04/2013 15:35, Jaroslav Bachorik wrote: Reviving the review process. I still need an official openjdk reviewer for this. Thanks, -JB- Just so I understand, the issue is that

Re: jmx-dev [PING] Re: [PATCH] JDK-7199324: IPv6 JMXConnectorServer.getConnectionIDs() return IDs contradicting address grammar

On 02/05/2013 11:52, Jaroslav Bachorik wrote: : Thanks Alan, the comments are addressed in http://cr.openjdk.java.net/~jbachorik/JDK-7199324/webrev.03 -JB- Looks good to me. -Alan

Re: jmx-dev RFR: 8015627

On 30/05/2013 12:42, Jaroslav Bachorik wrote: JMX related tests have hard time running in "agentvm" mode because they need a set of privileges which are not granted by the default security manager. For this reason all the tests from javax/management are forced to run in "othervm" mode. com/sun/j

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

On 03/09/2013 09:02, Jaroslav Bachorik wrote: Please, review the following patch: http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 It addresses the problem of the test not properly cleaning up the created threads at exit. It does so

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

On 03/09/2013 12:26, Jaroslav Bachorik wrote: : Hm, actually there are 6 other tests using the LockingThread class which leaves the threads running. So all those tests should be made running in "othervm" mode. Does increasing the number of tests running in "othervm" mode have any negative conseq

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

On 03/09/2013 14:36, Jaroslav Bachorik wrote: : Ok, I've rounded up all the tests in java/lang/management/ThreadMXBean not cleaning up the threads and not running in "othervm" mode and made them running in "othervm" mode. There are 5 such tests. IMO, for 5 tests it is worth to go for the simple

Re: jmx-dev RFR: 6804470 JvmstatCountersTest.java test times out on slower machines

On 14/10/2013 16:21, Jaroslav Bachorik wrote: Please, review the following simple change. The test times out on slower machines and I was able to reproduce the failure even on a normally fast machine using the fastdebug build. The timeout does not occur on every run - more like once in 10-15 r

Re: jmx-dev RFR 7140929: NotSerializableNotifTest.java fails intermittently

On 21/10/2013 12:03, Jaroslav Bachorik wrote: Hi, please, review the following small test change: Issue: https://bugs.openjdk.java.net/browse/JDK-7140929 Webrev: http://cr.openjdk.java.net/~jbachorik/7140929/webrev.00 The test fails intermittently, mostly when it is run with -Xcomp option. T

Re: jmx-dev RFR 8027358: sun/management/jmxremote/bootstrap/LocalManagementTest.java failing since JDK-8004926

On 29/10/2013 17:28, Jaroslav Bachorik wrote: Please, review this test fix. In agentvm mode the test can not rely on the co-location of the test class and the auxiliary classes the test class wants to start. It is necessary to explicitly provide the test class path when starting an external j

Re: jmx-dev Codereview request: 8029063 test/com/sun/jmx/snmp/NoInfoLeakTest.java does not compile with OpenJDK builds

On 27/11/2013 15:41, shanliang wrote: This is a simple test fix, have to remove the test in OpenJDK because the SNMP classes in the OpenJDK will not be compiled if the closed part is not present. Deleting it make sense, thumbs up from me. -Alan.

jmx-dev Dropping support for the IIOP transport from the RMI connector

In JDK 8 we updated the JMX Remote API and the RMI connector so that support for the IIOP transport is optional. RI and Oracle JDK builds continue to support it, builds of Compact Profiles leave it out (as CORBA and a number of its dependencies are not defined for any subset Profile of Java S

jmx-dev 8038343: Eliminate use of reflection to access JavaBeans Introspector

Currently the introspection code in the JMX monitor API uses core reflection to access the JavaBeans Introspector. This came about when we had to eliminate this dependency - for example in the subset Profiles of Java SE then compact3 defines the JMX API but doesn't have java.beans. I'd like

Re: jmx-dev 8038343: Eliminate use of reflection to access JavaBeans Introspector

On 25/03/2014 20:15, Mandy Chung wrote: This looks good. Using the SharedSecrets mechanism is a better solution. I generally prefer to use the 3-arg Class.forName to explicitly pass the class loader but it's really minor. That's a good point, it is more obvious when using the 3-arg method.

Re: jmx-dev 8038343: Eliminate use of reflection to access JavaBeans Introspector

On 25/03/2014 19:29, Florian Weimer wrote: * Alan Bateman: : http://cr.openjdk.java.net/~alanb/8038343/webrev/ Could you use a lambda expression in Introspector? Which of the Introspectors do you see the opportunity, my IDE didn't spot any. -Alan

Re: jmx-dev 8038343: Eliminate use of reflection to access JavaBeans Introspector

On 25/03/2014 20:33, Florian Weimer wrote: * Alan Bateman: http://cr.openjdk.java.net/~alanb/8038343/webrev/ Could you use a lambda expression in Introspector? Which of the Introspectors do you see the opportunity, my IDE didn't spot any. Oh, there are two. I meant the inner cla

Re: jmx-dev [9] Review Request for 8038795: tidy warnings cleanup for javax.management

I think you are looking for jmx-dev so forwarding to that list. On 01/04/2014 13:51, alexander stepanov wrote: Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8038795 Webrev corresponding: http://cr.openjdk.java.net/~yan/8038795/webrev.00

Re: jmx-dev [9] Review Request for 8038795: tidy warnings cleanup for javax.management

On 01/04/2014 14:31, alexander stepanov wrote: Thanks! I should have said that the changes look okay to me. I just assume the removal of the isn't really necessary. -Alan.

jmx-dev 8060166: javax/management/MBeanInfo/NotificationInfoTest.java fails with modular image

This test gets a URL to MBeanServer.class in a way that is dependent on the JDK internal layout (assumes rt.jar). I'd like to change this test to just use ClassLoader.getSystemResource so that it works when we move to a modular image. The proposed attached are below. -Alan --- a/test/javax/

Re: jmx-dev 8060166: javax/management/MBeanInfo/NotificationInfoTest.java fails with modular image

On 13/10/2014 15:35, Daniel Fuchs wrote: On 13/10/14 16:19, Alan Bateman wrote: URL codeBase = ClassLoader.getSystemResource("javax/management/MBeanServer.class"); Interesting simplification. This looks good to me :-) I was intrigued by the difference so I tried the

Re: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK

On 15/10/2014 14:35, shanliang wrote: Hi, SNMP is not part of OpenJDK and SNMP packages are not compiled in OpenJDK, so the SNMP sources should be deleted from the OpenJDK Bug: https://bugs.openjdk.java.net/browse/JDK-8060692 Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8060692/00/ The code

Re: jmx-dev RFR 8060692 Delete com/sun/jmx/snmp and sun/management/snmp from OpenJDK

On 15/10/2014 16:19, shanliang wrote: Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/ I add: ./01/jdk9-make/ for updating ./make/CompileJavaModules.gmk ./01/jdk9-jdk-src/ is same to ./00 Thanks, Shanliang This looks good. -Alan

Re: jmx-dev Code review: 8046192 Eliminate SNMP dependencies to the internal APIs from open jdk modules

On 03/11/2014 13:33, shanliang wrote: Hi, Here is version 2: http://cr.openjdk.java.net/~sjiang/JDK-8046192/01/ The modification in ./jdk/src was missed in the first version. This looks okay to me now. -Alan

Re: jmx-dev JDK 9 RFR of JDK-8066634: Suppress deprecation warnings in java.management module

I assume you meant to cc jmx-dev for this one. In any case it looks okay to me. -Alan On 08/12/2014 07:04, joe darcy wrote: Hello, Please review the patch below which addresses JDK-8066634: Suppress deprecation warnings in java.management module Thanks, -Joe diff -r 913808eaf19a sr

Re: jmx-dev [PING] Dropping support for the IIOP transport from the RMI connector

On 25/05/2015 10:43, Jaroslav Bachorik wrote: Hi, I am reviving this thread to give you the final heads-up before moving on with removing the IIOP transport from the JMX RMI connector. If you have any objections it is the time to speak now. -JB- Just to add to this. JDK 9 builds don't includ

Re: jmx-dev RFR 8043937: Drop support for the IIOP transport from the JMX RMIConnector

On 18/08/2015 15:35, Jaroslav Bachorik wrote: Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8043937 Webrev: http://cr.openjdk.java.net/~jbachorik/8043937/webrev.00 For Java SE 8, JSR 160 was updated to downgrade the support for the JXM RMI-IIOP transport

Re: jmx-dev RFR 8043937: Drop support for the IIOP transport from the JMX RMIConnector

On 19/08/2015 09:59, Jaroslav Bachorik wrote: I missed this. However, I have my doubts about 'common/autoconf/generated-configure.sh' - the comment says this file should not be edited but it was changed in the aforementioned commit. Should I change it back? You will need to edit spec.gmk.in

Re: jmx-dev RFR 8043937: Drop support for the IIOP transport from the JMX RMIConnector

On 19/08/2015 11:47, Jaroslav Bachorik wrote: Top level changes: http://cr.openjdk.java.net/~jbachorik/8043937/webrev.01/ JDK changes: http://cr.openjdk.java.net/~jbachorik/8043937/webrev.01/jdk I think you also need to look at jake/make/rmic/Rmic-java.management.gmk which is where RMICONNECTOR

Re: jmx-dev RFR 8043937: Drop support for the IIOP transport from the JMX RMIConnector

On 19/08/2015 13:51, Jaroslav Bachorik wrote: I hope I got it all this time. Used brute force search for any mention of 'iiop' and removed anything that had anything to do with JMX. Top level: http://cr.openjdk.java.net/~jbachorik/8043937/webrev.02 JDK: http://cr.openjdk.java.net/~jbachorik/8

Re: jmx-dev RFR 8043937: Drop support for the IIOP transport from the JMX RMIConnector

On 19/08/2015 15:01, Jaroslav Bachorik wrote: : There are several tests in jdk/test/javax/management that exercise IIOP if available, shouldn't they be updated too? Not sure about this. These tests are also exercising JMXMP if available - but that has never been a part of JDK. I think the

Re: jmx-dev RFR 8043937: Drop support for the IIOP transport from the JMX RMIConnector

On 21/08/2015 12:49, Jaroslav Bachorik wrote: Updated webrev top-level: http://cr.openjdk.java.net/~jbachorik/8043937/webrev.03 Updated webrev jdk: http://cr.openjdk.java.net/~jbachorik/8043937/webrev.03/jdk Contains changes to the top level repo as well as a correct version of jdk/make/rm

Re: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package

On 08/10/2015 12:49, Jaroslav Bachorik wrote: Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-7199353 Webrev: http://cr.openjdk.java.net/~jbachorik/7199353/webrev.00/top http://cr.openjdk.java.net/~jbachorik/7199353/webrev.00/jdk I see this patch is against

Re: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package

On 08/10/2015 13:26, Jaroslav Bachorik wrote: The patch is adding a new exported package to java.management - so it would have to be adjusted to the way jdk9 defines modules right now (eg. modules.xml). And then do this again for jigsaw/jake I would, personally, prefer to do the change only

Re: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package

On 09/10/2015 12:42, Peter Levart wrote: Hi, I don't think it has been mentioned before, but is @ConstructorProperties still necessary in JDK8+ ? Couldn't the j.l.r.Constructor#getParameters() be used instead? How is one supposed to compile an MXBean that would work in JDK8 and at the same

Re: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package

On 14/10/2015 10:34, Jaroslav Bachorik wrote: Round 2 webrev: http://cr.openjdk.java.net/~jbachorik/7199353/webrev.01 Changes against round 1: * @javax.management.ConstructorProperties (was @javax.management.annotation.ConstructorProperties) * diff is against the current jdk9 (eg. not the

Re: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package

On 14/10/2015 14:38, Jaroslav Bachorik wrote: Eg. "When only @java.beans.ConstructorProperties is used then rule 2 is not applicable to subset Profiles of Java SE that do not include the java.beans package." ? Adding "only" will would work too. You might consider "is present" rather than "i

Re: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package

On 15/10/2015 16:55, Jaroslav Bachorik wrote: Any objections to changing the annotation name to @ConstructorMapping to make it better distinguishable from @java.beans.ConstructorProperties ? Not from me. Do you mind updating the webrev so that we can see the updated javadoc? -Alan.

Re: jmx-dev RFR 8139725: Backout escaped partial fix for JDK-7199353

On 16/10/2015 06:02, Jaroslav Bachorik wrote: Please, review this critical backout request Issue : https://bugs.openjdk.java.net/browse/JDK-8139725 Webrev: http://cr.openjdk.java.net/~jbachorik/8139725/webrev.00 By mistake a partial fix for JDK-7199353 has been pushed recently. It needs to be

Re: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package

On 16/10/2015 13:04, Jaroslav Bachorik wrote: : I have decided for @ConstructorParameters - it is rather close to the original @ConstructorProperties and corresponds to the annotation purpose. I tried to address all the comments gathered in this review. The updated webrev is http://cr.openj

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

On 04/01/2016 10:20, Jaroslav Bachorik wrote: 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 bootcla

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

On 04/01/2016 15:05, Jaroslav Bachorik wrote: : Not sure. With this change in place the test will not even try to detect the situation when JMX is not bundled with JDK. There is another test (jdk/test/javax/management/remote/mandatory/version/ImplVersionTest.java) with the same wording in

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

On 05/01/2016 13:52, Jaroslav Bachorik wrote: 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 busine

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

On 06/01/2016 11:00, Jaroslav Bachorik wrote: On 5.1.2016 16:47, Eamonn McManus wrote: 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. Done. Also updated the test summary wordi

Re: jmx-dev [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure

On 29/06/2018 09:22, Sibabrata Sahoo wrote: May I get the approval from serviceability-...@openjdk.java.net. This a test only change to update the keystores and the list of ciphers/protocols that the test uses. There's nothing serviceability specific here so having a Reviewer from the security

Re: jmx-dev committed > max in MemoryMXBean#getHeapMemoryUsage()

probably best to ask this on serviceability-dev as it's more about the java.lang.management implementation rather than JMX. On 12/07/2018 13:57, Daniel Mitterdorfer wrote: Hi, while working on a change in Elasticsearch, I discovered an interesting situation related to the implementation of jmm

Re: jmx-dev RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows

On 19/05/2019 22:12, Daniil Titov wrote: Please review the change that fixes the failure of sun/management/jmxremote/bootstrap JMX tests on Windows platform. While running, these tests invoke revokeall.exe utility and this utility hangs. The problem here is that invokeall.exe goes into an end

Re: jmx-dev RFR: 8213222: remove RMIConnectorServer.CREDENTIAL_TYPES

On 11/01/2020 04:52, Daniil Titov wrote: Please review a change [1] that removes constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE. This constant represents the name of the attribute that specifies a list of class names acceptable to the RMIServer.newClient() remote method

Re: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX

On 21/01/2020 07:15, Yangfei (Felix) wrote: Hi Daniel, Thanks for reviewing the patch. Will do the push. Is this a documented and supported property? I assume so, in which case you should create a CSR. I think a Release-Note sub-task will needed too so that it gets into at least the relea

Re: jmx-dev RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy wrote: >> Before this Enhancement can be formally reviewed, you will need a JBS bug >> ID. If you are already working with a >> Committer or Reviewer in the `jdk` project who has agreed to sponsor your >> change, they can file the Enhancement

Re: jmx-dev RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote: >> @dholmes-ora raises a good point. Hopefully there is a balance point between >> a dozen different bugs / pull requests >> each targeting one area and one bug / PR targeting a dozen separate areas. I >> don't have a good general rule to su

Re: jmx-dev RFR: 8253497: Core Libs Terminology Refresh [v2]

On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words >> with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were >> changed as follows

Re: jmx-dev RFR: 8253497: Core Libs Terminology Refresh [v4]

On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words >> with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were >> changed as follows

Re: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records

On Thu, 25 Mar 2021 17:30:52 GMT, Daniel Fuchs wrote: > This RFE proposes to extend the MXBean framework to define a mapping to > records. > > The MXBean framework already defines a mapping of `CompositeType` to plain > java objects. Records are a natural representation of CompositeTypes. A >

Re: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v7]

On Fri, 2 Apr 2021 18:00:57 GMT, Daniel Fuchs wrote: >> This RFE proposes to extend the MXBean framework to define a mapping to >> records. >> >> The MXBean framework already defines a mapping of `CompositeType` to plain >> java objects. Records are a natural representation of CompositeTypes.

Re: jmx-dev RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP > 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming > `disallow`, tests calling `System.setSecurityManager()` need > `-Djava.secu

Re: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. > https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28

Re: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 315: >> >>> 313: * >>> 314: * @since 1.0 >>> 315: * @deprecated The Security Manager is deprecated and subject to >>> removal in a >> >> Javadoc will prefix, in bold, "D

Re: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. > https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28

Re: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

On Thu, 20 May 2021 04:22:32 GMT, Phil Race wrote: >> That is unfortunate, but nonetheless I think required to be done. >> We have acknowledeged this can't reasonably be called an RFE, so the JEP is >> introducing bugs/technical debt/call it what you will. This should generally >> be part of a

Re: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

On Fri, 21 May 2021 18:00:13 GMT, Phil Race wrote: > Are you suggesting that the patch doesn't need testing as it is ? It should > be the same either way. > It is very straight forward to run the automated tests across all platforms > these days. > I get the impression that no one is guaranteei

Re: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6]

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e38

Re: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]

On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e384

Re: jmx-dev RFR: JDK-8275244: Suppress warnings on non-serializable array component types in jdk.management

On Wed, 13 Oct 2021 19:58:43 GMT, Joe Darcy wrote: > After a refinement to the checks under development in #5709, the new checks > examine array types of serial fields and warn if the underlying component > type is not serializable. Per the JLS, all array types are serializable, but > if the b

Re: jmx-dev RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam wrote: > The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never > supported the value `"rw"` since the source code was imported to the openjdk > repo more than 15 years ago. In fact HotSpot throws > `IllegalArgumentException` when such a

Re: jmx-dev RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam wrote: > The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never > supported the value `"rw"` since the source code was imported to the openjdk > repo more than 15 years ago. In fact HotSpot throws > `IllegalArgumentException` when such a

Re: jmx-dev RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() [v2]

On Wed, 11 May 2022 02:43:21 GMT, Ioi Lam wrote: >> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never >> supported the value `"rw"` since the source code was imported to the openjdk >> repo more than 15 years ago. In fact HotSpot throws >> `IllegalArgumentException` when su

  1   2   >