Andi Vajda <va...@apache.org> wrote: > > That's why I made it a JCC option, which could be enabled/disabled > > via the config.py file. (That is, you could build it shared with or > > without auto-find, but if you decided you wanted it the other way, > > you could simply edit config.py to change it.) > > If you build your extension with --find-jvm-dll, code to hack the Path > on windows is inserted into your extension's __init__.py > file. Otherwise, the code doesn't exist in your extension. That code > is run when your extension is first imported. > > That code can only be effective if it is run before the very first > time the _jcc extension is loaded (which loads jcc.dll and jvm.dll > into your process). All other extensions will be run with the > jcc.dll/jvm.dll pair that the first extension caused to be loaded into > the process.
Yes, that's why it's so dangerous to put it in the extension rather than the jcc module. Things will mysteriously work or break depending on module load order. On the other hand, if you just put it in the jcc module, which is the first thing all JCC-generated Windows extensions load, the load order is immaterial. How about a win/win solution here? You add the --find-jvm-dll back as an optional arg to the setup.py for JCC, so that it can, if the user so desires, also do the auto-find trick. Let it default to off, as you prefer. That way, we have mechanism, instead of policy. Those who think it's a good idea can use it, and those who don't can not use it? And let the users vote with their configs? Bill
