Generowanie java z IDL (unikanie pakietu domyślnego)

Question

Pracuję z dużą starszą bazą kodu C++ z wieloma plikami IDL, które mają wszystkie typy i stałe zadeklarowane poza jakimkolwiek modułem.

W języku C++ powstaje kod generowany do globalnej przestrzeni nazw - brzydki, ale akceptowalny.

Teraz próbuję dodać klientów Java do łączenia się przez CORBA. W przypadku języka Java typy generowane z IDL (przy użyciu kompilatora Sun/Oracle IDL dla java: idlj) znajdują się w pakiecie domyślnym java , ponieważ nie znajdują się one w module IDL. Powoduje to błędy kompilacji Java, ponieważ importowanie z domyślnego pakietu jest nielegalne.

Szukam najprostszego sposobu rozwiązania problemu.

Mam zważył, co następuje:

1. Place deklaracji modułu wokół wszystkich rodzajów. Obecnie pracuję nad tym rozwiązaniem, ale jest ono BARDZO bolesne, w zależności od liczby dotkniętych typów i wpływu na dużą starszą bazę kodu C++.
2. Użyj opcji -pkgPrefix lub -pkgTranslate. Do tej pory nie mogę wymyślić, jak to zrobić w sposób ogólny, ponieważ musisz podać moduł do tłumaczenia z lub określić typ, aby dodać prefiks do. -pkgPrefix może być używany dla określonego typu, ale mamy setki typów i wolałbym nie umieszczać opcji -pkgPrefix specjalnie dla każdego skompilowanego pliku ...
3. Użyj dyrektywy pragma? Nie jestem świadomy tego, którego można użyć, ale mam nadzieję, że guru może wskazać drogę?
4. ????

Trudno uwierzyć, że nie ma łatwego sposobu na wymuszenie IDL w pakiecie Java, jeśli nie ma istniejącego modułu, który zawiera wszystkie typy. Mam nadzieję, że po prostu tęsknię za oczywistością!

Edit:

• IDL-to-Java kompilator jest idlj.
• Dodano przykład poniżej.
• Updated Pozycja nr 2 (powyżej) w celu wyjaśnienia, że ​​przy użyciu -pkgPrefix dla każdego rodzaju nie jest możliwe

Przykład (chyba że można zasadnie scenariusza):

---

Foo.idl

struct Foo 
{ 
    . 
    . 
    . 
} 

---

Foo.Java: (pamiętać, że pakiet nie jest określony, co oznacza, że ​​domyślny pakiet):

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; 
}; 

Answer 1

można grać z opcji pkgPrefix i pkgTranslate jak wskazano w a french site Zgaduję, że miałeś tę część poprawnie, ale szczegółowo na wszelki wypadek.

przykład:

interface T1 
{ 
}; 
interface T2 
{ 
}; 

cię konfiguracja pkgPrefix w pliku idl.config

PkgPrefix.T1=aaa 
PkgPrefix.T2=bbb 

następujące polecenie

idlj -td dir T.idl 

tworzy pliki w katalogu (istniejącego) reż:

dir/ 
├── aaa 
│   ├── T1Helper.java 
│   ├── T1Holder.java 
│   ├── T1.java 
│   ├── T1Operations.java 
│   └── _T1Stub.java 
└── bbb 
    ├── T2Helper.java 
    ├── T2Holder.java 
    ├── T2.java 
    ├── T2Operations.java 
    └── _T2Stub.java 

Aby utworzyć plik konfiguracyjny, można użyć kombinacji grep/awk/sed/cut.