You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Rory O'Donnell <ro...@oracle.com> on 2016/07/22 09:23:09 UTC

Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Hi Stefan,

Early Access b128 <https://jdk9.java.net/download/> for JDK 9 is 
available on java.net, summary of  changes are listed here 
<http://www.java.net/download/java/jdk9/changes/jdk-9+128.html>.

Early Access b127 <https://jdk9.java.net/jigsaw/> (#5304) for JDK 9 with 
Project Jigsaw is available on java.net, summary of changes are listed 
here 
<http://download.java.net/java/jigsaw/archive/127/binaries/jdk-9+127.html>

Early Access b03 <https://jdk8.java.net/download.html> for JDK 8u112 is 
available on java.net, summary of  changes are listed here 
<http://www.java.net/download/java/jdk8u112/changes/jdk8u112-b03.html>

Alan Bateman posted new EA builds contain initial implementation of 
current proposals , more info [0]

    The jigsaw/jake forest has been updated with an initial
    implementation of the proposals that Mark brought to the
    jpms-spec-experts mailing list last week. For those that don't build
    from source then the EA build/downloads [1] has also been refreshed.


Rgds,Rory

[0] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008467.html
[1] https://jdk9.java.net/jigsaw/

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by Stefan Bodewig <bo...@apache.org>.
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by dalibor topic <da...@oracle.com>.

On 01.08.2016 16:32, Stefan Bodewig wrote:
> On 2016-08-01, dalibor topic wrote:
>
>> I'd also suggest a sideways glance at
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=42838 again, in light
>> of the current minimal platform requirements for Ant.
>
> Sure, unfortunately the ticket only has people with strong opinions but
> no code attached to it :-)

I'm not sure if Bugzilla could be configured to use different font sizes 
to display comments with and without attached code, but it may be worth 
a try ;)

> One question to ask is what would improve for Ant if we used javax.tools
> rather than keep the existing code. We wouldn't easily be able to take
> advantage of anything the new API offers that went beyond our own
> compiler abstraction without breaking those who implement the current
> abstraction (this includes code outside of Ant like the adapter for
> Eclipse's ejc).

Fwiw, the Eclipse compiler does support JSR 199: 
http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_batch_compiler.htm 
. On the other hand, Eclipse does seem to come with its own Ant JDT 
Compiler Adapter: 
http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-ant_javac_adapter.htm&cp=1_3_8_1 
.

Jonathan and others go into some of the advantages that could be taken 
with the JSR APIs on Bugzilla, and the Maven Compiler Plugin seems to 
have gone that route by default since 3.0: 
http://maven.apache.org/plugins/maven-compiler-plugin/ potentially 
leading to performance improvements: 
https://issues.apache.org/jira/browse/WICKET-4523 .

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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-08-01, dalibor topic wrote:

> I'd also suggest a sideways glance at
> https://bz.apache.org/bugzilla/show_bug.cgi?id=42838 again, in light
> of the current minimal platform requirements for Ant.

Sure, unfortunately the ticket only has people with strong opinions but
no code attached to it :-)

Seriously, Ant's javac facade would have been sufficient even back in
1.7.0 to provide an implementation based on JSR 199.  It just never
looked worth the effort if we needed to support the
com.sun.tools.javac.Main based entry point for older JDKs anyway.  For
Ant 1.9.x this still is true as Java5 is the target. We wouldn't drop
the code that has worked well for years in 1.10.x either.

One question to ask is what would improve for Ant if we used javax.tools
rather than keep the existing code. We wouldn't easily be able to take
advantage of anything the new API offers that went beyond our own
compiler abstraction without breaking those who implement the current
abstraction (this includes code outside of Ant like the adapter for
Eclipse's ejc).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by dalibor topic <da...@oracle.com>.
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by dalibor topic <da...@oracle.com>.

On 28.07.2016 12:21, Stefan Bodewig wrote:
>
> If I understand this correctly the switch to CLDR has the potential to
> break the assumptions about the patterns used by DateFormat.SHORT and
> friends - if so I'd ask you to mark this change more prominently as one
> with the potential to break existing code.

Yeah - https://bugs.openjdk.java.net/browse/JDK-8008577 is marked as 
release-notes=yes, so the JDK 9 Release Notes will contain a note on it.
If you'd like to suggest specific items of note, I'd suggest raising 
them on i18n-dev@openjdk [0].

> https://bz.apache.org/bugzilla/show_bug.cgi?id=59909
>
> I'm talking about build files with something like
>
>     <touch file="touchtest" datetime="06/24/2003 2:20 pm"/>
>
> which works fine on JDK<9 and will break (unless you set
> java.locale.providers) on JDK9.

I suspect that https://bugs.openjdk.java.net/browse/JDK-8130845 may be 
related.

cheers,
dalibor topic

[0] http://mail.openjdk.java.net/mailman/listinfo/i18n-dev
-- 
<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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-07-27, Stefan Bodewig wrote:

> I will create a bug ticket for the datetime parsing problem once/if I
> manage to create a stand-alone test case.

It seems somebody else has already done:

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8152154

it has been closed as "not an issue" because I could get back to Java8
behavior by setting a system property.

If I understand this correctly the switch to CLDR has the potential to
break the assumptions about the patterns used by DateFormat.SHORT and
friends - if so I'd ask you to mark this change more prominently as one
with the potential to break existing code.

Our test that rely on the default patterns can be fixed by specifying
the patterns explicitly, and we should update our manual page and
recommend using the pattern attributes explicitly if you want the build
to be consistent between Java versions.

https://bz.apache.org/bugzilla/show_bug.cgi?id=59909

I'm talking about build files with something like

    <touch file="touchtest" datetime="06/24/2003 2:20 pm"/>
    
which works fine on JDK<9 and will break (unless you set
java.locale.providers) on JDK9.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by dalibor topic <da...@oracle.com>.

On 27.07.2016 22:16, Stefan Bodewig wrote:
> I will create a bug ticket for the datetime parsing problem once/if I
> manage to create a stand-alone test case.

Thanks, Stefan!

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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-07-26, Rory O'Donnell wrote:

> Can you log bugs for the above items and let us have the Incident IDs,
> we will follow up  ?

Based on Dalibor's feedback I'll drop the case for rmic -Xnew and likely
won't follow up the JAI problems as I don't see any easy way to isolate
them.

I will create a bug ticket for the datetime parsing problem once/if I
manage to create a stand-alone test case.

Thanks

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by Rory O'Donnell <ro...@oracle.com>.
Hi Stefan,

On 25/07/2016 16:08, Stefan Bodewig wrote:
> Hi all
>
> some feedback from working on Apache Ant.
>
> On 2016-07-22, Rory O'Donnell wrote:
>
>> Early Access b127 <https://jdk9.java.net/jigsaw/> (#5304) for JDK 9
>> with Project Jigsaw is available on java.net, summary of changes are
>> listed here
>> <http://download.java.net/java/jigsaw/archive/127/binaries/jdk-9+127.html>
> thanks to Felix Yang's bug reports I've already fixed problems with
> Ant's native2ascii and rmic tasks.
>
> 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).
>
> [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]
>
> I can successfully bootstrap Ant's master branch with the latest jigsaw
> build and am down to three families of errors:
>
> * 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.
>
> * 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.
>
> * 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.
Can you log bugs for the above items and let us have the Incident IDs, 
we will follow up  ?

Rgds,Rory
>
> Cheers
>
>          Stefan

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by dalibor topic <da...@oracle.com>.

On 31.07.2016 10:27, Stefan Bodewig wrote:
> Hi all
>
> Ant's master branch is down to a single test failure apart from the JAI
> problems on my local machine.

Great!

> An error I've overlooked when I initially
> reported the problems I've found
>
> It looks as if <https://bz.apache.org/bugzilla/show_bug.cgi?id=52382>
> was back. You can't use Xalan's redirect extension when a
> SecurityManager is set.
>
> The reason is that since JAXP 1.4 XMLConstants.FEATURE_SECURE_PROCESSING
> has been introduced and this one gets enabled (and you can't disable it)
> if a SecurityManager is set. The fix we applied back then is a hack that
> sets _isNotSecureProcessing in TransformerFactoryImpl via reflection -
> this works fine for JDK 7 and 8, but breaks now.

Yeah, that's by design - the module system in JDK 9 prevents such hacks to
internal classes. Please see http://openjdk.java.net/jeps/261 for details
and escape hatches.

As far as not being able to use XSLT extensions when secure processing 
is enabled, that's been the case since JAXP 1.4: 
https://jaxp.java.net/1.4/JAXP-Compatibility.html#JAXP_security , while 
FEATURE_SECURE_PROCESSING itself was introduced with JAXP 1.3: 
http://docs.oracle.com/javase/1.5.0/docs/guide/xml/jaxp/JAXP-Compatibility_150.html#JAXP_security 
. Finally, JAXP 1.5 documents SecurityManager setting 
FEATURE_SECURE_PROCESSING here: 
https://jaxp.java.net/1.5/JAXP1.5Guide.html#JAXP1.5Documentation%2CGuide-5RelationshipwiththeSecurityManageroftheJavaplatform

If you need to do insecure XSLT processing, then 
http://camel.465427.n5.nabble.com/XMLConstants-FEATURE-SECURE-PROCESSING-feature-setting-in-jboss-fuse-6-1-td5750712.html 
may be relevant.

> Rather than adding another layer of reflection (likely need to undo the
> changes to _featureManager from
> http://hg.openjdk.java.net/jdk9/jdk9/jaxp/file/057e5d7f6572/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java#l259
> ) I'd prefer to figure out a way that allows the following scenario:
>
> * User is using an IDE which has enabled a SecurityManager to run
>   Ant
> * User wants to run an XSLT transform that uses Xalan's redirect
>   extension
>
> without any hacks. Running Ant's <junitreport> is one example of such a
> transform.

I think core-libs-dev@openjdk would be a good place to solicit feedback 
in this case.

> PS and completely unrelated: while adding support for javac's -h option
> I realized the option wasn't mentioned inside javac's manual page at
> all. Only javac -help talks about it.

Please see https://bugs.openjdk.java.net/browse/JDK-8065825 and related 
issues.

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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by Stefan Bodewig <bo...@apache.org>.
Hi all

Ant's master branch is down to a single test failure apart from the JAI
problems on my local machine. An error I've overlooked when I initially
reported the problems I've found

It looks as if <https://bz.apache.org/bugzilla/show_bug.cgi?id=52382>
was back. You can't use Xalan's redirect extension when a
SecurityManager is set.

The reason is that since JAXP 1.4 XMLConstants.FEATURE_SECURE_PROCESSING
has been introduced and this one gets enabled (and you can't disable it)
if a SecurityManager is set. The fix we applied back then is a hack that
sets _isNotSecureProcessing in TransformerFactoryImpl via reflection -
this works fine for JDK 7 and 8, but breaks now.

Rather than adding another layer of reflection (likely need to undo the
changes to _featureManager from
http://hg.openjdk.java.net/jdk9/jdk9/jaxp/file/057e5d7f6572/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java#l259
) I'd prefer to figure out a way that allows the following scenario:

* User is using an IDE which has enabled a SecurityManager to run
  Ant
* User wants to run an XSLT transform that uses Xalan's redirect
  extension

without any hacks. Running Ant's <junitreport> is one example of such a
transform.

Cheers

        Stefan

PS and completely unrelated: while adding support for javac's -h option
I realized the option wasn't mentioned inside javac's manual page at
all. Only javac -help talks about it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Early Access builds of JDK 8u112 b03, JDK 9 b128 are available on java.net

Posted by Stefan Bodewig <bo...@apache.org>.
Hi all

some feedback from working on Apache Ant.

On 2016-07-22, Rory O'Donnell wrote:

> Early Access b127 <https://jdk9.java.net/jigsaw/> (#5304) for JDK 9
> with Project Jigsaw is available on java.net, summary of changes are
> listed here
> <http://download.java.net/java/jigsaw/archive/127/binaries/jdk-9+127.html>

thanks to Felix Yang's bug reports I've already fixed problems with
Ant's native2ascii and rmic tasks.

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).

[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]

I can successfully bootstrap Ant's master branch with the latest jigsaw
build and am down to three families of errors:

* 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.

* 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.

* 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.

Cheers

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org