Problem:
- Product Name: VisiBroker
- Product Version: 5.2.1
- Product Component: idl2java
- Platform/OS Version: ALL
- JDK/Compiler Version: Supported JDKs
Compiling IDL-generated code to Java classes failed when an IDL type not enclosed in a module is mapped to a Java type in the global namespace. Try importing this java type causes compilation to failed.
Resolution:
According to CORBA idl2java language mapping spec Section 1.3:"IDL declarations not enclosed in any modules are mapped into the (unnamed) Java global scope."
So VisiBroker's idl2java compiler is correct in that it maps:
typedef string TroubleString;
to TroubleStringHelper.java without any package.
What has changed in Java going to version 1.4 is detailed here:
Incompatibilities in the Java 2 Platform, Standard Edition, v1.4
The compiler now rejects import statements that import a type from the unnamed namespace. Previous versions of the compiler would accept such import declarations, even though they were arguably not allowed by the language (because the type name appearing in the import clause is not in scope). The specification is being clarified to state clearly that you cannot have a simple name in an import statement, nor can you import from the unnamed namespace.
To summarize, the syntax
import SimpleName;
is no longer legal. Nor is the syntax
import ClassInUnnamedNamespace.Nested;
which would import a nested class from the unnamed namespace. To fix such problems in your code, move all of the classes from the unnamed namespace into a named namespace.
This is why the compilation failed. Agreeably, there is a bit of disconnect between the CORBA idl2java spec and Sun's Java spec. But to make the Java generated code coming from the IDLs compile correctly, all the IDL types and interfaces would need to be in a module (thus compile into Java namespaces). This is the only solution that would comply with both CORBA and Java specs.
#Security
#VisiBroker




