Hi Christoph
Many thanks for your effort!
It's really better than the old version! However I have 2 comments although I
am not a reviewer(as you often stated :))
1. we could also write java code to copy/delete JDK.
2. 8169827 is to track PropertiesTest failed in copying JDK intermittently. I
su
On Mon, Jan 23, 2017 at 11:37 PM, Luke Hutchison
wrote:
> On Mon, Jan 23, 2017 at 11:21 PM, Luke Hutchison
> wrote:
>
>> That looks like a variation of the classic class initialization deadlock
>>> problem. Your main thread is blocked in es.submit(callable).get(); while
>>> still within the stat
On Mon, Jan 23, 2017 at 11:21 PM, Luke Hutchison
wrote:
> That looks like a variation of the classic class initialization deadlock
>> problem. Your main thread is blocked in es.submit(callable).get(); while
>> still within the static initializer of the LambdaBug class. If the executor
>> thread a
On Mon, Jan 23, 2017 at 10:48 PM, David Holmes
wrote:
> On 24/01/2017 2:41 PM, Luke Hutchison wrote:
>
>> If you run the code below, the active JVM thread (in the ExecutorService)
>> locks up when the lambda expression is called. The Eclipse debugger is not
>> able to stop the locked-up thread, o
Hi Luke,
On 24/01/2017 2:41 PM, Luke Hutchison wrote:
If you run the code below, the active JVM thread (in the ExecutorService)
locks up when the lambda expression is called. The Eclipse debugger is not
able to stop the locked-up thread, or get a stacktrace beyond the call into
the lambda.
Tha
+1
Mandy
> On Jan 23, 2017, at 2:07 PM, Naoto Sato wrote:
>
> More concise version:
>
> --- a/src/java.base/share/classes/java/util/ResourceBundle.java
> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java
> @@ -972,7 +972,9 @@
> * equivalent to calling {@link #getBundle(Strin
If you run the code below, the active JVM thread (in the ExecutorService)
locks up when the lambda expression is called. The Eclipse debugger is not
able to stop the locked-up thread, or get a stacktrace beyond the call into
the lambda.
The problem seems to be that some part of the Java 8 lambda s
Hi Hamlin,
Thanks for tackling this one.
On 23/01/2017 4:38 PM, Hamlin Li wrote:
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8171142
webrev: http://cr.openjdk.java.net/~mli/8171142/webrev.00/
As I commented in the bug report, and as Roger also ment
+1
Paul.
> On 23 Jan 2017, at 14:29, Peter Levart wrote:
>
> Hi,
>
> I have a fix for intermittently failing test that I created recently:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8173201_PublicMethodsTest.fix/webrev.01/
>
> The test has been found to fail with a strange compilation
+1
/Claes
On 2017-01-23 23:29, Peter Levart wrote:
Hi,
I have a fix for intermittently failing test that I created recently:
http://cr.openjdk.java.net/~plevart/jdk9-dev/8173201_PublicMethodsTest.fix/webrev.01/
The test has been found to fail with a strange compilation error:
https://b
Hi,
I have a fix for intermittently failing test that I created recently:
http://cr.openjdk.java.net/~plevart/jdk9-dev/8173201_PublicMethodsTest.fix/webrev.01/
The test has been found to fail with a strange compilation error:
https://bugs.openjdk.java.net/browse/JDK-8173201
...which is ju
More concise version:
--- a/src/java.base/share/classes/java/util/ResourceBundle.java
+++ b/src/java.base/share/classes/java/util/ResourceBundle.java
@@ -972,7 +972,9 @@
* equivalent to calling {@link #getBundle(String, Locale,
ClassLoader)
* getBundle(baseName, targetLocale, module
Hi Gunnar,
Annotations went into the platform way back in Java SE 5.0, with a GA
during 2004. When working on repeating annotations, I was surprised to
find there weren't stronger ordering guarantees for annotations from
core reflection. However, requests to tighten this aspect of the
platfor
OK, I will clarify the method description of getBundle(String, Locale,
Module) as follows:
diff -r 290145dc2c96
src/java.base/share/classes/java/util/ResourceBundle.java
--- a/src/java.base/share/classes/java/util/ResourceBundle.java
+++ b/src/java.base/share/classes/java/util/ResourceBundle.j
Hi Daniel,
your fix looks good, pretty straightforward, +1.
A minor thing,
src/java.xml/share/classes/com/sun/xml/internal/stream/EventFilterSupport.java:
67 while (super.hasNext()){
As you are touching this line, you could add a blank between ')' and '{'.
Disclaimer: I'm no reviewer.
Hi Ramanand,
test/tools/launcher/LauncherMessageTest.java
1)
116 String[] commands = {"java", "--module-path", modules.getPath(),
117 "-m", "mod.b/pkgB.ClassB"};
The execution PATH may or may not contain the JAVA_HOME_UNDER_TEST/bin,
so the right "java" may not be picked up
Hi,
I would keep the main, it is handy to debug the test standalone. (It
will still need testng.jar).
$02, Roger
On 1/23/17 3:24 PM, Aleks Efimov wrote:
Hi Daniel, Lance,
It looks like Assert.assertEquals(String actual, String expected,
String message) suites better and lines 73-77 can be
Hi Aleks,
> On Jan 23, 2017, at 3:24 PM, Aleks Efimov wrote:
>
> Hi Daniel, Lance,
>
> It looks like Assert.assertEquals(String actual, String expected, String
> message) suites better and lines 73-77 can be replaced with:
> assertEquals(sb.toString(), SMOKE, "Smoke test failed" ).
Yep, that
Hi Daniel, Lance,
It looks like Assert.assertEquals(String actual, String expected, String
message) suites better and lines 73-77 can be replaced with:
assertEquals(sb.toString(), SMOKE, "Smoke test failed" ).
And do we really need 'main' here? All test methods are annotated with
@Test tags al
Hi Alan,
Thank you for the review.
My comments are inline and Webrev is updated here:
http://cr.openjdk.java.net/~rpatil/8167063/webrev.01/
Change Summary:
- Removed SecurityException handling
- Updated the error message in launcher.properties
- Removed loadModuleMainClass0 method and moved the c
Hi Daniel,
thanks for checking/reviewing. So I'll submit with removing the ProblemList.txt
entry and I'll also remove the intermittent flag.
Sounds fair to check later if problems will still show up. Although I have the
feeling that the issue of https://bugs.openjdk.java.net/browse/JDK-8147431
Hi Daniel,
The changes look fine.
Did you give any consideration to using assertFalse in the smokeTest at line
73?
Probably want to consider a back port at some point to 8u when time permits.
Best
Lance
> On Jan 23, 2017, at 12:48 PM, Daniel Fuchs wrote:
>
> Hi,
>
> Please find below a fix
> On Jan 23, 2017, at 9:14 AM, Naoto Sato wrote:
>
> http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
>
>>
>> The fix is to reinstate the code that has been removed with 8171189,
>> with modification to load implementations with ServiceLoader.load()
>> method. That way, SPI implementations
> On 23 Jan 2017, at 03:04, Alan Bateman wrote:
>
>
>
> On 20/01/2017 23:48, Paul Sandoz wrote:
>> Hi,
>>
>> Please review this small clarification to the specification of
>> URLClassLoader for multi-release jars.
>>
>>
> This looks okay to me. One suggestion is to move this paragraph up t
Hi,
Please find below a fix for:
8173111: Excessive recursion in EventFilterSupport when filtering
over large number of XML events can cause StackOverflow
https://bugs.openjdk.java.net/browse/JDK-8173111
The fix is almost trivial: it replaces a recursion by a loop in
two places.
http:
Correct link to the changes:
http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
Naoto
On 1/23/17 9:13 AM, Naoto Sato wrote:
Hi,
Please review the changes for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8172365
The proposed fix is located at:
http://cr.openjdk.java.net/~
Hi,
Please review the changes for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8172365
The proposed fix is located at:
http://cr.openjdk.java.net/~rgoel/JDK-8167273/webrev.05/
The fix is to reinstate the code that has been removed with 8171189,
with modification to load impl
Hi Christoph,
Thanks for fixing this test!
I imported your patch, modified ProblemList.txt to not skip the test,
and sent it through our test system, and I'm happy to report that
the test was run on all available platforms with no failure.
So I think you should simply remove the line from Probl
Hi Vitaly,
There probably is something that can be done to avoid the deadlock.
ProcessExited may need to use a different lock.
Please file an issue.
Roger
On 1/20/2017 5:14 PM, Vitaly Davidovich wrote:
Hi all,
Just wanted to revisit this issue again. I haven't filed a JBS entry
for it, p
Hi Hamlin,
test/javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java:
line 130: trivial, but please add a space in "!=null"...
Note: on Windows there is no difference between Process.destroy vs
Process.destroyForcibly,
but on Linux it it is the difference between kill -15 and kill -9.
On 20/01/2017 23:48, Paul Sandoz wrote:
Hi,
Please review this small clarification to the specification of URLClassLoader
for multi-release jars.
This looks okay to me. One suggestion is to move this paragraph up to
before the two paragraphs on security so that the statement on
supporting
Looks good to me Paul.
-Chris.
On 20/01/17 23:48, Paul Sandoz wrote:
Hi,
Please review this small clarification to the specification of URLClassLoader
for multi-release jars.
Thanks,
Paul.
diff -r 467b3b7aeb1b src/java.base/share/classes/java/net/URLClassLoader.java
--- a/src/java.base/shar
Hi,
while working on jaxp changes and running jtreg tests I found that test
javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh does not work. I then saw
that this was already reported with bug 8169827. But, as I had already spent
some time to fix this test I'd like to contribute my fix:
Bug:
On 22/01/2017 19:27, Xueming Shen wrote:
The assumption is the remove of the version tag can help us to easily
get the
diffs from the webrev directly in future upgrade.
Here is the webrev with the diff by listing old and new files in a
webrev list file.
http://cr.openjdk.java.net/~sherman/8
Build changes look good. Thanks!
/Erik
On 2017-01-21 21:41, Xueming Shen wrote:
Erik, Alan
Here is the webrev that dropped the version number from the name.
http://cr.openjdk.java.net/~sherman/8173140/webrev
Thanks,
Sherman
On 1/21/17, 12:30 AM, Erik Joelsson wrote:
Hello,
Build changes
35 matches
Mail list logo
