manifest.getMainAttributes().put(Attributes.Name.CLASS_PATH, jarFile.getName());

    Closer closer = Closer.create();
    try {
      FileOutputStream fileOut = closer.register(new FileOutputStream(jarFile));
      JarOutputStream jarOut = closer.register(new JarOutputStream(fileOut, manifest));
      for (String entry : entries) {
        jarOut.putNextEntry(new ZipEntry(entry));

    manifest.getMainAttributes().put(Attributes.Name.CLASS_PATH, jarFile.getName());

    Closer closer = Closer.create();
    try {
      FileOutputStream fileOut = closer.register(new FileOutputStream(jarFile));
      JarOutputStream jarOut = closer.register(new JarOutputStream(fileOut, manifest));
      for (String entry : entries) {
        jarOut.putNextEntry(new ZipEntry(entry));

   *
   * <p>We have chosen this approach over at least two alternatives:
   *
   * <ul>
   *   <li>We could change the serialization of this class incompatibly. We have reserved the right
   *       to make such changes to our serialized forms, and we have made them before, usually
   *       without trouble. In this case, my guess is that our chosen approach is even less likely

- Added scoring for the prioritized list feature so nodes that best satisfy the highest-ranked subrequests were chosen. ([#134711](https://github.com/kubernetes/kubernetes/pull/134711), [@mortent](https://github.com/mortent)) [SIG Node, Scheduling and Testing]