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

Unify Info.plist files with correct version strings

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 16
    • Fix Version/s: 16
    • Component/s: infrastructure
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b14
    • OS:
      os_x

      Description

      When fixing JDK-8246094, I concluded that our Info.plist files are in a bit of a mess. When reading Apple's documentation for some of the standard properties in there, we aren't setting the correctly. We also aren't setting them consistently for all the Info.plist files. JDK-8246094 fixed some of this, but I didn't want that bug to be too disruptive.

      We currently have two different types of Info.plist files.

      1. The global one that gets put in the Contents folder of the JDK/JRE.
      2. One that gets embedded into all our launchers.

      In JDK-8246094, I addressed the fact that there were large discrepancies between these two. What is left to address is:

      1. Unify the location of the files for easier future maintenance.
      2. Correct the values for the version numbers to adhere to the documentation by Apple.

      Number 2 here is the trickier part. Below are the three keys we need to correct. Setting these correctly seems important as Macos uses them to identify an application. In the case of the sound input bug, if two applications shared the exact same values, then the OS would get confused when looking up sound input permissions. This indicates that we need to be mindful of these values so that they are made unique enough in different builds.

      CFBundleIdentifier
      In the main Info.plist, we currently set this to net.openjdk.java.<version>.jdk. I'm not sure if we really should be adding the version string here as there are separate fields for version (2 of them, see below), but I _think_ the reason it's done this way is that the version fields are documented to only accept X.Y.Z, 3 numbers separated by dots, so no free text string there. Our different build versions cannot be simply identified with just numbers, so if we want to keep each application version that a developer might create and install on a system unique, we probably need to keep adding a part of the version string here, at least for developer builds. The embedded plist needs to be changed to mimic this. Possibly we should only add some part of the version string for developer builds and make sure that part is empty for CI/promoted builds where the two version fields below will be unique anyway.

      CFBundleShortVersionString
      This value is currently hard coded to 1.0. That just seems wrong. The Apple documentation says this is a "release" version on the format X.Y.Z. I think we should just put our Verona based version number here instead.

      CFBundleVersion
      This value currently gets our release version. The Apple documentation says this is a "build" version which should change for each build. This also takes the format of X.Y.Z. I think we should put our build number here, with the CI build number added too when available.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              erikj Erik Joelsson
              Reporter:
              erikj Erik Joelsson
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: