The background makes sense, and along the lines I imagined.

To correct my initial workaround idea, as you illustrate, it has to be a sub-class. A good idea to just define it in the other API, as opposed to creating a generic one in both.

QuoteI split my project into three parts. One contains the common stuff and will be compiled against jPCT-AE

I split in two projects, each having two source folders. The the common folder in project part is linked to a source folder in the other part. So one project is self-contained (JPCT-AE), the other borrows the common folder.

I was trying to make common scene code that would run equally on JPCT and JPCT-AE (with a small platform-specific layer). One difference is the package of the Light class: com.threed.jpct.util for JPCT and com.threed.jpct for JPCT-AE. This will be an issue for a cross-platform source if imports are explicitly declared.

I am trying to understand the rationale: this seems to be the same Light object, but not clear why different packages between platforms. Moreover, the com.threed.jpct.util still exists in JPCT-AE.

For now the workaround is to move Light to the platform-specific area.