Under certain circumstances, if I have a struct defined in my idl(e.g., struct foo), running the idl compiler generates a source file with an underscore preceding the name(e.g., _foo.java). In order to work around this, we need to change the name of the struct. e.g, just play with the name until the problem goes away. It's not easily reproducable, since if I just cut and paste the problematic struct into a very simple idl file with only this struct defined, the problem does NOT show up. It seems to be context sensitive. e.g., put the same struct into a different idl file and the problem does NOT happen. In our experience, the struct with the problem noted above is also referenced as an argument as an "in" argument in an interface method. The idl files that had this problem all had #include of one or more other idl files. *** Since our company would probably be unhappy with us sending you copies of several of our idl files, I can't provide a sample. However, if you let me know where to add debugging in JacORB 2.0 idl compiler files, I can run the problematic idl files through the compiler and send you the debugging output.
Underscores are gerenally prepended by the IDL compiler to prevent identifiers from clashing with Java keywords. If you want to debug, I suggest you edit the method needsJavaEscape in the class src/org/jacorb/idl/lexer.java to emit additional output when escaping occurs.
Created attachment 57 [details] More explanation
Created attachment 58 [details] stack trace showing error case from debug lexer.java
Created attachment 59 [details] debug version of lexer.java
The root of the problem is a clash between libraries that were loaded from the endorsed dir and the Java_CUP parser runtime classes used by JacORB. After moving these classes to a different namespace in JacORB, this clash is no longer possible.
I am sorry, I meant to add the last comment to another bug, NOT this one! Don't know how this happened.... :-( Gerald.
The root of the problem is that the lexer is overly cautious and complains about the suffix "Operations" in *any* identifier because this could potentially clash with generated signature class "fooOperations" for an interface "foo". Complaining about "fooOperations" is okay WRT the Java language mapping if there is an interface "foo". The workaround here is to avoid the suffixes "Operations", "Holder", "Helper" and "Package" which are used to in the names of mapped classes. The solution is to modify the lexer such that it will check if there is an interface named "foo" before complaining. I am downgrading the severity because I believe the workarounds should be viable in most cases. Cannot promise the fix for this maintenance release, I am afraid. Regards and thanks for the bug report, Gerald.
With the latest fix for #610 this problem is solved, too. *** This bug has been marked as a duplicate of 610 ***