Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6950048

Plugin2 needs to look for right MS C runtime when launching an older JRE.

    XMLWordPrintable

Details

    • b125
    • generic
    • generic
    • Not verified

    Description

      deploy/src/plugin/share/classes/sun/plugin2/os/windows/Windows.java

      has some code that handles when a plugin2 aware applet tag has requested
      to run the applet in an earlier (1.4 or 1.5) JRE. That code needs to
      load jp2native.dll - from the same JRE as the invoking plugin2 to
      make sure it gets the right version. As near as I can tell it does
      this by pre-pending its plugin jar location to the boot class path
      of the invocation of that 1.4 JRE. Then some code in NativeLoadLibrary
      will look relative to that first for the jp2native.dll

      It also knows that the earlier 1.4 JRE will not have the
      VS2003 runtime : msvcr71.dll, and jp2native.dll will have
      that as a dependency so in that case it also looks for that C runtime
      and loads it.

      A problem arises when JDK upgrades to VS2010. Then jp2native will
      instead be dependent on msvcr100.dll and all earlier JRE's
      (1.4, 1.5, 1.6) will need to locate that.

      But if I make that code change now, so long as JDK 7 promoted
      builds are using VS2003, then this will break.

      I could put in some "smarts" which attempts to use boot class
      path in a similar way to the code described above and look
      to see which dll is actually in the plugin's jre\bin directory
      and load the right one.

      However after some consideration, it seems like its best to leave this
      referring only to msvcr71.dll. As soon as JDK 7 upgrades to
      use VS2010 we'll need to switch this over to load msvcr100.dll
      if its anything earlier than JDk 1.7

      What tipped this was the realisation that the logic is actually
      GENERATED CODE. And the real source is in
      deploy/make/plugin/plugin2/gensrc/windows.cfg

      So the fix is to make the changes there, and regenerate Windows.java

      Note that if JDK 6 ever switched over to VS2010 something similar
      would need to happen there.

      Attachments

        Activity

          People

            ccheung Calvin Cheung
            prr Philip Race
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: