Is there any reason why OCAP-RI no longer use "_g" to differentiate between debug and production shared libraries?
In my opinion this was an unnecessary change.
The reason for this change was sent out to the "dev" and "users" mailing lists. Please subscribe to these lists for important information about changes to the system.
The change was made because of requests that we received to always build the "optimized" or "non-debug" JVM binaries by default -- large, complex applications were taking too long to load. However, we still want to build the stack libraries in "debug" so that we can do development-related debugging. With the old setup, when the JVM was built with debugging enabled, it only looked for JNI libraries with an "_g" suffix. If the JVM was built with debugging disabled, it only loaded JNI libs without the "_g".
Since much of the JNI code that the JVM relies on is part of the stack build (libmpe.dll), we would have had to rename these DLLs anyway or introduce a step in the build process that creates a copy of the library with the "_g" suffix. The stack already has its own organizational structure for separating debug/release binaries, so we just got rid of the JVM-introduced "_g" policy.
That makes sense now. Thanks.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.