On 8/15/18 5:10 PM, mandy chung wrote:
I think we should remove the ExceptionInInitializerError::getCause
method and have getException to return getCause(). I think the
simplest is to keep the exception field and make sure it's set
with the cause. Existing version of EIIE always has null
On 8/15/18 3:20 PM, Peter Levart wrote:
Hi Mandy,
Just a question. Why does "private Throwable exception" field in
ExceptionInInitializerError exist? Was it there before there was a
"cause" in Throwable and later still remained there because of
serialization format? Would it be possible
ping?
-- Igor
> On Aug 10, 2018, at 1:44 PM, Igor Ignatyev wrote:
>
> http://cr.openjdk.java.net/~iignatyev//8209386/webrev.00/index.html
>> 4 lines changed: 1 ins; 0 del; 3 mod;
>
> Hi all,
>
> could you please review this small fix for the error detected in
> jdk.internal.ed by
Hi Mandy,
Just a question. Why does "private Throwable exception" field in
ExceptionInInitializerError exist? Was it there before there was a
"cause" in Throwable and later still remained there because of
serialization format? Would it be possible to "simulate" its effect for
serialization
ExceptionInInitializerError(Throwable cause) sets the detail message to
null. It'd be helpful to include a detail message rather than null
as in Throwable(Throwable cause) that constructs a new throwable
with a default message cause==null ? null : cause.toString().
This would help
http://cr.openjdk.java.net/~iignatyev//8209549/webrev.00/index.html
> 2 lines changed: 0 ins; 0 del; 2 mod;
Hi all,
could you please review this tiny patch which removes unused (and actually
non-existed) file from requires.extraPropDefns and simplifies paths in
requires.extraPropDefns and
You can remove all comments you like. If you do not distribute the resulting
binaries you do not need to provide the changes/source you made (that’s a legal
requirement from the GPL license). If you do need to provide source (because
you distribute binaries) then you have to retain at least all
The javadoc comments in public API are a requirement in OpenJDK and can
not be removed. This is the OpenJDK project policy. If you want to
extend OpenJDK you have to add the comments. And not only comments. New
public API may be added to OpenJDK only after passing the special
process called
Hi Roger,
Filed JDK-8209542: "Serialization discussion of enum types should
mention java.lang.Enum."
Thanks for the review,
-Joe
On 8/15/2018 6:20 AM, Roger Riggs wrote:
Hi Joe,
This change looks fine as the spec for serializing Enum's is in OIS
and OOS.
However, the spec for
On 08/15/2018 07:16 PM, Peter Levart wrote:
On 08/15/2018 05:49 PM, dalibor topic wrote:
On 06.08.2018 20:21, mr rupplin wrote:
Three problems that I run into when running the 'make jdk' after
minor work on the System.java class for JNI and custom JDK:
On 08/15/2018 05:49 PM, dalibor topic wrote:
On 06.08.2018 20:21, mr rupplin wrote:
Three problems that I run into when running the 'make jdk' after
minor work on the System.java class for JNI and custom JDK:
java/lang/memory/GroupListener.java:111:
Can we get explanations for each of
Hi Adam,
This fix is JDK 8u only and so you will need to request for 8u approval.
The proposed empty static method is fine with me. Please fix the format
and indentation before you post the review.
Since this patch is small, you can inline the diff in the RFR mail.
I can review it when you
On 06.08.2018 20:21, mr rupplin wrote:
Three problems that I run into when running the 'make jdk' after minor work on
the System.java class for JNI and custom JDK:
java/lang/memory/GroupListener.java:111:
Can we get explanations for each of these?
No.
There is no java.lang.memory in
Hi Mandy, Hans,
Tried out the below (after removing my previous fix, the volatile
compare), and it appears to solve the problem just fine.
If I generate a webrev and get it attached to the bug, would one of you
mind approving the change?
--...at the end of getBundleImpl in jdk8
Hi Mandy, Hans,
Tried out the below (after removing my previous fix, the volatile
compare), and it appears to solve the problem just fine.
If I generate a webrev and get it attached to the bug, would one of you
mind approving the change?
--...at the end of getBundleImpl in jdk8
Can you explain how to remove the requirement for comments in the OpenJDK build
in the Java source files? It's really killing my schedule to have to reinsert
comments by hand.
Thanks.
Max R.
Software Developer
Your change is still approved, but ...
All tests are a little white-box in the sense that they are guided by where
bugs are likely to be found, which comes from experience with
implementations. There is a collection of timed waiting APIs in the JDK
that throw InterruptedException. It would be
Hi Martin,
ok, as a reliable pattern I see that to avoid knowing details of the
implementation.
But the self interrupt seems redundant if the other is needed.
Updated:
http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/
Thanks, Roger
On 8/14/2018 6:14 PM, Martin Buchholz wrote:
Hi Joe,
This change looks fine as the spec for serializing Enum's is in OIS and OOS.
However, the spec for serializing Enum's in ObjectInputStream and
ObjectOutputStream is incomplete.
It does not mention that the class of the Enum is written to the stream
before the enum name.
Please file
Looks good Joe
On Aug 14, 2018, at 11:20 PM, joe darcy wrote:
> http://cr.openjdk.java.net/~darcy/8176425.0/
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Hi Joe,
Added myself as a reviewer to the CSR and the change looks fine
On Aug 14, 2018, at 11:59 PM, joe darcy wrote:
> https://bugs.openjdk.java.net/browse/JDK-8209524
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Hi Alan,
Just a quick follow-up regarding the BufferPoolMXBean.
On 14/08/18 12:34, Andrew Dinn wrote:
> On 06/08/18 10:29, Alan Bateman wrote:
>
>> Are you familiar with BufferPoolMXBean which can be used by management
>> tools to monitor pool of buffers? I'm wondering if we should introduce a
Hi Ivan,
On 15/08/18 1:20 PM, Ivan Gerasimov wrote:
> Hi Jaikiran!
>
> The first part (the documentation clarification) was requested some
> time ago [1], so it may be eventually fixed.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-7033681
Thank you for pointing to that one. I hadn't found it
Hi Jaikiran!
The first part (the documentation clarification) was requested some time
ago [1], so it may be eventually fixed.
[1] https://bugs.openjdk.java.net/browse/JDK-7033681
With respect to the second part (throwing UOE from remove(Object)), I
agree with you that it would be more
Consider the following code:
import java.util.Arrays;
import java.util.List;
public class ArraysAsListTest {
public static void main(final String[] args) throws Exception {
final List someList = Arrays.asList(new String[] {"a"});
System.out.println("Removed? " +
25 matches
Mail list logo
