Project Panama
Two of the weaknesses of the Java platform are [1] the poor support provided through JNI to integrate Java applications with native binary libaries [2] Java practictioner view that all applications should be recoded in Java to avoid interoperability problems. While it is generally accepted that the Microsoft extension to Java for COM integration was an attempt to make Java applications Windows specific; it is also true that copyright of COM was transfered to X/Open to remove licence issues. It is not unreasonable to conclude that the use if COM (on windows) and XPCOM (on Linux/ *ix) was a genuine attempt to provide an object based application binary interface.
Over the twenty years since Sun committed to integrating XP/COM ABI into the JVM, we have not seen the wholesale re-implemntation of everything in Java, but we have seen many inovations with FPGA, GPGPU, SDN, ML, AI etc that demostrate that there will always be a need for interop with Binary code.
Project Panama took like it has incorporated the lessons (failings) of Object-RPC, but the absents of "struct" (value-types) is still an ommision that makes this task more difficult. Comparing Project Panama with the CLR P/Invoke leaves me wondering whether this decades old problem will ever be solved..
It's ironic that one of the big impacts of Java has been the regression to TCP/IP Sockets for interop, and IDL (e.g. protobuf/gRPC) for message formatting.