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

[Jason Greene (JIRA)]

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

Jason Greene edited comment on WFLY-1077 at 2/18/14 11:33 AM:
--------------------------------------------------------------

The previous approach that Stuart was investigating was based on the notion of being able to ship the JDK Orb in an EAP minor release which would have required that we support both JacORB and the Sun ORB and have plug-able orbs. The problem with that prototype was that the standard Corba APIs are too tied to a particular implementation, so we would have had to have separate binary distributions, switching out versions for each ORB, or change the APIs but that would violate the spec. That's when we shelved it and thought we would dust it off for the next major.

As to just using whats in the JDK the four problems we run into are:
1. Broken Interaction with Modularity - The implementation expects the users application classes to be on the main java class path, which they aren't
2. Proprietary JDK-specific hooks - Integrating with the ORB requires that we use internal JDK classes, but these can vary across JVM vender and version
3. Potential Interoperability issues - If the user is using IBM on one VM and OracleJDK on another, we might not be able to fix an interop problem
4. Inability to fix bugs - If we find a problem with the JDK, getting the bug fixed takes ages. As an example, I fixed a serious deadlock NIO bug on mac, and it took 13 months for that bug fix to show up in a release.

That said the work is simpler if we are doing a hard switch, we can eliminate all of the JacORB integration code, and all of the plug-ability code.
                
      was (Author: jason.greene):
    The previous approach that Stuart was investigating was based on the notion of being able to ship the JDK Orb in an EAP minor release which would have required that we support both JacORB and the Sun ORB and have plug-able orbs. The problem with that prototype was that the standard Corba APIs are too tied to a particular implementation, so we would have had to have separate binary distributions, switching out versions for each ORB, or change the APIs but that would violate the spec. That's when we shelved it and thought we would dust it off for the next major.

As to just using whats in the JDK the three problems we run into are:
1. Broken Interaction with Modularity - The implementation expects the users application classes to be on the main java class path, which they aren't
2. Proprietary JDK-specific hooks - Integrating with the ORB requires that we use internal JDK classes, but these can vary across JVM vender and version
3. Potential Interoperability issues - If the user is using IBM on one VM and OracleJDK on another, we might not be able to fix an interop problem
4. Inability to fix bugs - If we find a problem with the JDK, getting the bug fixed takes ages. As an example, I fixed a serious deadlock NIO bug on mac, and it took 13 months for that bug fix to show up in a release.

That said the work is simpler if we are doing a hard switch, we can eliminate all of the JacORB integration code, and all of the plug-ability code.
                  
> 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