[jboss-jira] [JBoss JIRA] (WFLY-1077) JDK ORB Subsystem

[Stuart Douglas (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12946221#comment-12946221 ] 

Stuart Douglas commented on WFLY-1077:
--------------------------------------

There are a few reasons why we would need a fork if we wanted to adopt the Oracle ORB. A lot of them have already been mentioned above but just to re-iterate:

- Using the JDK ORB is not an option as different JDK's have different ORB implementations, and if a bug is discovered we have no way of fixing it in a timely manner. Even though this is part of the JDK this code is no where near as well tested as other parts of the JDK code. For example one bug I found straight away was than AnyImpl.write_value(OutputStream out) would throw a NPE with the version of the JDK ORB I was using, as far as I could see it looked like nothing used that particular code path, and so the bug was never discovered.

- We require some changes to the RMI-API classes to make some of the things we do in EAP work correctly (such as automatic stub generation and transparent substitution between remoting and CORBA objects). There are a few reasons why we would need a fork if we wanted to adopt the Oracle ORB. A lot of them have already been mentioned above but just to re-iterate:

- Using the JDK ORB is not an option as different JDK's have different ORB implementations, and if a bug is discovered we have no way of fixing it in a timely manner. Even though this is part of the JDK this code is no where near as well tested as other parts of the JDK code. For example one bug I found straight away was than AnyImpl.write_value(OutputStream out) would throw a NPE with the version of the JDK ORB I was using, as far as I could see it looked like nothing used that particular code path, and so the bug was never discovered.

- We require some changes to the RMI-API classes to make some of the things we do in EAP work correctly (such as automatic stub generation and transparent substitution between remoting and CORBA objects). 

- Using the Glassfish ORB is not really an option, as it has to many dependencies on Glassfish internals. The core code base is similar, but there is no way we could just take it as is and put it into EAP.

Something else worth mentioning is that when we were originally looking at this we thought that there were issues with JacORB's chunking implementation that were causing interoperability problems that would have been very difficult to fix. Basically in some circumstances JacORB was ignoring the chunked marker and just assuming a value was chunked. It turned out that even though this looked like a problem according to the spec you are not allowed to send non-chunked objected embedded into a chunked object, so the real problem was that the Glassfish ORB was not following the spec.

Looking at the code base the Oracle ORB does appear more modern, and is under active development, however we really don't have any resources to spare for this, and this is going to be a lot of work for something that is just going to cause our customers headaches with the migration from one ORB to another.

At the moment I really think the problems outweigh the benefits. 
                
> JDK ORB Subsystem
> -----------------
>
>                 Key: WFLY-1077
>                 URL: https://issues.jboss.org/browse/WFLY-1077
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>            Reporter: Dimitris Andreadis
>            Assignee: Stuart Douglas
>
> Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem.
> AFAIK, most/all JDK ORBs are based on the Sun ORB.
> Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira