Re: JDK 9 RFR of JDK-8163934: Remove intermittent key from java/lang/ProcessBuilder/Zombies.java

[joe darcy]

Looks fine Amy; thanks,

-Joe


On 8/28/2016 6:14 PM, Amy Lu wrote:

java/lang/ProcessBuilder/Zombies.java

This test was failing intermittently (JDK-8160151). Mentioned issue 
has been resolved and no open bug (no failure reported) till now.


This patch is to remove @key intermittent from the test.

bug: https://bugs.openjdk.java.net/browse/JDK-8163934
webrev: http://cr.openjdk.java.net/~amlu/8163934/webrev.00/

Thanks,
Amy

--- old/test/java/lang/ProcessBuilder/Zombies.java2016-08-29 
09:10:18.0 +0800
+++ new/test/java/lang/ProcessBuilder/Zombies.java2016-08-29 
09:10:18.0 +0800

@@ -25,7 +25,6 @@
  * @test
  * @run main/othervm Zombies
  * @bug 6474073 6180151
- * @key intermittent
  * @summary Make sure zombies don't get created on Unix
  * @author Martin Buchholz
  */

Re: JDK 9 RFR of JDK-8163934: Remove intermittent key from java/lang/ProcessBuilder/Zombies.java

[joe darcy]

Looks fine Amy; thanks,

-Joe


On 8/28/2016 6:14 PM, Amy Lu wrote:

java/lang/ProcessBuilder/Zombies.java

This test was failing intermittently (JDK-8160151). Mentioned issue 
has been resolved and no open bug (no failure reported) till now.


This patch is to remove @key intermittent from the test.

bug: https://bugs.openjdk.java.net/browse/JDK-8163934
webrev: http://cr.openjdk.java.net/~amlu/8163934/webrev.00/

Thanks,
Amy

--- old/test/java/lang/ProcessBuilder/Zombies.java2016-08-29 
09:10:18.0 +0800
+++ new/test/java/lang/ProcessBuilder/Zombies.java2016-08-29 
09:10:18.0 +0800

@@ -25,7 +25,6 @@
  * @test
  * @run main/othervm Zombies
  * @bug 6474073 6180151
- * @key intermittent
  * @summary Make sure zombies don't get created on Unix
  * @author Martin Buchholz
  */

JDK 9 RFR of JDK-8163934: Remove intermittent key from java/lang/ProcessBuilder/Zombies.java

[Amy Lu]

java/lang/ProcessBuilder/Zombies.java

This test was failing intermittently (JDK-8160151). Mentioned issue has 
been resolved and no open bug (no failure reported) till now.


This patch is to remove @key intermittent from the test.

bug: https://bugs.openjdk.java.net/browse/JDK-8163934
webrev: http://cr.openjdk.java.net/~amlu/8163934/webrev.00/

Thanks,
Amy

--- old/test/java/lang/ProcessBuilder/Zombies.java  2016-08-29 
09:10:18.0 +0800
+++ new/test/java/lang/ProcessBuilder/Zombies.java  2016-08-29 
09:10:18.0 +0800
@@ -25,7 +25,6 @@
  * @test
  * @run main/othervm Zombies
  * @bug 6474073 6180151
- * @key intermittent
  * @summary Make sure zombies don't get created on Unix
  * @author Martin Buchholz
  */

Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions

[Stefan Bodewig]

Hi,

I've been told to ask for advice here.

Over the past few weeks we've adapted the Apache Ant code base to JDK 9
well enough that Ant's own test suite works - almost.

The onyl remaining issue really goes back to Java 1.7 and JAXP 1.4 when
secure processing was introduced. If you are running an XSLT transform
and it needs extensions - say the Xalan redirect extension - you can't
do it if a SecurityManager has been set.

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

This is causing quite a few problems for users running Ant from within
IDEs which typically install SecurityManagers. One such instance it
Ant's own  task which uses XSLT and the redirect extension.

Back in Java 1.7 we "solved" the problem with a hack. We simply disable
secure processing mode via reflection

https://github.com/apache/ant/commit/fe829a9d0fa679df3ae2cc4803e5236ed2ed5c7b

The module system now breaks the hack as we can no longer access the
necessary field via reflection.

Before we try to find new clever or stupid workarounds we may as well
ask for advice on how to do it properly.

This is our use-case: The user wants to execute Ant's -Task from
within Eclipse which has installed a SecurityManager and the transform
requires an extension. How can we make this work?

Cheers

Stefan

Participating on https://bugs.openjdk.java.net/browse/JDK-8156070

[Jonathan Bluett-Duncan]

Hi all,

My name is Jonathan, and it's my first time posting to this mailing list.

I'm writing to you all as I'm rather interested in contributing to this
area of the OpenJDK. Particularly, I'm thinking I'd quite like to help out
with one of the subtasks for the Immutable Collections enhancements
. However I don't have
specific ideas and I don't know which of the subtasks would most closely
match my skills and knowledge, so I wondered if I could have some guidance
as to what I could do and how I can get started.

FYI, I've partially read the contribution instructions
, and I just submitted an OCA earlier
today, so I don't expect to be actually ready to participate until I hear
back from Oracle, but nonetheless I'd like to try to get the ball rolling
as soon as possible.

Kind regards,
Jonathan Bluett-Duncan

RE: Proposal for adding O_DIRECT support into JDK 9

[Lu, Yingqi]

Hi Uwe/Andrew,

Thank you both for the suggestions. I agree it would be cleaner to make 
O_DIRECT an extended open options within nio package. 

We will modify the patch and update the community soon!

Thanks,
Lucy

-Original Message-
From: Uwe Schindler [mailto:uschind...@apache.org] 
Sent: Sunday, August 28, 2016 3:30 AM
To: 'Andrew Haley' ; Lu, Yingqi ; 
core-libs-dev@openjdk.java.net
Cc: Kaczmarek, Eric 
Subject: RE: Proposal for adding O_DIRECT support into JDK 9

Hi,

IMHO, I'd stay with FOS/FIS/RAF completely out of this business and not change 
them anymore. Those are legacy APIs!

I'd suggest to add this to StandardOpenOptions 
(https://docs.oracle.com/javase/8/docs/api/java/nio/file/StandardOpenOption.html)
 and use it solely with the Java 7+ NIO.2 Path APIs. No need to change the 
old-style java.io.File based APIs. This is easy to implement and add, because 
you would only add the new Enum constant and then implement it in the default 
FileSystem(-Provider) for each platform.

Uwe

-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer Bremen, Germany 
http://lucene.apache.org/

> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On 
> Behalf Of Andrew Haley
> Sent: Sunday, August 28, 2016 12:23 PM
> To: Lu, Yingqi ; core-libs-dev@openjdk.java.net
> Cc: Kaczmarek, Eric 
> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
> 
> On 26/08/16 23:31, Lu, Yingqi wrote:
> 
> > The proposal adds 4 API methods to java/io/FileInputStream.java, 
> > java/io/OutputStream.java to enable the feature. In addition, it add 
> > O_DIRECT with two more modes "ro" (read-only and direct) and "rwo"
> > (read-write and direct) to java/io/RandomAccessFile.java.
> >
> > public FileInputStream(String name, boolean direct) throws
> FileNotFoundException
> 
> Adding a boolean for O_DIRECT does not scale well.  There are many 
> other flags, and if there is some future expansion it would mean 
> adding more boolean arguments to the call signature.  It might be 
> worth considering a more direct way to make the call to open(2).  I 
> appreciate that not every flag passed to open() makes sense, though.
> And there is Windows etc. to think about.  But something like
> 
>   new FileInputStream(filename, File.DIRECT | File.APPEND)
> 
> is much more scalable and involves less argument marshalling.
> 
> Andrew.

RE: Proposal for adding O_DIRECT support into JDK 9

[Uwe Schindler]

Hi,

IMHO, I'd stay with FOS/FIS/RAF completely out of this business and not change 
them anymore. Those are legacy APIs!

I'd suggest to add this to StandardOpenOptions 
(https://docs.oracle.com/javase/8/docs/api/java/nio/file/StandardOpenOption.html)
 and use it solely with the Java 7+ NIO.2 Path APIs. No need to change the 
old-style java.io.File based APIs. This is easy to implement and add, because 
you would only add the new Enum constant and then implement it in the default 
FileSystem(-Provider) for each platform.

Uwe

-
Uwe Schindler
uschind...@apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
> Behalf Of Andrew Haley
> Sent: Sunday, August 28, 2016 12:23 PM
> To: Lu, Yingqi ; core-libs-dev@openjdk.java.net
> Cc: Kaczmarek, Eric 
> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
> 
> On 26/08/16 23:31, Lu, Yingqi wrote:
> 
> > The proposal adds 4 API methods to java/io/FileInputStream.java,
> > java/io/OutputStream.java to enable the feature. In addition, it add
> > O_DIRECT with two more modes "ro" (read-only and direct) and "rwo"
> > (read-write and direct) to java/io/RandomAccessFile.java.
> >
> > public FileInputStream(String name, boolean direct) throws
> FileNotFoundException
> 
> Adding a boolean for O_DIRECT does not scale well.  There are many
> other flags, and if there is some future expansion it would mean
> adding more boolean arguments to the call signature.  It might be
> worth considering a more direct way to make the call to open(2).  I
> appreciate that not every flag passed to open() makes sense, though.
> And there is Windows etc. to think about.  But something like
> 
>   new FileInputStream(filename, File.DIRECT | File.APPEND)
> 
> is much more scalable and involves less argument marshalling.
> 
> Andrew.

Re: Proposal for adding O_DIRECT support into JDK 9

[Andrew Haley]

On 26/08/16 23:31, Lu, Yingqi wrote:

> The proposal adds 4 API methods to java/io/FileInputStream.java,
> java/io/OutputStream.java to enable the feature. In addition, it add
> O_DIRECT with two more modes "ro" (read-only and direct) and "rwo"
> (read-write and direct) to java/io/RandomAccessFile.java.
> 
> public FileInputStream(String name, boolean direct) throws 
> FileNotFoundException

Adding a boolean for O_DIRECT does not scale well.  There are many
other flags, and if there is some future expansion it would mean
adding more boolean arguments to the call signature.  It might be
worth considering a more direct way to make the call to open(2).  I
appreciate that not every flag passed to open() makes sense, though.
And there is Windows etc. to think about.  But something like

  new FileInputStream(filename, File.DIRECT | File.APPEND)

is much more scalable and involves less argument marshalling.

Andrew.