Native needs reorg

[Thrameos]

Long ago native/ was the directory for all of the private compiled source code that was under the hood. The original author intended to have a common directory and a set of front ends for python and ruby. Each had a corresponding include directory.

Fast forward to today. Common and python still exist, but we have added java to the mix. Java was added as an after thought to contain the smallish thunk code. Which was originally lost then later recovered. But native/java is rapidly out growing this role.

With the addition of android the Java code now needs 3 pieces: code common to both VMs, code for jvm, and code for dex. It gets more complex as we will also have an additional C++ source tree and Java package to support the reverse bridge. Add in concerns for building as named modules for Java 9+ ( when we drop Java 8) and future maven support and the sounce tree gets to be a mess.

Proposal... the java tree gets a new set of sub directories called org.jpype, org.jpype.jvm.asm, org.jpype.jvm, org.jpype.dex, and python.lang. we build from that two jars org.jpype which contains jvm group and another for android group.

Ideally the cpp code would be organized under native/cpp. But I understand you would like to maintain history on those files. Is that correct @marscher? So we will add one addition native/embedded to house all the reverse bridge C++ code.

[marscher]

Thanks for outlining this. I'd opt for the addition of native/embedded or does this layout make things unnecessarily complex in the future? If so, feel free to restructure it on your behalf.

[Thrameos]

native/embedded is fine. So our tree will be

• native/common - C++ pieces for the behind the scenes inaccessible stuff.
• native/embedded - C++ pieces for Python FFI from Java
• native/python - CPython interface
• native/java/jpype.core - most of the org.jpype stuff that is used everywhere with stubs for machine dependent
• native/java/jpype.jdk - stuff exclusively for java virtual machine implementations.
• native/java/jpype.jdk.asm - stuff used to class extension and reverse bridge (from ASM)
• native/java/jpype.dex - stuff of android machine
• native/jave/jpype.dex.asm - same for dex if we find a workable solution
• native/java/python.lang - Python reverse bridge stubs
• native/java/jpype.python - Reverse bridge internal classes

Does that all sound sane?

[marscher]

Is this still a plan of yours or can we close it?

[Thrameos]

Closing for now.