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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Alan Bateman

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 SE).

I would like to bring up the topic of dropping support for the IIOP
transport completely, that is change the RMI connector so that it only
supports the default JRMP transport. From what I can tell then this
isn't used very widely and I'm curious if anyone would really notice or
care. The rational for doing this is the same reason that we downgraded
it to optional, it's problematic for our modularity efforts due to the
CORBA Tie classes in javax.management.remote.rmi.

So is anyone using it in a way that would be highly disruptive if it
were removed in JDK 9?

-Alan.


Reply | Threaded
Open this post in threaded view
|

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

Jaroslav Bachorik
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-

[original message]
Alan Bateman <Alan.Bateman@...> writes:


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 SE).

I would like to bring up the topic of dropping support for the IIOP
transport completely, that is change the RMI connector so that it only
supports the default JRMP transport. From what I can tell then this
isn't used very widely and I'm curious if anyone would really notice or
care. The rational for doing this is the same reason that we downgraded
it to optional, it's problematic for our modularity efforts due to the
CORBA Tie classes in javax.management.remote.rmi.

So is anyone using it in a way that would be highly disruptive if it
were removed in JDK 9?

-Alan.

[---]




Reply | Threaded
Open this post in threaded view
|

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

Alan Bateman

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 include the IIOP transport so
that the RMIConnector has only support the default transport since
jdk9-b01. So far then I don't think anyone has noticed, at least I'm not
aware of any bug reports.

-Alan.
Reply | Threaded
Open this post in threaded view
|

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

Steven Schlansker

On May 25, 2015, at 3:08 AM, Alan Bateman <[hidden email]> wrote:

>
> 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 include the IIOP transport so that the RMIConnector has only support the default transport since jdk9-b01. So far then I don't think anyone has noticed, at least I'm not aware of any bug reports.

Since this is active development around changing the supported transports in Java 9, maybe this is an opportune moment for me to bring up a request I made early this year -- promoting the JMXMP transport from jmxremote_optional into the core?

http://mail.openjdk.java.net/pipermail/jmx-dev/2015-January/000794.html

Unlike IIOP, there is a clear use case where it is strictly superior to the default RMI transport (when you connect with a firewall or NAT between the application server and your workstation, or a virtual networking setup like Docker)

I apologize for the thread hijack, but I didn't get any replies earlier, and it'd be fantastically useful IMO.

Thanks,
Steven

Reply | Threaded
Open this post in threaded view
|

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

Staffan Larsen-2
Hi Steven,

We started evaluating the inclusion of JMXMP in the JDK last year for the reasons you site. Unfortunately we came to the conclusion that the JMXMP code base in its current form was not suited for inclusion in the JDK. Improving the code base to modernize and remove technical debt was deemed too costly. Of course if other people want to take on the task we are open to contributions.

Regards,
/Staffan

> On 26 maj 2015, at 19:34, Steven Schlansker <[hidden email]> wrote:
>
>
> On May 25, 2015, at 3:08 AM, Alan Bateman <[hidden email]> wrote:
>
>>
>> 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 include the IIOP transport so that the RMIConnector has only support the default transport since jdk9-b01. So far then I don't think anyone has noticed, at least I'm not aware of any bug reports.
>
> Since this is active development around changing the supported transports in Java 9, maybe this is an opportune moment for me to bring up a request I made early this year -- promoting the JMXMP transport from jmxremote_optional into the core?
>
> http://mail.openjdk.java.net/pipermail/jmx-dev/2015-January/000794.html
>
> Unlike IIOP, there is a clear use case where it is strictly superior to the default RMI transport (when you connect with a firewall or NAT between the application server and your workstation, or a virtual networking setup like Docker)
>
> I apologize for the thread hijack, but I didn't get any replies earlier, and it'd be fantastically useful IMO.
>
> Thanks,
> Steven
>