Ping for review.
(or should I withdraw this change and leave the set LC_ALL related tests
as shell script tests as they are?)
Thanks,
Amy
On 6/7/17 2:14 PM, Amy Lu wrote:
java/nio/charset/Charset/default.sh
java/nio/charset/coders/CheckSJISMappingProp.sh
java/nio/file/Path/MacPathTest.java w
Hi,
please review a minor patch to add @key intermittent to
java/lang/ProcessHandle/OnExitTest.java. It has been observed to be
failing intermittently on Solaris x64.
Bug: https://bugs.openjdk.java.net/browse/JDK-8182321
Patch:
diff -r d6e163b08d8c test/java/lang/ProcessHandle/OnExitTes
Hi Felix,
Thank you for your suggestions.
But I think it's just a java wrapper around a shell, not a real java.
Thank you
-Hamlin
On 2017/6/16 9:41, Felix Yang wrote:
Hi Hamlin,
I think you need something like:
/ProcessTools.executeCommand("sh", "-c", yourTestCmd).../
yourTestCmd i
Hi Naoto,
Thank you for comments.
By searching I found out others have the similar issues when trying to
replace LC_ALL with file.encoding/sun.jnu.encoding, they're accessing
file names. That means LC_ALL is IMPORTANT. So I think it's better for
me to keep the shell test for now.
Thank you
java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh
Please review this patch to refactor the shell test to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8181309
webrev: http://cr.openjdk.java.net/~amlu/8181309/webrev.00/
Thanks,
Amy
Hi Hamlin,
I think you need something like:
/ProcessTools.executeCommand("sh", "-c", yourTestCmd).../
yourTestCmd is like the original cmd in shell "
export LC_ALL=en_US.UTF-8 ;${TESTJAVA}/bin/java ${TESTVMOPTS} -cp ${TESTCLASSES}
MacPathTest"
-Felix
On 2017/6/16 9:32, Naoto Sato wrote:
Hi Hamlin,
What I meant was that setting the java locale either through
Locale.setDefault() or user.language/user.country properties won't
affect the default encoding determination. Other properties
(file.encoding/sun.jnu.encoding) would set the default, but I am not
sure how they are suppose
Hi Naoto,
Thank you for comments.
Do you mean there is no way to set encoding through system property or
java API? And can I understand it as it's better to keep the shell test
rather than convert it to java test.
Thank you
-Hamlin
On 2017/6/16 0:45, Naoto Sato wrote:
Hi,
Setting the de
On 2017-06-15 18:50, Alan Bateman wrote:
On 15/06/2017 17:26, Chris Hegarty wrote:
:
Claes,
This is the first test in the core area that will now use a test
specific native library, which will need to be built ( by the build
system, which it does ), and pointed to when executing jtreg
from
Thanks Mandy.
Pushed with the following description as we discussed offline:
The interfaces and classes in this package came from Document Object
Model (DOM) Level 3 XPath Specification, Working Draft 20 August 2002.
Refer to Document Object Model (DOM) Level 3 XPath Specification,
Version 1.0
> On Jun 15, 2017, at 10:28 AM, huizhe wang wrote:
>
> Hi Mandy,
>
> Removed the change to module-info.java. While adding a description that the
> xpath package was from a working draft, I felt compelled to mention the
> latest specification. So essentially going back to your previous suggest
Hey Alan,
Thanks. We'd been tossing that around in the list of possibilities, but
hadn't gotten far enough to think about whether it would be easier or not.
My initial thought in this general direction was to write a JVMTI agent
that takes a list of JAR files as arguments. It then does two thin
Hi Mandy,
Removed the change to module-info.java. While adding a description that
the xpath package was from a working draft, I felt compelled to mention
the latest specification. So essentially going back to your previous
suggestion, explaining the difference between the working draft and the
On 15/06/2017 17:26, Chris Hegarty wrote:
:
Claes,
This is the first test in the core area that will now use a test
specific native library, which will need to be built ( by the build
system, which it does ), and pointed to when executing jtreg
from the command line, e.g.
jtreg ...
-nativepa
Hi,
Setting the default Java Locale and/or user.* properties has nothing to
do with the default encoding. The default encoding on mac/unix
environments is determined from the environment variable LC_CTYPE.
Naoto
On 6/14/17 8:35 PM, Hamlin Li wrote:
On 2017/6/15 1:22, Alan Bateman wrote:
O
> On 15 Jun 2017, at 14:29, Claes Redestad wrote:
> ...
> http://cr.openjdk.java.net/~redestad/8181147/jdk.06/
Claes,
This is the first test in the core area that will now use a test
specific native library, which will need to be built ( by the build
system, which it does ), and pointed to when
On 6/15/17, 6:29 AM, Claes Redestad wrote:
Hi Sherman,
One nick picking is that it might be better to initialize the
constant "LATIN1" from the String class
when intializing String_coder_ID? recently I got a "naked constants"
complain #JDK-8156530, so
I guess it might be better to do so at y
Hi Sherman,
On 06/15/2017 05:27 AM, Xueming Shen wrote:
Hi Claes,
The change looks fine. Yes, encoding the 2-byete latin1 at native
looks reasonable.
Thanks for reviewing!
One nick picking is that it might be better to initialize the constant
"LATIN1" from the String class
when intializi
On 15/06/2017 01:00, Jeremy Manson wrote:
:
The upshot is that, in the same way as we would have turned on the big
kill switch by default to ease the transition, we are also likely to
implement -Xbootclasspath/p to ease the transition.
You might find it easier to add --patch-module to your JDK
19 matches
Mail list logo
