Some comments about the jpackage+1-49 update. 1) It has become a lot more verbose since jpackage+1-35. Makes using the verbose argument difficult to actually see relevant output, like the actual rpmbuild/dpkg command output.
It seems to be running rpmbuild --version twice Running [rpmbuild --version] RPM version 4.14.1 Running [rpmbuild --version] RPM version 4.14.1 Same goes for dpkg-deb --version. It is run twice. It is running a lot of ldd commands, is that necessary? They are extremely verbose. Perhaps jpackage needs different verbosity levels if anyone is actually interested in all these ldd outputs. The dpkg command fails a lot with IOException. dpkg-query: no path found matching pattern /usr/lib64/libX11.so.6 java.io.IOException: command [dpkg, -s, /usr/lib64/libX11.so.6] exited with 1 code 2) Previous resources for RPM are no longer used: The resources for application.desktop and application.png is no longer used with building RPM. Have these been removed? Nothing in the changes listed since previous build has any mention that this has been removed. With jpackage+1-35 Using default package resource java32,png [menu icon] (add application.png to the resource-dir to customize) Using default package resource template,desktop [Menu shortcut descriptor] (add application.desktop to the resource-dir to customize) Using default package resource template.spec [RPM spec file] (add application.spec to the resource-dir to customize) With jpackage+1-49 Using default package resource template.spec [RPM spec file] (add application.spec to the resource-dir to customize) /Sverre man. 7. okt. 2019 kl. 10:15 skrev Alan Bateman <alan.bate...@oracle.com>: > On 07/10/2019 08:00, David Holmes wrote: > > On 7/10/2019 4:43 pm, Alan Bateman wrote: > >> On 07/10/2019 04:35, David Holmes wrote: > >>> > >>> Nothing to do with jpackage but a fix to Class.forName to ensure > >>> classes are linked as per the specification of forName. You can > >>> temporarily workaround with -XX:+ClassForNameDeferLinking, but your > >>> code needs to be updated to deal with LinkageErrors from Class.forName. > >> In this case, it is core reflection code that it looking at the type > >> parameters in the type of a field. I suspect this code needs to > >> translate NCDEF to TypeNotPresentException, other linkage errors > >> maybe need to be handled here too. > > > > Oops! Yes indeed. > I've created JDK-8231924 [1] to track this. We will need to a wider > audit of Class.forName usages in the JDK in case there are other issues > like this. > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8231924 >
