Linking to JavaRuntimeSupport framework

[Mike Swingler]

Depending on JavaVM.framework, JavaRuntimeSupport.framework, or JavaNativeFoundation.framework isn't a problem, if the Install-on-Demand machinery can detect the presence of the "JLI_MemAlloc" symbol which is exported from libjava. The point of the fix yesterday was to ensure that libjava could be loaded without hauling in any of those other frameworks first.

I'm going to be looking into this more today to make sure we've covered all the cases.

Regards,
Mike Swingler
Java Engineering
Apple Inc.

On Jul 21, 2011, at 8:45 AM, David Smith-Uchida wrote:

> Oh, and the only reason that patch works for me is because my app is Rococoa based.  The AWT native code has a large number of dependencies on JavaRuntimeSupport.  So, unless JavaRuntimeSupport initalization is patched to not generate the install a JVM message, the path to java_props_md.c won't do anything.
> 
> Cheers,
> Dave Smith
> 
> On Jul 21, 2011, at 10:43 PM, David Smith-Uchida wrote:
> 
>> I haven't tried building and running it yet, but the problem was triggered by the call to JRSCopyOSVersion in
>> jdk/src/solaris/native/java/lang/java_props_md.c
>> 
>> Looking at the new code, it's now linking JavaRuntimeSupport dynamically to call it.  Do you have that update?
>> 
>> I'm not sure if that's going to fix it because when I traced down into the code with gdb it was JRSCopyOSVersion calling into some java init that triggered the check for the runtimes, not the static links.
>