FULL PRODUCT VERSION :
Any Java 1.5 version

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
IDLJ generates wrong repository ID for structs defined in IDL

For this IDL definition:
***
module com {
  module lhs {
    module ccb {
      module soi {
      	module types {
  struct LocaleI
  {
    string language;
    string country;
    string variant;
  };
					};
				};
			};
		};
};
  
***

The following repository ID will be generated:
***
private static String  _id = "IDL:com/lhs/ccb/soi/types/LocaleI/LocaleI:1.0";
***

The "LocaleI" is repeated here two times - this is wrong.
IDLJ from the Java 1.4 generates the following repository ID (the correct one):
private static String  _id = "IDL:com/lhs/ccb/soi/types/LocaleI:1.0";


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Put this into a file "test.idl"
***
module com {
  module lhs {
    module ccb {
      module soi {
      	module types {
  struct LocaleI
  {
    string language;
    string country;
    string variant;
  };
					};
				};
			};
		};
};
***

2. Execute:
idlj -fAll test.idl


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The generated class LocaleIHelper should contains the following repository ID:

private static String  _id = "IDL:com/lhs/ccb/soi/types/LocaleI:1.0";

If I generate Java classes with IDLJ from Java 1.4 it generates this exactly this repository ID.
If I use idl2cpp compiler from TAO orb it generates C++ classes with this repository ID.
ACTUAL -
IDLJ  generates:

private static String  _id = "IDL:com/lhs/ccb/soi/types/LocaleI/LocaleI:1.0";


REPRODUCIBILITY :
This bug can be reproduced always.

Release Regression From : 1.4.2
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.
Posted Date : 2006-06-14 01:27:45.0

N/A

entry.repositoryID ().ID () is returning an incorrect string.
Some logic in the com.sun.tools.corba.se.idl.Parser class could 
be at fault. To investigate further.
Posted Date : 2006-08-11 18:50:24.0

For us this is a show stopper. We can't use Java 5. Our application transfers CORBA structs in CORBA:Any objects. The repository ID is included in the Any. So client and server no longer interoperate since they use different reference IDs (unless run this Java 5 version, which they don't).

Same as above, it's a show-stopper as I can no longer interoperate with non Java 5 CORBA code.

This bug does not seem to be fixed in Java 6 rc. Very strange considering the severity of the bug since it breaks Corba interoperability.

I can confirm what jcedata says. This is not fixed in Java 6. 

The problem has not been fixed in Java 6. What's the point of write-once run everywhere, if we can't get something as basic as interoperability between 1.4 CORBA Clients and 1.6 CORBA  Servers.

This is NOT fixed in the 1.6 JDK release 3, 4 or 5.
What are you people waiting for?

Just tried this again using:
jdk1.6.0
jdk1.6.0_01
jdk1.6.0_02
jdk1.6.0_03
jdk1.6.0_04
jdk1.6.0_05
The same problem exists.

 ericpierskalla, 
as the bug report indicates - this fix is in 6u10 which is still a few months away from general release. If you need a fix in the interim and have a support contract please contact sun service to get the issue escalated.