/corba/webrev.00/
--
Sebastian
On 10/27/2015 05:32 AM, Sebastian Sickelmann wrote:
> Hello,
>
> Actually I am searching through the JBS for low hanging fruits.
> Right now i am looking through the openjdk-sources and try to evaluate
> if i can make something about JDK-5108778.
>
discussion-threads in
the subtask.
Please cc me, if someone wants to start discussion/review on those.
--
Sebastian
On 11/08/2015 01:50 PM, Sebastian Sickelmann wrote:
> Hi,
>
> i wanted to start a discussion/review-process some time ago, see the
> second-try below.
>
> Is there so
://mail.openjdk.java.net/pipermail/net-dev/2015-November/009308.html
On 10/27/2015 05:32 AM, Sebastian Sickelmann wrote:
> Hello,
>
> Actually I am searching through the JBS for low hanging fruits.
> Right now i am looking through the openjdk-sources and try to evaluate
> if i can make something ab
Hello,
Actually I am searching through the JBS for low hanging fruits.
Right now i am looking through the openjdk-sources and try to evaluate
if i can make something about JDK-5108778.
Please find my webrevs for the jaxp, jaxws and corba repos at:
http://cr.openjdk.java.net/~sebastian/5108778/ja
On 10/09/2015 08:58 PM, Stuart Marks wrote:
> On 10/9/15 4:16 AM, Aleksey Shipilev wrote:
>> Please note that "static final Boolean myBool = new
>> Boolean(true).booleanValue()" is a spec-recommended way to avoid binary
>> incompatibilities caused by conditional compilation. See JLS 13.4.9.
>> Ther
On 10/08/2015 08:58 PM, Stuart Marks wrote:
> On 10/7/15 12:59 PM, Sebastian Sickelmann wrote:
>> http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/
>>
>> jdk:
>> The Boolean constructors are @Deprecated now so that we get
>> compile-warnings
Hello,
Actually I am searching through the JBS for low hanging fruits.
Right now i am looking through the openjdk-sources and try to evaluate
if i can make something about JDK-5108778.
Please find my webrevs for the jdk, jaxp, jaxws and corba repos at:
http://cr.openjdk.java.net/~sebastian/51087
Hi,
while looking through some bugs in JBS I found this[1] one.
It seems to be that it is already solved. I tried the submitted example
with jdk6,7,8 and
it seems that it works since jdk7.
So maybe the bug can be closed, like the one it relates to
JDK-5056544 javax.swing.timer stops afte
probably have the effect of removing
> surprise effects like this one, as we continue to extend the JVM
> linkage rules.
>
>
> On Dec 2, 2013, at 1:42 PM, Sebastian Sickelmann
> mailto:sebastian.sickelm...@gmx.de>> wrote:
>
>> Hi,
>>
>> some days ago i
Hi,
some days ago i had written[0] that i maybe found a bug in access
verification in MethodHandles.Lookup.
Now i produces webrev's for the two repos jdk and hotspot.
In the jdk webrev [1] I implemented some additional tests.
In the hotspot webrev [2] I tried to fix the wrong behavior. I am not
// easy check; all self-access is OK
which skips any further checking.
Should we file a bug for this?
-- Sebastian
[2] which should be the declaring class. But in this example it isn't.
Am 26.11.2013 18:44, schrieb Sebastian Sickelmann:
> Hi,
>
> A few days ago I
43692695/oss-patches/openjdk8/MethodHandles.Lookup/hgexport_0.txt
Am 26.11.2013 03:03, schrieb John Rose:
> On Nov 24, 2013, at 2:08 AM, Sebastian Sickelmann
> mailto:sebastian.sickelm...@gmx.de>> wrote:
>
>> I am sorry. Due to a configuration failure in my IDE had run with
Am 26.12.2011 12:38, schrieb Weijun Wang:
On 12/26/2011 05:39 PM, Sebastian Sickelmann wrote:
Hi,
one week ago (2011-12-15) [0] i asked for the downsides of changing
the legacy Exceptions in core-libs. There where only one answer from
"/Weijun Wang" who said that there may be ser
For my Pre New Years Eve event[0] (Close simple open loops)
i'am searching a sponsor for this change[1].
It introduces longer exception-chains while using RuntimeException.
-- Sebastian
[0]
http://codingwizard.wordpress.com/2011/12/26/closing-simple-open-loops-to-new-years-eve/
[1]
http://dl
Am 26.12.2011 17:25, schrieb Sebastian Sickelmann:
For my Pre New Years Eve event[0] (Close simple open loops)
i'am searching a sponsor for this change[1].
It introduces longer exception-chains while using RuntimeException.
-- Sebastian
[0]
http://codingwizard.wordpress.com/2011/
Hi,
one week ago (2011-12-15) [0] i asked for the downsides of changing the
legacy Exceptions in core-libs.
There where only one answer from "/Weijun Wang" who said that there may
be serialisation issues.
I created a webrev[1] /with the suggested change and tests. The dumps
inside the test di
Hello,
while refactoring some exceptions (support for the 4 common ctors) i
come along some
inconsistency in handling cause-chaining via initCause method. I hope we
can unify to a
compatible solution that there is only one initCause-behavior for every
Exception in JDK.
Here are the types i d
as today. Parsing does have to be fast because when there
is a security manager every checked operation will construct a
Permission to check against.
Éamonn
On 5 December 2011 07:45, Sebastian Sickelmann
wrote:
Am 05.12.2011 12:53, schrieb Weijun Wang:
On 12/03/2011 06:12 AM, Stuart Marks w
Am 09.12.2011 17:07, schrieb Sean Mullan:
On 12/6/11 3:48 PM, Sebastian Sickelmann wrote:
Am 05.12.2011 19:06, schrieb Sean Mullan:
On 12/2/11 11:02 AM, Sean Mullan wrote:
[0] Solution 1
http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html
[1
Am 05.12.2011 19:06, schrieb Sean Mullan:
On 12/2/11 11:02 AM, Sean Mullan wrote:
[0] Solution 1
http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html
[1] Solution 2
http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011
that every
other "PermissionWithActions" is using.
I will try to extract the parsing to an sun.security.PermissionParser.
Reintegration it back into an abstract base class for the PermissionWithActions
classes should be not the biggest problem.
Thanks for the input.
-- Sebastian
Éamonn
On 5 December
Java ME Mobile Media API (not in any of
the OpenJDK repositories) so it looks like the code has been copied even
more times than are visible here. Perhaps a public permissions parsing
utility method is called for.
s'marks
On 12/2/11 9:02 AM, Sebastian Sickelmann wrote:
Am 02.12.2011 16:27,
ld we try to cleanup them all. Or should we try to make some
de-duplication/code-reuse refactoring.
-- Sebastian
On 12/1/2011 10:18 PM, Sebastian Sickelmann wrote:
Hi Brandon,
i will try to work out a fix for both and cc the review request to you.
-- Sebastian
Am 01.12.2011 23:54, schrieb
Am 02.12.2011 01:22, schrieb Stuart Marks:
On 12/1/11 2:13 PM, Stuart Marks wrote:
On 12/1/11 12:38 PM, Alan Bateman wrote:
On 01/12/2011 18:35, Sebastian Sickelmann wrote:
:
Thanks Alan,
L67-68 was a backporting (from a more complex solution to a small
warning
cleanup) issue. I missed the
c the same changes you apply to
FilePermission.java to PropertyPermission.java? Or, maybe you can
apply the same changes yourself to PropertyPermission.java?
Thanks.
On 12/1/2011 8:27 AM, Sebastian Sickelmann wrote:
Am 01.12.2011 10:16, schrieb Stuart Marks:
Hi Sebastian,
Thanks for submi
Am 01.12.2011 16:12, schrieb Sean Mullan:
On 11/22/2011 11:45 PM, Sebastian Sickelmann wrote:
It's been a long time ago.
Had someone had the time to think about this:
Am 29.10.2011 13:17, schrieb Sebastian Sickelmann:
Sorry i linked the wrong webrev for Solution 3.
Am 27.10.2011
Am 01.12.2011 18:15, schrieb Alan Bateman:
On 01/12/2011 16:27, Sebastian Sickelmann wrote:
:
Thanks for the good feedback.
I splitted my change to the trivial part and will start discussion of
FilePermission change on core-libs-dev after the cleanup event.
I created a new webrev with the
]
http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000380.html
On 11/30/11 8:33 PM, Sebastian Sickelmann wrote:
Hi,
i have a webrev[0] that contains some warning cleanup for java.io
It is based on rev 7795c41ed54c http://hg.openjdk.java.net/jdk8/tl/jdk/
Some comments to the
Hi,
i have a webrev[0] that contains some warning cleanup for java.io
It is based on rev 7795c41ed54c http://hg.openjdk.java.net/jdk8/tl/jdk/
Some comments to the changes:
ExpiringCache.java: Changed anonymous inner class to inner class with
the intention to put serialversion inside of it. But
Hi,
I started some cleanup work a while ago and we got into short
discussions while cleaning-up javax.xml.crypto.
Unfortunately i got no relay for a long time. Tried to get some comments
on 2011-10-27 [1] and 2011-11-23 [2] but nobody reacted.
Maybe i have done something wrong, maybe i hav
It's been a long time ago.
Had someone had the time to think about this:
Am 29.10.2011 13:17, schrieb Sebastian Sickelmann:
Sorry i linked the wrong webrev for Solution 3.
Am 27.10.2011 16:50, schrieb Sebastian Sickelmann:
Some time ago (see below) i ask what would be the right soluti
Sorry i linked the wrong webrev for Solution 3.
Am 27.10.2011 16:50, schrieb Sebastian Sickelmann:
Some time ago (see below) i ask what would be the right solution to
refactor
exception initialization to?
Solution 1: Disallow calls to initCause after creation, if there was an
exception-cause
e may break.
-- Sebastian
Am 02.10.2011 21:49, schrieb Sebastian Sickelmann:
Am 01.10.2011 18:19, schrieb Sean Mullan:
On 9/30/11 2:15 PM, Sebastian Sickelmann wrote:
I think I know the reason. If you allow initCause to be called when a
cause is
not initially provided, then getCause will still
Am 03.10.2011 17:35, schrieb Jason Mehrens:
> What's about moving
>
> public boolean equals(Object o) {return o == this || c.equals(o);}
>
> to CheckedCollection and remove it in CheckedSet (L2394),
CheckedList (L2506)
>
> and
>
> public int hashCode() {return c.hashCode();}
>
> to CheckedColl
Am 01.10.2011 18:19, schrieb Sean Mullan:
On 9/30/11 2:15 PM, Sebastian Sickelmann wrote:
I think I know the reason. If you allow initCause to be called when a
cause is
not initially provided, then getCause will still return null, which
seems wrong.
getCause() of Throwable and all classes
Am 30.09.2011 22:20, schrieb Darryl Mocek:
Hello.
Please review this patch to add CheckedQueue to Collections. Test
case provided.
Webrev at: http://cr.openjdk.java.net/~mduigou/4533691/0/webrev/
Thanks,
Darryl
Looks good to me.
Just the @since 1.7 seems wrong for an JDK8 Patch. Should the
Am 28.09.2011 06:36, schrieb Sebastian Sickelmann:
Am 27.09.2011 17:38, schrieb Sean Mullan:
On 9/24/11 5:55 AM, Sebastian Sickelmann wrote:
Am 23.09.2011 20:54, schrieb Sean Mullan:
On 9/17/11 3:09 PM, Sebastian Sickelmann wrote:
i have updated the webrev [0].
But i think that L69 and L72
Am 27.09.2011 17:38, schrieb Sean Mullan:
On 9/24/11 5:55 AM, Sebastian Sickelmann wrote:
Am 23.09.2011 20:54, schrieb Sean Mullan:
On 9/17/11 3:09 PM, Sebastian Sickelmann wrote:
i have updated the webrev [0].
But i think that L69 and L72 of the test should be changed to
checkMutable and
Am 23.09.2011 20:54, schrieb Sean Mullan:
On 9/17/11 3:09 PM, Sebastian Sickelmann wrote:
i have updated the webrev [0].
But i think that L69 and L72 of the test should be changed to
checkMutable and the implementation of the exceptions accordantly.
That's an interesting question. The cu
Hi i created a small concept-demo how i think we can manage to remove
some flaws(public accessible fields) out of the jdk without breaking
binary-compatibility. I uploaded the "code of cencept" to my
github-incubator[0] and posted some description on my weblog[1]. It
would be nice to get some
Looks good to me.
Nice pattern to use static initialization on first usage of UnsafeHolder
instead of using lazy initialization code with double-check-ideom for
synchronizing in the two accessing methods. It should works for all vm i
have workes with (sun/oracle,ibm) , but is it garanted by vm
Sorry i have forgotten the webrev url.
http://oss-patches.24.eu/openjdk8/InternalError/part2/7084245_main_1/
Am 30.08.2011 10:20, schrieb Sebastian Sickelmann:
Am 29.08.2011 21:10, schrieb Xueming Shen:
Hi Sebastian,
I will help to push the patch, if people all agreed the changes
proposed
Am 29.08.2011 21:10, schrieb Xueming Shen:
Hi Sebastian,
I will help to push the patch, if people all agreed the changes proposed.
Thanks for supporting this.
I pulled your patch and generated the webrev at
http://cr.openjdk.java.net/~sherman/7084245/webrev
I already created a new webrev tha
Am 28.08.2011 22:54, schrieb Mario Torre:
Il giorno dom, 28/08/2011 alle 21.35 +0200, Sebastian Sickelmann ha
scritto:
Hi, here is a webrev[1] for some cleanup that i want to integrated in
tl-repositories.
Hi,
Hi created a new webrev with your suggested changes at:
http://oss-patches.24.eu
Am 29.08.2011 02:02, schrieb David Holmes:
On 29/08/2011 5:35 AM, Sebastian Sickelmann wrote:
Hi, here is a webrev[1] for some cleanup that i want to integrated in
tl-repositories.
Alan Bateman had scanned the changes and gave me some good input[3] for
further discussion here:
The changes to
Hi, i thought about what todo to enable the enhanced-for-loop for
Iterators and Enumerations.
And it seems to me that the main problem is that the used
Iterator/Enumeration should not be used in other places( it should be
"private" for the loop).
As Iterable solves this through creating a ne
Hi, here is a webrev[1] for some cleanup that i want to integrated in
tl-repositories.
Alan Bateman had scanned the changes and gave me some good input[3] for
further discussion here:
The changes to java.util.concurrent should go through Doug Lea's
upstream CVS. Alan told me that Chris Hegar
Am 28.08.2011 06:22, schrieb Dr Andrew John Hughes:
On 14:16 Tue 23 Aug , Sebastian Sickelmann wrote:
I have rebased my "additional chainings of InternalError" on your commit.
The webrev is:
http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_c43af666d130/
R
Hi,
is there someone who wants to review / support this simple warning removal?
The webrev is:
http://oss-patches.24.eu/openjdk8/Simple_Warning/
-- Sebastian*
*
Am 19.08.2011 06:50, schrieb Sebastian Sickelmann:
Am 18.08.2011 16:11, schrieb Alan Bateman:
Mandy Chung wrote:
Thumbs up from me. Are you going to include this change with
another CR that you have a fix to be pushed?
Mandy
I think it's best to separate this fix and so I've c
Am 23.08.2011 14:16, schrieb Sebastian Sickelmann:
Am 22.08.2011 21:19, schrieb Joe Darcy:
Sebastian Sickelmann wrote:
Am 17.08.2011 03:11, schrieb joe.da...@oracle.com:
Hello.
On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote:
Hi,
some time ago, i wrote[5] with Joe and David about
Am 25.08.2011 10:46, schrieb Alan Bateman:
Sebastian Sickelmann wrote:
:
I have build(make clean, make all, make images) the jdk-repo only. Or
does i have to pull in the changes of my jdk8/tl/jdk clone to my
jdk8/jdk8/jdk clone to check this?
Has someone in the past evaluated if there is a
Am 26.08.2011 13:05, schrieb Dalibor Topic:
On 8/26/11 12:59 PM, Sebastian Sickelmann wrote:
Am 26.08.2011 08:32, schrieb Peter Jones:
Public fields like RemoteException.detail, ill-advised as they may have been,
cannot be removed (would break binary compatibility).
Sorry for that. It was
Am 26.08.2011 09:22, schrieb Alan Bateman:
Sebastian Sickelmann wrote:
OK. Webrev is there:
http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/
Can someone review this?
I think this one will require careful review and I'm not even sure
that it'
Am 26.08.2011 08:32, schrieb Peter Jones:
On Aug 25, 2011, at 8:00 PM, Sebastian Sickelmann wrote:
Am 26.08.2011 00:24, schrieb Sebastian Sickelmann:
Am 26.08.2011 00:03, schrieb Sebastian Sickelmann:
I have found more places in jdk source where an Exception has a private cause
field.
share
Am 26.08.2011 00:24, schrieb Sebastian Sickelmann:
Am 26.08.2011 00:03, schrieb Sebastian Sickelmann:
I have found more places in jdk source where an Exception has a
private cause field.
share/classes/javax/management/remote/JMXProviderException.java:
private Throwable cause = null;
share
Am 25.08.2011 22:53, schrieb Dr Andrew John Hughes:
On 16:43 Thu 25 Aug , joe.da...@oracle.com wrote:
IChangeset: 624cc18a6cf9
Author:darcy
Date: 2011-08-25 09:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/624cc18a6cf9
7082727: VirtualMachineError should declare it
Looks good.
Thanks For fixing.
-- Sebastian
Joe Darcy schrieb:
>Hello.
>
>Please review the patch below to add an explicit serialVersionUID to
>VirtualMachineError:
>
>7082727 VirtualMachineError should declare its serialVersionUID
>http://cr.openjdk.java.net/~darcy/7082727.0/
>
>Tha
Am 25.08.2011 08:28, schrieb Alan Bateman:
Joe Darcy wrote:
Hi Alan.
I did check for that point in my review :-)
The VirtualMachineError class is abstract so as long as all its
subclasses declare a serialVersionUID, like InternalError does, I
think we're fine.
We need to check the serializat
I am sorry. Should have read the complete Serialization Specification. Thought
that serialversionUid is only calculated on declared non transient instance
fields. I will estimate old serialversionUid andere create a new Cr. Should we
create Regression Tests on all serializable somehow?
-- Sebast
Am 22.08.2011 21:19, schrieb Joe Darcy:
Sebastian Sickelmann wrote:
Am 17.08.2011 03:11, schrieb joe.da...@oracle.com:
Hello.
On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote:
Hi,
some time ago, i wrote[5] with Joe and David about advancing some
exception-types to the 4 standard ctors
Hi,
while making some change for using exception-chaining on
RuntimeException in more cases, i found that
javax.xml.crypto.NoSuchMechnismException had a private cause field that
isn't necessary since throwable can handle it. But just removing isn't
that simple as Alan pointed out[1].
First of
Hi,
while making some change for using exception-chaining on
RuntimeException in more cases, i found that
javax.xml.crypto.NoSuchMechnismException had a private cause field that
isn't necessary since throwable can handle it. But just removing isn't
that simple as Alan pointed out[1].
First of
Am 20.08.2011 00:04, schrieb Sebastian Sickelmann:
Am 19.08.2011 23:21, schrieb Alan Bateman:
Sebastian Sickelmann wrote:
OK. We need to change the serialversion. But is this enough? May we
break applications out there which serialized
NoSuchMechanismExceptions or extended classes? I have
Am 19.08.2011 23:21, schrieb Alan Bateman:
Sebastian Sickelmann wrote:
OK. We need to change the serialversion. But is this enough? May we
break applications out there which serialized
NoSuchMechanismExceptions or extended classes? I have compiled it
with no explicit serialversionUID and
Hi,
i sometimes get this warning if i don't execute a "make clean" before my
"make all" in jdk repository.
/home/sebastian/deve/openjdk8/build/linux-i586/j2sdk-image/bin/javac
-J-XX:ThreadStackSize=768 -J-XX:-PrintVMOptions
-J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-client -J-Xmx
Am 17.08.2011 23:31, schrieb Sebastian Sickelmann:
Ok. Rebased again.
Now the webrevs are:
http://oss-patches.24.eu/openjdk8/InternalError/part1/REBASED_ON_e59aad6ed600/
http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_e59aad6ed600/
Unfortunatly after i have uploaded the
Am 18.08.2011 22:14, schrieb Alan Bateman:
Sebastian Sickelmann wrote:
Hi,
i have created a fix for fixing Exception-Chains in case of an
rethrown RuntimeException.
I am not quite sure if this is inside the scope of what i
discussed[0][1] with Joe. But it is
fixed in the same manner as
Am 18.08.2011 16:11, schrieb Alan Bateman:
Mandy Chung wrote:
Thumbs up from me. Are you going to include this change with
another CR that you have a fix to be pushed?
Mandy
I think it's best to separate this fix and so I've created the
following to track it:
7080622: Remove varargs warn
Sorry. Does't Poster it to the list
Original-Nachricht
Betreff: Re: Request Review for small change to remove 2 warnings in rmic
Von: Sebastian Sickelmann
An: Alan Bateman
CC:
I updated my Patch so that it handles all varargs warnings in jdk subrepo.
http://oss-patch
Hi,
i have created a fix for fixing Exception-Chains in case of an rethrown
RuntimeException.
I am not quite sure if this is inside the scope of what i
discussed[0][1] with Joe. But it is
fixed in the same manner as the patches there.
http://oss-patches.24.eu/openjdk8/RuntimeException/REBAS
Am 18.08.2011 06:46, schrieb Sebastian Sickelmann:
Am 18.08.2011 00:52, schrieb Mandy Chung:
Thumbs up from me. Are you going to include this change with
another CR that you have a fix to be pushed?
I have some other improved that are reviewed by Joe actually. But
there are on a completly
parameter;
src/share/classes/sun/tools/serialver/SerialVer.java:462: warning:
non-varargs call of varargs method with inexact argument type for last
parameter;
I send in a combined webrev in shortly.
Mandy
On 8/17/11 3:45 PM, Sebastian Sickelmann wrote:
Hi while searching if i created warnings
Hi while searching if i created warnings with an change i have seen that
there are 2 warnings in rmic that are easy to remove.
Please review this hg export (no webrev unfortunately, because my
free-file-host-provider is out of service :-( )
# HG changeset patch
# User Sebastian
# Date 1313620
It breaks my webrev a did 2 minutes before my upload completed. :-(
But never mind. You are right. Removing is always a win. ;-)
Am 17.08.2011 23:14, schrieb Rémi Forax:
Hurrah, this is the changeset of the month,
removing things is always a win.
Rémi
On 08/17/2011 11:05 PM, xueming.s...@oracl
Am 17.08.2011 23:34, schrieb Alexandre Boulgakov:
On 8/17/2011 2:04 PM, Sebastian Sickelmann wrote:
Am 17.08.2011 16:58, schrieb Alexandre Boulgakov:
Hello Sebastian.
On 8/17/2011 7:43 AM, Sebastian Sickelmann wrote:
Am 17.08.2011 13:45, schrieb Alan Bateman:
joe.da...@oracle.com wrote:
I
Am 17.08.2011 16:43, schrieb Sebastian Sickelmann:
Am 17.08.2011 13:45, schrieb Alan Bateman:
joe.da...@oracle.com wrote:
I am willing to sponsor this work and I've filed bug 7080020 "Add
conventional constructors to InternalError" for it.
Thanks Joe, and to help this a
Am 17.08.2011 16:58, schrieb Alexandre Boulgakov:
Hello Sebastian.
On 8/17/2011 7:43 AM, Sebastian Sickelmann wrote:
Am 17.08.2011 13:45, schrieb Alan Bateman:
joe.da...@oracle.com wrote:
I am willing to sponsor this work and I've filed bug 7080020 "Add
conventional const
Am 17.08.2011 03:11, schrieb joe.da...@oracle.com:
Hello.
On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote:
Hi,
some time ago, i wrote[5] with Joe and David about advancing some
exception-types to the 4 standard ctors.
The first Exception i have looked at was InternalError and now(after
Hi,
after pulling from both sources
http://hg.openjdk.java.net/jdk8/tl/jdk/
http://hg.openjdk.java.net/jdk8/jdk8/jdk/
i see that i got two heads.
Is it because in all the other repositorys jdk8/*/jdk there are also
many changes to the jdk-sub-repo?
Should i worry about these changes and merge
Am 17.08.2011 13:45, schrieb Alan Bateman:
joe.da...@oracle.com wrote:
I am willing to sponsor this work and I've filed bug 7080020 "Add
conventional constructors to InternalError" for it.
Thanks Joe, and to help this along here's the webrev with Sebastian's
patches:
http://cr.openjdk.ja
Am 16.08.2011 13:35, schrieb Alan Bateman:
Sebastian Sickelmann wrote:
Hi,
some time ago, i wrote[5] with Joe and David about advancing some
exception-types to the 4 standard ctors.
The first Exception i have looked at was InternalError and now(after
some struggeling with gnumake and hg
Hi,
some time ago, i wrote[5] with Joe and David about advancing some
exception-types to the 4 standard ctors.
The first Exception i have looked at was InternalError and now(after
some struggeling with gnumake and hg) my patches for reviewing are ready.
I uploaded them at [4]
I split the c
try (XYZException e) { throw new CorrectedException(e.toString(), e);}
I think the latter one(Third++) would sometimes lead to greater discussion.
-- Sebastian
Am 09.08.2011 22:46, schrieb Joe Darcy:
Sebastian Sickelmann wrote:
Hi David,
it would be nice to have some help on this.
I started
the commiters who want to sponsor this work.
Anyone interrested in supporting/guiding?
-Sebastian
[1] https://bugs.openjdk.java.net/attachment.cgi?id=229&action=diff)
Am 08.08.2011 23:28, schrieb David Schlosnagle:
On Mon, Aug 8, 2011 at 4:57 PM, Sebastian Sickelmann
wrote:
These ones
lMessage = null;
}else {
String message = cause.getMessage();
detailMessage = (message==null ? null : cause.toString());
}
instead?
- Sebastian
Am 08.08.2011 21:18, schrieb Sebastian Sickelmann:
Thanks for encouraging me.
I opened a bug [1] at bugs.openjdk.java.ne
AM, Sebastian Sickelmann wrote:
Looks good to me.
But i have one question:
Why there are two ways to plumb the causes of an exception?
The history of this situation is covered in older versions of the
javadoc of Throwable:
http://download.oracle.com/javase/6/docs/api/java/lang
Sorry for the typo. I wanted to write.:
Should we open a new discussion on this, or is meaningless to create
better support for good old enumerations.
Sebastian Sickelmann schrieb:
>Hi,
>
>Maybe my mail [1] got lost in thread-history. But i think that Colin had
>a good idea in
Looks good to me.
But i have one question:
Why there are two ways to plumb the causes of an exception?
In many exceptions-classes you can use a constuctor-level argument
to specify the cause, and in some classes you must use the initCause method.
Is it: "When you often need a caus
Hi,
Maybe my mail [1] got lost in thread-history. But i think that Colin had
a good idea in [2].
Should we open a new discussion on this, are is meaningless to create
better support for good old enumerations.
-Sebastian
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/00
I like that idea. Should we open another discussion thread?
Colin Decker schrieb:
>One better way to handle this in Java 8 would be to have a utility method
>that takes a Supplier> SAM argument (with a no-arg method
>that returns an Enumeration) and returns an Iterable that gets a new
>Enumerat
Am 02.08.2011 21:44, schrieb Mike Duigou:
Hello All;
A fairly simple bug to review which snuck through testing.
http://cr.openjdk.java.net/~mduigou/7073296/0/webrev/
The changes to Class are incidental but so trivial that opted to include them.
I can remove if anyone feels strongly (or even w
Hi,
first of all. Your Job at invokedynamic is really awesome. I have started a
project called "mockinject" at java.net a few year ago that need to hook inside
method calls and invokedynamic will make it really easy to do it in jdk7. I got
some problem with the actual implementation some time a
Jeff Hain wrote:
> Hello.
>
> I have some remarks about the methods named in the subject (JDK 6u26, JDK
> 7b147).
>
>
> 1) AbstractCollection.removeAll(Collection)
> This method could return immediately if the specified collection is
> empty,
> not to iterate uselessly over all "this", or
94 matches
Mail list logo
