I'm working with a LARGE legacy C++ code base with numerous IDL files that have all the types and constants declared outside of any module.
For C++, this results in code being generated to the global namespace -- ugly, but acceptable.
Now I'm trying to add Java clients to connect via CORBA. For Java, however, the types that are generated from the IDL (using the Sun/Oracle IDL compiler for java: idlj) are in the java default package because they are not within an IDL module. This results in Java compilation errors, as it is illegal to import from the default package.
I'm looking for the easiest way to correct the problem.
I've considered the following:
- Place a module declaration around all types. I'm currently working this solution, but it's VERY painful, based on the number of types affected and the impact to the large legacy C++ codebase.
- Use the -pkgPrefix or -pkgTranslate options. So far, I can't figure out how to accomplish this generically, since you must specify a module to translate from or specify a type to add a prefix to. -pkgPrefix can be used for a specific type, but we have hundreds of types and I'd rather not list a -pkgPrefix option specifically for each compiled file...
- Use a pragma directive? I'm not aware of one to use, but hoping a guru can point the way?
- ????
I find it difficult to believe that there's no easy way to force the IDL to be in a Java package if there's not an existing module that contains all the types. I'm hoping that I'm just missing the obvious!
Edit:
- IDL-to-Java compiler is idlj.
- Added example below.
- Updated Item #2 (above) to clarify that using -pkgPrefix for each type is not feasible (unless it can be reasonably scripted?)
Example:
Foo.idl
struct Foo
{
.
.
.
}
Foo.java: (note that no package is specified, meaning the default package):
public final class Foo implements org.omg.CORBA.portable.IDLEntity
{
.
.
.
}
ClassUsesFoo.java:
package com.sigh;
import Foo; // <-- this is an error
public class ClassUsesFoo
{
private Foo f;
};