Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues

Bug 436

Summary:	struct foo generates _foo.java instead of foo.java
Product:	JacORB	Reporter:	john.seltzer
Component:	IDL compiler	Assignee:	Gerald Brose <gerald.brose>
Status:	RESOLVED DUPLICATE
Severity:	normal
Priority:	P2
Version:	2.0 beta3
Hardware:	All
OS:	All
Attachments:	More explanation stack trace showing error case from debug lexer.java debug version of lexer.java

Description john.seltzer 2004-01-06 21:48:55 UTC

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.

Comment 1 Gerald Brose 2004-01-08 17:25:07 UTC

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.

Comment 2 john.seltzer 2004-01-08 17:44:41 UTC

Created attachment 57 [details]
More explanation

Comment 3 john.seltzer 2004-01-10 00:32:38 UTC

Created attachment 58 [details]
stack trace showing error case from debug lexer.java

Comment 4 john.seltzer 2004-01-10 00:34:03 UTC

Created attachment 59 [details]
debug version of lexer.java

Comment 5 Gerald Brose 2004-02-02 08:57:46 UTC

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.

Comment 6 Gerald Brose 2004-02-02 09:07:34 UTC

I am sorry, I meant to add the last comment to another bug, NOT
this one! Don't know how this happened.... :-(

Gerald.

Comment 7 Gerald Brose 2004-10-30 22:11:09 UTC

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.

Comment 8 Gerald Brose 2005-11-19 22:13:53 UTC

With the latest fix for #610 this problem is solved, too.

*** This bug has been marked as a duplicate of 610 ***