[jacorb-developer] Should jacorb-omgapi be fed into the compiler?

[Timothy Astle]

I observed something odd today and I'm not sure what to make of it 
(mostly because it was done this way for such a long time), so I'm going 
to do my best to describe what I seen in hope of understanding this 
better.  I'm going to omit versions and configuration details for now, 
just so I can make sure my logic is correct.

Today when using Eclipse, I started seeing a compilation error for a 
class that extends a CORBA stub.  This stub extends the 
org.omg.CORBA.Object.  The eclipse compiler complained that my stub 
implementation was missing implementations for the following methods:

* _get_client_policy(...)
* _validate_connection(...)
* etc.

Basically, the methods outlined in this conversation, which relate to a 
CORBA 3.1 draft:
http://www.omg.org/issues/issue5782.txt

I had a colleague use Eclipse and click through to his implementation 
(which didn't have problems) and he had Oracle comments all over the 
place.  So his Object interface was from Oracle (JDK), mine was from the 
3.6.1 jacorb-omgapi bundle.

The build using Maven (javac) never hits what I observed in Eclipse, but 
I'm not convinced it is correct, even though it "works".  I would have 
expected that we would have been using the org.omg.CORBA.Object from 
JacORB.  So during compilation, I would have expected it to fail the 
same as I'm now seeing in Eclipse.

So I started digging about our configuration and looking at examples 
online for any hints so see if my suspicions were right or wrong.

I don't believe the compiler plays a role in this particular problem 
because the generated code appears to be fine, but I'll show what I have:

<plugin>
     <groupId>org.codehaus.mojo</groupId>
     <artifactId>idlj-maven-plugin</artifactId>
     <version>1.2.1</version>
     <executions>
         <execution>
             <goals>
                 <goal>generate</goal>
             </goals>
         </execution>
     </executions>
     <configuration>
         <compiler>jacorb</compiler>
         <sources>
             <source>
                 <includes>
                     <include>**/example.idl</include>
                 </includes>
                 <additionalArguments>
<additionalArgument>-D_PRE_3_0_COMPILER_</additionalArgument>
<additionalArgument>-DJACORB</additionalArgument>
                 </additionalArguments>
                 <compatible>false</compatible>
                 <emitStubs>true</emitStubs>
                 <emitSkeletons>false</emitSkeletons>
             </source>
         </sources>
         <includeDirs>
             <includeDir>src/main/idl/jacorb</includeDir>
             <includeDir>src/main/idl</includeDir>
         </includeDirs>
         <dependencies>
             <dependency>
                 <groupId>org.jacorb</groupId>
<artifactId>jacorb-idl-compiler</artifactId>
                 <version>3.6.1</version>
             </dependency>
         </dependencies>
     </configuration>
</plugin>

Since the problem seems to be compile time, I started thinking about 
things like -Xbootclasspath, endorsedDirs, etc.  Then I stumbled across 
this:

https://github.com/JacORB/JacORB/blob/master/demo/maven/pom.xml#L57

So I'm like, "Hey, maybe I'm onto something here."  I tried this:

<plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-compiler-plugin</artifactId>
     <configuration>
         <source>1.8</source>
         <target>1.8</target>
         <compilerArgs>
             <args>-Xlint:all</args>
<args>-Xbootclasspath/p:${settings.localRepository}/org/jacorb/jacorb-omgapi/3.6.1/jacorb-omgapi-3.6.1.jar</args>
         </compilerArgs>
     </configuration>
</plugin>

and sure enough, it causes errors during our Maven compilation.  I 
believe this is good.

The runtime configuration uses the following properties:

-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB
-Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton

so I think the runtime configuration should continue to work okay (I 
could be wrong).

Does anyone have any thoughts?  Should I be setting the bootclasspath to 
the compiler as I did above to cause the failure? (Or is there a better 
way to do this?)  Does anyone notice anything else obvious that I could 
be missing in the configuration?

Thanks for your time,

Tim