Remove local build workaround for non-portable macOS wheels

[devinrsmith]

To maintain the existing behavior with 0.11.x releases, locally built macOS wheels still have hard-coded rpaths to libjvm.dylib.

We should prefer to remove this workaround when applicable (should wait at least for a minor release, not a patch release).

[mkanoor]

@devinrsmith I get this error when I use the wheel package on MacOS. Is this similar to this issue

E   ImportError: dlopen(/Users/xxxx/devsrc/pkg1/.tox/py310/lib/python3.10/site-packages/jpy.cpython-310-darwin.so, 0x0002): symbol not found in flat namespace (_JNI_CreateJavaVM)

I was able to build from source and didn't see the problem.

[devinrsmith]

Are you seeing this for the macOS jpy==0.11.1.dev0 with the pre-built wheels? 0.11.1 hasn't been released yet, but will be after some of my team does some more testing.

If so, I think this is expected for the pre-built wheels. The proper fix depends on the environment, but essentially it's up to the caller to ensure that libjvm.dylib has been properly sourced. This can be accomplished with jpyutil, either through jpyutil.preload_jvm_dll(...) or jpyutil.init_jvm(...) before import jpy is invoked. I'm hoping to get some better usage documentation on this in the future.

I think it makes sense to remove this special-case for local builds in the future for 0.12.x+ releases; I think even building from source locally, you are locking yourself into a hard-coded JVM path that might not be there in the future, so it's best to encourage more general solutions IMO.

[mkanoor]

@devinrsmith No I am using this one jpy-0.11.0-cp310-cp310-macosx_10_15_universal2.whl

[devinrsmith]

Okay. There may be a case to be made that locally-built wheels should retain the specific libjvm.dylib paths hardcoded.

Advantages of hardcoded:

• No need to preload libjvm.dylib library with jpyutil

Disadvantages of hardcoded:

• Can't redistributed wheel
• Will break if JVM location changes (depends on the specific paths that have been hardcoded, symlink vs absolute; but patch upgrades to java may cause breakage)
• Is different behavior than PyPi wheels, so users need to know "Am I working with a hardcoded wheel, or a PyPi distributed wheel?"

I'm going to create a specific issue to create better canonical documentation for expected patterns around preloading libjvm.

In the meantime, it may be worth trying to use the published wheel with a pattern that looks like:

import jpyutil
# This needs to happen before `import jpy`
jpyutil.preload_jvm_dll()

import jpy

or

import jpyutil
# This needs to happen before `import jpy`
jpyutil.init_jvm()

import jpy

This hopefully should work if JAVA_HOME environment is set.