On 2016-07-26, dalibor topic wrote: > On 25.07.2016 17:08, Stefan Bodewig wrote:
>> For <rmic> Ant was invoking sun.rmi.rmic.Main internally and this class >> is no longer exported (and inside a module Ant wouldn't import >> anyway). I'm a little bit worried that com.sun.tools.javac.Main used in >> <javac> and com.sun.tools.javah.oldjavah.Main used in <javah> may >> "disappear" in similar ways (or already have). > Please see > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008820.html > for the former and https://bugs.openjdk.java.net/browse/JDK-8152360 > for the deprecation of the separate javah tool. Good, this makes me feel better, at least a bit. It doesn't mean javah will work as before (as its entry point may not get exported), but I think I'll implement a froking javac, something like https://bz.apache.org/bugzilla/show_bug.cgi?id=35234 to get on the save side and I've opened https://bz.apache.org/bugzilla/show_bug.cgi?id=59905 in order to support javac -h. >> [aside: removing native2ascii from the JDK as people could use ther >> build tools which in turn use the JDK tool still strikes me as a curious >> move] > This is tracked at https://bugs.openjdk.java.net/browse/JDK-8074431 > and was discussed on core-libs-dev at > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032634.html > . I know (Felix said so much in his bugzilla report), but I'm not sure how many toolsmiths are subscribed there (I'm not). > As far as I know, the native2ascii implementations in NetBeans or > IntelliJ do not depend on the JDK tool. I just looked through the build tools and found that sbt used Ant (and thus was broken as well) and gradle doesn't provide built-in support for native2ascii at all so people will be using Ant here as well. Maven's native2ascii (the one I found, I don't know where the official plugin went after codhauss closed the doors) is an independent implementation but doesn't cover the -reverse case. >> * rmic -Xnew doesn't work and fails with a strange error message. I know >> I've reported this before: > Yes, this is https://bugs.openjdk.java.net/browse/JDK-8146299 OK, I've opened https://bz.apache.org/bugzilla/show_bug.cgi?id=59906 which should lead to fewer failing tests. >> * some of the JAI tests fail, but I haven't had the time to really look >> into them, yet. JAI is not an area I felt confident in jumping in. > JAI is not part of JDK 9 (or any other JDK release). It doesn't seem > that it has seen much development in the past 10 or so years, judging > by https://java.net/projects/jai-core/sources/svn/show , fwiw. It may be my environment, I vaguely recall seeing failures for OpenJDK 7/8 but not for the official Oracle java packages. It's unlikely I'm going to spend much time trying to figure things out. >> * Something has changed WRT date time parsing. Many of the <touch> >> invocations we use inside our tests fail (on my German locale system, >> in case this matters). > Does setting java.locale.providers as outlined at > https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach#JDK9Outreach-UseCLDRLocaleDatabyDefault > help? Not at first glance. Note that we explicitly specify the locale when creating the DateFormat instance. I'll try to extract a stand-alone test case and then open a bug. Thanks Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
