Hi Stefan, 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.
[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 .
As far as I know, the native2ascii implementations in NetBeans or IntelliJ do not depend on the JDK tool.
* rmic -Xnew doesn't work and fails with a strange error message. I know I've reported this before: rmic -vcompat -Xnew SomeClass results in ,---- | rmic: error - In doclet class sun.rmi.rmic.newrmic.Main, method | optionLength not accessible | 1 error `---- I think I've been told -Xnew had been removed before (and if so we need to adapt Ant), but there should be a better error message.
Yes, this is https://bugs.openjdk.java.net/browse/JDK-8146299 . "Furthermore it is not documented or supported." so it's not necessarily likely to work between releases or updates.
* 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.
* 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). We use DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT, Locale.US) and receive ,---- | java.text.ParseException: Unparseable date: "06/24/2003 2:20 pm" | at java.text.DateFormat.parse(java.base@9-ea/DateFormat.java:366) `---- The same string is parsed without any problems on Java8 and earlier.
Does setting java.locale.providers as outlined at https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach#JDK9Outreach-UseCLDRLocaleDatabyDefault help?
cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
