Re: RFR: 8186009 tools launcher test AddExportsAndOpensInManifest.java fails intermittently: AccessDeniedException

[Alan Bateman]

On 26/01/2018 00:19, Andrey Nazarov wrote:

Screenshot with new layout 
http://cr.openjdk.java.net/~anazarov/JDK-8186009/Screen%20Shot%202018-01-25%20at%2015.40.15.png

CR: http://cr.openjdk.java.net/~anazarov/JDK-8186009/webrev.04/ 


Looks okay to me (although I'm not a fan of using @BeforeMethod in this 
way).


-Alan

[JDK 11] RFR 8196211: Move two sun/nio/cs tests into OpenJDK

[Amy Lu]

Please review the patch to move two sun/nio/cs tests into OpenJDK.

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

Thanks,
Amy

Re: [PATCH] Inefficient ArrayList.subList().toArray()

[Martin Buchholz]

Yes.

public Object[] toArray() {
checkForComodification();
return Arrays.copyOfRange(root.elementData, offset, offset +
size);
}

@SuppressWarnings("unchecked")
public  T[] toArray(T[] a) {
checkForComodification();
if (a.length < size)
return (T[]) Arrays.copyOfRange(
root.elementData, offset, offset + size,
a.getClass());
System.arraycopy(root.elementData, offset, a, 0, size);
if (a.length > size)
a[size] = null;
return a;
}

It's still possible to find simple performance improvements in classes like
ArrayList.

On Thu, Jan 25, 2018 at 4:41 PM, John Rose  wrote:

> On Jan 25, 2018, at 2:02 PM, Сергей Цыпанов 
> wrote:
> >
> > +return (T[]) Arrays.copyOfRange(root.elementData,
> offset, size, a.getClass());
>
>
> Giving this a quick glance:
> I think you may want s/size/offset+size/.
> There should be calls to checkForComodification.
>
>

Re: [11] RFR JDK-8196127: Dead code in VersionProps.java.template

[mandy chung]

I like code deletion!
Mandy

On 1/25/18 6:24 PM, David Holmes wrote:

Wow that was fast! :)

Looks good.

Thanks,
David

On 26/01/2018 5:33 AM, mandy chung wrote:

Trivial fix to remove unused isHeadless variable.

$ hg diff 
src/java.base/share/classes/java/lang/VersionProps.java.template
diff --git 
a/src/java.base/share/classes/java/lang/VersionProps.java.template 
b/src/java.base/share/classes/java/lang/VersionProps.java.template

--- a/src/java.base/share/classes/java/lang/VersionProps.java.template
+++ b/src/java.base/share/classes/java/lang/VersionProps.java.template
@@ -166,15 +166,8 @@
   * Print version info.
   */
  private static void print(boolean err, boolean newln) {
-    boolean isHeadless = false;
  PrintStream ps = err ? System.err : System.out;

-    /* Report that we're running headless if the property is 
true */

-    String headless = System.getProperty("java.awt.headless");
-    if ( (headless != null) && 
(headless.equalsIgnoreCase("true")) ) {

-    isHeadless = true;
-    }
-
  /* First line: platform version. */
  if (err) {
  ps.println(launcher_name + " version \"" + java_version 
+ "\""


Mandy

RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

[Joe Wang]

Hi,

Adding methods for comparing CharSequence, StringBuilder, and StringBuffer.

The Comparable implementations for StringBuilder/Buffer are similar to 
that of String, allowing comparison operations between two 
StringBuilders/Buffers, e.g. 
aStringBuilder.compareTo(anotherStringBuilder). For CharSequence 
however, refer to the comments in JIRA, a static method 'compare' is 
added instead of implementing the Comparable interface. This 'compare' 
method may take CharSequence implementations such as String, 
StringBuilder and StringBuffer, making it possible to perform comparison 
among them. The previous example for example is equivalent to 
CharSequence.compare(aStringBuilder, anotherStringBuilder).


Tests for java.base have been independent from each other. The new tests 
are therefore created to have no dependency on each other or sharing any 
code.


JBS: https://bugs.openjdk.java.net/browse/JDK-8137326
webrev: http://cr.openjdk.java.net/~joehw/jdk11/8137326/webrev/

Thanks,
Joe

Re: [11] RFR JDK-8196127: Dead code in VersionProps.java.template

[David Holmes]

Wow that was fast! :)

Looks good.

Thanks,
David

On 26/01/2018 5:33 AM, mandy chung wrote:

Trivial fix to remove unused isHeadless variable.

$ hg diff src/java.base/share/classes/java/lang/VersionProps.java.template
diff --git 
a/src/java.base/share/classes/java/lang/VersionProps.java.template 
b/src/java.base/share/classes/java/lang/VersionProps.java.template

--- a/src/java.base/share/classes/java/lang/VersionProps.java.template
+++ b/src/java.base/share/classes/java/lang/VersionProps.java.template
@@ -166,15 +166,8 @@
   * Print version info.
   */
  private static void print(boolean err, boolean newln) {
-    boolean isHeadless = false;
  PrintStream ps = err ? System.err : System.out;

-    /* Report that we're running headless if the property is true */
-    String headless = System.getProperty("java.awt.headless");
-    if ( (headless != null) && (headless.equalsIgnoreCase("true")) ) {
-    isHeadless = true;
-    }
-
  /* First line: platform version. */
  if (err) {
  ps.println(launcher_name + " version \"" + java_version + 
"\""


Mandy

Re: [PATCH] Inefficient ArrayList.subList().toArray()

[John Rose]

On Jan 25, 2018, at 2:02 PM, Сергей Цыпанов  wrote:
> 
> +return (T[]) Arrays.copyOfRange(root.elementData, offset, 
> size, a.getClass());


Giving this a quick glance:
I think you may want s/size/offset+size/.
There should be calls to checkForComodification.

Re: Oracle Java 8u161 regression in XML Schema Factory

[Krystal Mok]

Hi guys,

A coworker of mine had hit this issue last night on 8u161 and it worked
fine on 8u151:

ERROR: 
/home/myuser/.cache/bazel/_bazel_myuser/some_hash_code/external/jackson_datatype_joda_shaded/BUILD:5:1:
Building
external/jackson_datatype_joda_shaded/libjackson-datatype-joda-class.jar
(35 source files) failed (Exit 1)
java.lang.InternalError: Cannot find requested resource bundle for locale
en_US
at
com.sun.tools.javac.util.JavacMessages.getBundles(JavacMessages.java:128)
at
com.sun.tools.javac.util.JavacMessages.getLocalizedString(JavacMessages.java:147)
at
com.sun.tools.javac.util.JavacMessages.getLocalizedString(JavacMessages.java:140)
at com.sun.tools.javac.util.Log.localize(Log.java:788)
at com.sun.tools.javac.util.Log.printLines(Log.java:586)
at
com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:170)
at
com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:96)
at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:90)
at
com.google.devtools.build.buildjar.javac.BlazeJavacMain.compile(BlazeJavacMain.java:105)
at
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder$1.invokeJavac(SimpleJavaLibraryBuilder.java:106)
at
com.google.devtools.build.buildjar.ReducedClasspathJavaLibraryBuilder.compileSources(ReducedClasspathJavaLibraryBuilder.java:53)
at
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.compileJavaLibrary(SimpleJavaLibraryBuilder.java:109)
at
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:117)
at
com.google.devtools.build.buildjar.BazelJavaBuilder.processRequest(BazelJavaBuilder.java:105)
at
com.google.devtools.build.buildjar.BazelJavaBuilder.runPersistentWorker(BazelJavaBuilder.java:67)
at
com.google.devtools.build.buildjar.BazelJavaBuilder.main(BazelJavaBuilder.java:45)
Caused by: java.util.MissingResourceException: Can't find bundle for base
name com.google.errorprone.errors, locale en_US
at
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1573)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:854)
at
com.sun.tools.javac.util.JavacMessages.lambda$add$0(JavacMessages.java:106)
at
com.sun.tools.javac.util.JavacMessages.getBundles(JavacMessages.java:125)
... 15 more

Resource bundle loading issue...could that be related to this XML issue
here?

Thanks,
Kris

On Thu, Jan 25, 2018 at 8:41 AM, Seán Coffey  wrote:

> On 25/01/2018 11:58, Bernd wrote:
>
> Hello,
>>
>> some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and
>> u162) but work with 8u152.
>>
>> I cant reproduce the fault in a stand-alone program so it seems to be
>> related to classloader/reflection magic of those tools, sorry.
>>
>> Is this a regression of 8159240
>>  (not public?)
>>
> Fixes in the CPU releases are kept private - hence the above bug is not
> public. The changesets do become public once the release is made public
> though. See : http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/06086cb6c34
> 9
>
> I don't think it's a factor for what you're seeing.
>
> Classes nearer to those below were touched via JDK-8186080: Transform XML
> interfaces
> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/cb84156d54b2
> http://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/08a44c164993
>
> This may be connected with some tools trying to redefine the classes
> perhaps. Needs more investigating. Perhaps the XMLSchemaLoader changes are
> a factor ?
>
> regards,
> Sean.
>
>
>> Here is the stacktrace anyway:
>>
>> com.sun.org.apache.xerces.internal.impl.dv.DVFactoryException: Schema
>> factory class
>> com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl does
>> not
>> extend from SchemaDVFactory.
>>  at
>> com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.
>> getInstance(SchemaDVFactory.java:75)
>>  at
>> com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.
>> getInstance(SchemaDVFactory.java:57)
>>  at
>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.
>> reset(XMLSchemaLoader.java:1024)
>>  at
>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.
>> loadGrammar(XMLSchemaLoader.java:556)
>>  at
>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.
>> loadGrammar(XMLSchemaLoader.java:535)
>>  at
>> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchema
>> Factory.newSchema(XMLSchemaFactory.java:254)
>>  at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.
>> java:638)
>>  at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.
>> java:654)
>>  at
>> com.seeburger.api.test.helpers.BuilderTestHelper.getCRSchema
>> Validator(BuilderTestHelper.java:57)
>>

Re: [PATCH] Inefficient ArrayList.subList().toArray()

[Martin Buchholz]

Thanks, Сергей
I filed a bug for you
https://bugs.openjdk.java.net/browse/JDK-8196207

On Thu, Jan 25, 2018 at 2:02 PM, Сергей Цыпанов 
wrote:

> Hi,
>
> I've run into poor performance of toArray() method called on result of
> subList() taken from java.util.ArrayList.
>
> Consider simple benchmark:
>
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-XX:+UseParallelGC", "-Xms1g", "-Xmx1g"})
> public class SubListToArrayBenchmark {
>
> @Benchmark
> public Integer[] list_typeChecked(Data holder) {
> return holder.list.toArray(new Integer[0]);
> }
>
> @Benchmark
> public Integer[] subList_typeChecked(Data holder) {
> return holder.list.subList(0, holder.size).toArray(new Integer[0]);
> }
>
> @State(Scope.Thread)
> public static class Data {
> ArrayList list;
>
> @Param({"0", "10", "100", "1000"})
> int size;
>
> @Setup
> public void setup() {
> list = IntStream
> .range(0, size)
> .boxed()
> .collect(toCollection(ArrayList::new));
> }
> }
> }
>
>
> With Java 1.8.0_162 on my PC (Intel i5-4690 3,5 GHz) it yields these
> results:
>
> Benchmark(size)  Mode  Cnt Score Error  Units
> list_typeChecked 0  avgt   504,630 ±0,062
> ns/op
> list_typeChecked   10  avgt   50  16,629 ±0,140  ns/op
> list_typeChecked 100  avgt   50  79,783 ±1,676  ns/op
> list_typeChecked   1000  avgt   50742,757 ±  10,357  ns/op
>
> subList_typeChecked  0  avgt   50  11,833 ±0,801  ns/op
> subList_typeChecked10  avgt   50  42,713 ±0,590  ns/op
> subList_typeChecked  100  avgt   50197,336 ±3,560  ns/op
> subList_typeChecked1000  avgt   50  1765,187 ±  19,729  ns/op
>
> With Java 9 subList performs slightly better but still much worse than
> list.
>
>
> Despite the fact that amount of data transfered from list to array is the
> same for both methods there's a huge difference in absolute values.
>
> Instantiation of SubList costs in average only 9.591 ± 0.650  ns and is
> independent on the size of its source so it couldn't be root cause.
>
> Here SubLists taken from ArrayList calls AbstractCollection.toArray()
> method while implementing RandomAccess and being array-based by its nature.
> Array-based ArrayList provides efficient implementation of toArray(T[])
> and we can apply the same approach for ArrayList.SubList.
>
> Here's the patch for JDK 9:
>
> 
> 
> 
>
> diff --git a/src/java.base/share/classes/java/util/ArrayList.java
> b/src/java.base/share/classes/java/util/ArrayList.java
> --- a/src/java.base/share/classes/java/util/ArrayList.java
> +++ b/src/java.base/share/classes/java/util/ArrayList.java
> @@ -1363,6 +1363,20 @@
>  }
>  };
>  }
> +
> +public Object[] toArray() {
> +return Arrays.copyOfRange(root.elementData, offset, size);
> +}
> +
> +@SuppressWarnings("unchecked")
> +public  T[] toArray(T[] a) {
> +if (a.length < size)
> +return (T[]) Arrays.copyOfRange(root.elementData,
> offset, size, a.getClass());
> +System.arraycopy(root.elementData, offset, a, 0, size);
> +if (a.length > size)
> +a[size] = null;
> +return a;
> +}
>  }
>
>  /**
>
> 
> 
> 
>
> Best regards,
> Sergey Tsypanov
>

Re: RFR: 8186009 tools launcher test AddExportsAndOpensInManifest.java fails intermittently: AccessDeniedException

[Andrey Nazarov]

Screenshot with new layout 
http://cr.openjdk.java.net/~anazarov/JDK-8186009/Screen%20Shot%202018-01-25%20at%2015.40.15.png

CR: http://cr.openjdk.java.net/~anazarov/JDK-8186009/webrev.04/ 


—Thanks,
Andrei

> On 25 Jan 2018, at 16:05, Andrey Nazarov  wrote:
> 
> Hi,
> 
> Could you review fix in launcher tests. Fix changes “file.jar” name to unique 
> name for every test case. It eliminates dependency between test cases on the 
> file.
> 
> http://cr.openjdk.java.net/~anazarov/JDK-8186009/webrev.03 
> 
> 
> https://bugs.openjdk.java.net/browse/JDK-8186009 
> 
> 
> —Andrei

RFR: 8186009 tools launcher test AddExportsAndOpensInManifest.java fails intermittently: AccessDeniedException

[Andrey Nazarov]

Hi,

Could you review fix in launcher tests. Fix changes “file.jar” name to unique 
name for every test case. It eliminates dependency between test cases on the 
file.

http://cr.openjdk.java.net/~anazarov/JDK-8186009/webrev.03 


https://bugs.openjdk.java.net/browse/JDK-8186009 


—Andrei

Re: [PATCH] Inefficient ArrayList.subList().toArray()

[Krystal Mok]

Hi Sergey,

Not a Reviewer but I like this patch a lot. Thanks for contributing it to
OpenJDK!

Best regards,
Kris

On Thu, Jan 25, 2018 at 2:02 PM, Сергей Цыпанов 
wrote:

> Hi,
>
> I've run into poor performance of toArray() method called on result of
> subList() taken from java.util.ArrayList.
>
> Consider simple benchmark:
>
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-XX:+UseParallelGC", "-Xms1g", "-Xmx1g"})
> public class SubListToArrayBenchmark {
>
> @Benchmark
> public Integer[] list_typeChecked(Data holder) {
> return holder.list.toArray(new Integer[0]);
> }
>
> @Benchmark
> public Integer[] subList_typeChecked(Data holder) {
> return holder.list.subList(0, holder.size).toArray(new Integer[0]);
> }
>
> @State(Scope.Thread)
> public static class Data {
> ArrayList list;
>
> @Param({"0", "10", "100", "1000"})
> int size;
>
> @Setup
> public void setup() {
> list = IntStream
> .range(0, size)
> .boxed()
> .collect(toCollection(ArrayList::new));
> }
> }
> }
>
>
> With Java 1.8.0_162 on my PC (Intel i5-4690 3,5 GHz) it yields these
> results:
>
> Benchmark(size)  Mode  Cnt Score Error  Units
> list_typeChecked 0  avgt   504,630 ±0,062
> ns/op
> list_typeChecked   10  avgt   50  16,629 ±0,140  ns/op
> list_typeChecked 100  avgt   50  79,783 ±1,676  ns/op
> list_typeChecked   1000  avgt   50742,757 ±  10,357  ns/op
>
> subList_typeChecked  0  avgt   50  11,833 ±0,801  ns/op
> subList_typeChecked10  avgt   50  42,713 ±0,590  ns/op
> subList_typeChecked  100  avgt   50197,336 ±3,560  ns/op
> subList_typeChecked1000  avgt   50  1765,187 ±  19,729  ns/op
>
> With Java 9 subList performs slightly better but still much worse than
> list.
>
>
> Despite the fact that amount of data transfered from list to array is the
> same for both methods there's a huge difference in absolute values.
>
> Instantiation of SubList costs in average only 9.591 ± 0.650  ns and is
> independent on the size of its source so it couldn't be root cause.
>
> Here SubLists taken from ArrayList calls AbstractCollection.toArray()
> method while implementing RandomAccess and being array-based by its nature.
> Array-based ArrayList provides efficient implementation of toArray(T[])
> and we can apply the same approach for ArrayList.SubList.
>
> Here's the patch for JDK 9:
>
> 
> 
> 
>
> diff --git a/src/java.base/share/classes/java/util/ArrayList.java
> b/src/java.base/share/classes/java/util/ArrayList.java
> --- a/src/java.base/share/classes/java/util/ArrayList.java
> +++ b/src/java.base/share/classes/java/util/ArrayList.java
> @@ -1363,6 +1363,20 @@
>  }
>  };
>  }
> +
> +public Object[] toArray() {
> +return Arrays.copyOfRange(root.elementData, offset, size);
> +}
> +
> +@SuppressWarnings("unchecked")
> +public  T[] toArray(T[] a) {
> +if (a.length < size)
> +return (T[]) Arrays.copyOfRange(root.elementData,
> offset, size, a.getClass());
> +System.arraycopy(root.elementData, offset, a, 0, size);
> +if (a.length > size)
> +a[size] = null;
> +return a;
> +}
>  }
>
>  /**
>
> 
> 
> 
>
> Best regards,
> Sergey Tsypanov
>

[PATCH] Inefficient ArrayList.subList().toArray()

[Сергей Цыпанов]

Hi,

I've run into poor performance of toArray() method called on result of 
subList() taken from java.util.ArrayList.

Consider simple benchmark:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(jvmArgsAppend = {"-XX:+UseParallelGC", "-Xms1g", "-Xmx1g"})
public class SubListToArrayBenchmark {

@Benchmark
public Integer[] list_typeChecked(Data holder) {
return holder.list.toArray(new Integer[0]);
}

@Benchmark
public Integer[] subList_typeChecked(Data holder) {
return holder.list.subList(0, holder.size).toArray(new Integer[0]);
}

@State(Scope.Thread)
public static class Data {
ArrayList list;

@Param({"0", "10", "100", "1000"})
int size;

@Setup
public void setup() {
list = IntStream
.range(0, size)
.boxed()
.collect(toCollection(ArrayList::new));
}
}
}


With Java 1.8.0_162 on my PC (Intel i5-4690 3,5 GHz) it yields these results:

Benchmark(size)  Mode  Cnt Score Error  Units
list_typeChecked 0  avgt   504,630 ±0,062  ns/op
list_typeChecked   10  avgt   50  16,629 ±0,140  ns/op
list_typeChecked 100  avgt   50  79,783 ±1,676  ns/op
list_typeChecked   1000  avgt   50742,757 ±  10,357  ns/op

subList_typeChecked  0  avgt   50  11,833 ±0,801  ns/op
subList_typeChecked10  avgt   50  42,713 ±0,590  ns/op
subList_typeChecked  100  avgt   50197,336 ±3,560  ns/op
subList_typeChecked1000  avgt   50  1765,187 ±  19,729  ns/op

With Java 9 subList performs slightly better but still much worse than list.


Despite the fact that amount of data transfered from list to array is the same 
for both methods there's a huge difference in absolute values.

Instantiation of SubList costs in average only 9.591 ± 0.650  ns and is 
independent on the size of its source so it couldn't be root cause.

Here SubLists taken from ArrayList calls AbstractCollection.toArray() method 
while implementing RandomAccess and being array-based by its nature.
Array-based ArrayList provides efficient implementation of toArray(T[]) and we 
can apply the same approach for ArrayList.SubList.

Here's the patch for JDK 9:



diff --git a/src/java.base/share/classes/java/util/ArrayList.java 
b/src/java.base/share/classes/java/util/ArrayList.java
--- a/src/java.base/share/classes/java/util/ArrayList.java
+++ b/src/java.base/share/classes/java/util/ArrayList.java
@@ -1363,6 +1363,20 @@
 }
 };
 }
+
+public Object[] toArray() {
+return Arrays.copyOfRange(root.elementData, offset, size);
+}
+
+@SuppressWarnings("unchecked")
+public  T[] toArray(T[] a) {
+if (a.length < size)
+return (T[]) Arrays.copyOfRange(root.elementData, offset, 
size, a.getClass());
+System.arraycopy(root.elementData, offset, a, 0, size);
+if (a.length > size)
+a[size] = null;
+return a;
+}
 }
 
 /**



Best regards,
Sergey Tsypanov

Re: [11] RFR JDK-8196127: Dead code in VersionProps.java.template

[Lance Andersen]

+1
> On Jan 25, 2018, at 2:33 PM, mandy chung  wrote:
> 
> Trivial fix to remove unused isHeadless variable.
> 
> $ hg diff src/java.base/share/classes/java/lang/VersionProps.java.template
> diff --git a/src/java.base/share/classes/java/lang/VersionProps.java.template 
> b/src/java.base/share/classes/java/lang/VersionProps.java.template
> --- a/src/java.base/share/classes/java/lang/VersionProps.java.template
> +++ b/src/java.base/share/classes/java/lang/VersionProps.java.template
> @@ -166,15 +166,8 @@
>   * Print version info.
>   */
>  private static void print(boolean err, boolean newln) {
> -boolean isHeadless = false;
>  PrintStream ps = err ? System.err : System.out;
> 
> -/* Report that we're running headless if the property is true */
> -String headless = System.getProperty("java.awt.headless");
> -if ( (headless != null) && (headless.equalsIgnoreCase("true")) ) {
> -isHeadless = true;
> -}
> -
>  /* First line: platform version. */
>  if (err) {
>  ps.println(launcher_name + " version \"" + java_version + "\""
> 
> Mandy

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: [11] RFR JDK-8196127: Dead code in VersionProps.java.template

[Paul Sandoz]

+1

Paul.

> On Jan 25, 2018, at 11:33 AM, mandy chung  wrote:
> 
> Trivial fix to remove unused isHeadless variable.
> 
> $ hg diff src/java.base/share/classes/java/lang/VersionProps.java.template
> diff --git a/src/java.base/share/classes/java/lang/VersionProps.java.template 
> b/src/java.base/share/classes/java/lang/VersionProps.java.template
> --- a/src/java.base/share/classes/java/lang/VersionProps.java.template
> +++ b/src/java.base/share/classes/java/lang/VersionProps.java.template
> @@ -166,15 +166,8 @@
>   * Print version info.
>   */
>  private static void print(boolean err, boolean newln) {
> -boolean isHeadless = false;
>  PrintStream ps = err ? System.err : System.out;
> 
> -/* Report that we're running headless if the property is true */
> -String headless = System.getProperty("java.awt.headless");
> -if ( (headless != null) && (headless.equalsIgnoreCase("true")) ) {
> -isHeadless = true;
> -}
> -
>  /* First line: platform version. */
>  if (err) {
>  ps.println(launcher_name + " version \"" + java_version + "\""
> 
> Mandy

[11] RFR JDK-8196127: Dead code in VersionProps.java.template

[mandy chung]

Trivial fix to remove unused isHeadless variable.

$ hg diff src/java.base/share/classes/java/lang/VersionProps.java.template
diff --git 
a/src/java.base/share/classes/java/lang/VersionProps.java.template 
b/src/java.base/share/classes/java/lang/VersionProps.java.template

--- a/src/java.base/share/classes/java/lang/VersionProps.java.template
+++ b/src/java.base/share/classes/java/lang/VersionProps.java.template
@@ -166,15 +166,8 @@
  * Print version info.
  */
 private static void print(boolean err, boolean newln) {
-    boolean isHeadless = false;
 PrintStream ps = err ? System.err : System.out;

-    /* Report that we're running headless if the property is true */
-    String headless = System.getProperty("java.awt.headless");
-    if ( (headless != null) && (headless.equalsIgnoreCase("true")) ) {
-    isHeadless = true;
-    }
-
 /* First line: platform version. */
 if (err) {
 ps.println(launcher_name + " version \"" + java_version + "\""

Mandy

Re: [11] RFR JDK-8168682: jdk/test/java/lang/ClassLoader/forNameLeak/ClassForNameLeak.java fails with -Xcomp

[Brent Christian]

Hi, Mandy

Interesting problem.  Your changes look fine.

(The static finals could be all caps, but I wouldn't bother with further 
changes just for that.)


Thanks,
-Brent

On 1/24/18 10:15 AM, mandy chung wrote:

This patch revises the test to make the phantom reference reachable
in order to ensure that the reference is enqueued for verification.

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8168682/webrev.00/

thanks
Mandy

Re: RFR 8139206: Add InputStream readNBytes(int len)

[Brian Burkhalter]

I have moved the CSR [1] back to Draft and updated it according to the content 
of webrev.03. If there are no more comments by tomorrow I will move it once 
again to Finalized. After that, once the CSR has been re-approved, then if 
there are no further comments on the changes I will go ahead and push the fix, 
assuming there are no unexpected failures in rerunning the regression tests.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8194956

On Jan 24, 2018, at 1:06 PM, Roger Riggs  wrote:

> +1
> 
> On 1/24/2018 2:50 PM, Brian Burkhalter wrote:
>> On Jan 23, 2018, at 4:50 PM, Brian Burkhalter  
>> wrote:
>> 
>>> On Jan 23, 2018, at 1:19 AM, Weijun Wang  wrote:
>>> 
 + * Therefore, the method may be safely called with very large values 
 of
 + * {@code len} provided sufficient memory is available.
 
 What does "sufficient memory" mean? For len, or the number of available 
 bytes?
>>> 
>>> It means enough bytes for the collectivity of the intermediate and returned 
>>> buffers. This is already stated to be proportional to ‘len’.
>> 
>> All right, to make sure this horse is truly dead here’s one more revision. 
>> The changes with respect to the previous revision are [1] and the overall 
>> changes versus the SCM base are [2]. The .02-.03 differences are:
>> 
>> A) Add an @implNote at line 368.
>> B) Minor memory use improvement at line 392.
>> 
>> Thanks,
>> 
>> Brian
>> 
>> [1] http://cr.openjdk.java.net/~bpb/8139206/webrev.02-03/
>> [2] http://cr.openjdk.java.net/~bpb/8139206/webrev.03/

Re: Oracle Java 8u161 regression in XML Schema Factory

[Seán Coffey]

On 25/01/2018 11:58, Bernd wrote:


Hello,

some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and
u162) but work with 8u152.

I cant reproduce the fault in a stand-alone program so it seems to be
related to classloader/reflection magic of those tools, sorry.

Is this a regression of 8159240
 (not public?)
Fixes in the CPU releases are kept private - hence the above bug is not 
public. The changesets do become public once the release is made public 
though. See : http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/06086cb6c349


I don't think it's a factor for what you're seeing.

Classes nearer to those below were touched via JDK-8186080: Transform 
XML interfaces

http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/cb84156d54b2
http://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/08a44c164993

This may be connected with some tools trying to redefine the classes 
perhaps. Needs more investigating. Perhaps the XMLSchemaLoader changes 
are a factor ?


regards,
Sean.


Here is the stacktrace anyway:

com.sun.org.apache.xerces.internal.impl.dv.DVFactoryException: Schema
factory class
com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl does not
extend from SchemaDVFactory.
 at
com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.getInstance(SchemaDVFactory.java:75)
 at
com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.getInstance(SchemaDVFactory.java:57)
 at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.reset(XMLSchemaLoader.java:1024)
 at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:556)
 at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:535)
 at
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:254)
 at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638)
 at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:654)
 at
com.seeburger.api.test.helpers.BuilderTestHelper.getCRSchemaValidator(BuilderTestHelper.java:57)
 at
com.seeburger.api.test.helpers.BuilderTestHelper.validateAndCompare(BuilderTestHelper.java:73)
 at
com.seeburger.api.test.KSMBuilderTest.testDeletePGP(KSMBuilderTest.java:196)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:68)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:310)
 at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:89)
 at
org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:97)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:294)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:127)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:82)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:282)
 at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:87)
 at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:50)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:207)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:146)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
 at
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
 at
org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
 at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:122)
 at
org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:106)
 at
org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
 at
org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:59)
   

Oracle Java 8u161 regression in XML Schema Factory

[Bernd]

Hello,

some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and
u162) but work with 8u152.

I cant reproduce the fault in a stand-alone program so it seems to be
related to classloader/reflection magic of those tools, sorry.

Is this a regression of 8159240
 (not public?)

Here is the stacktrace anyway:

com.sun.org.apache.xerces.internal.impl.dv.DVFactoryException: Schema
factory class
com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl does not
extend from SchemaDVFactory.
at
com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.getInstance(SchemaDVFactory.java:75)
at
com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.getInstance(SchemaDVFactory.java:57)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.reset(XMLSchemaLoader.java:1024)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:556)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:535)
at
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:254)
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638)
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:654)
at
com.seeburger.api.test.helpers.BuilderTestHelper.getCRSchemaValidator(BuilderTestHelper.java:57)
at
com.seeburger.api.test.helpers.BuilderTestHelper.validateAndCompare(BuilderTestHelper.java:73)
at
com.seeburger.api.test.KSMBuilderTest.testDeletePGP(KSMBuilderTest.java:196)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:68)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:310)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:89)
at
org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:97)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:294)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:127)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:82)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:282)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:50)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:207)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:146)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
at
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
at
org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
at
org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:122)
at
org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:106)
at
org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
at
org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:59)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207)

on the classpath jaxb-impl-2.2.5.jar but the specific packages are only
loaded from rt.jar and redefined. I asume the later is done by Powermock.

Line 611: