On 8 Feb 2016, at 07:02, Stuart Marks wrote:
> On 2/5/16 4:54 PM, David Holmes wrote:
>> Regardless of whether I agree with this API or not, it does, as Stuart points
>> out, require a JEP and to go through the normal rigorous process of
>> determining
>> whether an API is suitable for inclusion
> On 6 Feb 2016, at 14:29, Tagir F. Valeev wrote:
>
> Hello!
>
> PS> I still disagree and pushing back on the support for splitting
> PS> after partial traversal. It’s not a pattern i think we should
> PS> encourage and propagate so such behaviour can be generally relied
> PS> upon, and predomi
On 8 Feb 2016, at 06:27, Alan Bateman wrote:
>
> On 07/02/2016 22:20, Peter Levart wrote:
>> :
>>
>> If the decision to remove sun.misc.Cleaner was partly influenced by the
>> desire to maintain just 2 instead of 3 Cleaner(s), then my proposal to
>> migrate JDK code to the public API might e
On 7 Feb 2016, at 19:01, Jeremy Manson wrote:
> Hadoop seems to use sun.misc.Cleaner:
>
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hadoop/hadoop-common/2.7.1/org/apache/hadoop/crypto/CryptoStreamUtils.java
There is an issue in the Hadoop JIRA tracking this:
https://issues.
Is there an option to fall back to the older v.1.2.8 implementation if
necessary ? It would certainly alleviate issues for any applications
that might run into issues with the latest and greatest zlib libraries.
JDK-8133206 would be one such example.
Regards,
Sean.
On 05/02/2016 18:55, Xuemin
On 08/02/2016 10:42, Seán Coffey wrote:
Is there an option to fall back to the older v.1.2.8 implementation if
necessary ? It would certainly alleviate issues for any applications
that might run into issues with the latest and greatest zlib
libraries. JDK-8133206 would be one such example.
Jus
On 08/02/2016 07:02, Stuart Marks wrote:
On 2/5/16 4:54 PM, David Holmes wrote:
Regardless of whether I agree with this API or not, it does, as
Stuart points
out, require a JEP and to go through the normal rigorous process of
determining
whether an API is suitable for inclusion in the Java
> On 1 Feb 2016, at 19:45, Martin Buchholz wrote:
>
> After much debate on what to do when CompleteableFuture.whenComplete
> encounters an exception in both the source and the action, we chose
> what was acceptable to the most people - add the action's exception to
> the source exception as a su
On 02/08/2016 07:27 AM, Alan Bateman wrote:
On 07/02/2016 22:20, Peter Levart wrote:
:
If the decision to remove sun.misc.Cleaner was partly influenced by
the desire to maintain just 2 instead of 3 Cleaner(s), then my
proposal to migrate JDK code to the public API might enable Oracle to
r
Miran,
JDK-8056152 added a new constructor to java.lang.Thread for constructing
Threads that do not inherit inheritable thread-local initial values. All usages
of sun.misc.ManagedLocalsThread in the base module were also replaced
with this new constructor. Given there is now a supported API for cr
On 02/08/2016 10:33 AM, Chris Hegarty wrote:
On 8 Feb 2016, at 06:27, Alan Bateman wrote:
On 07/02/2016 22:20, Peter Levart wrote:
:
If the decision to remove sun.misc.Cleaner was partly influenced by the desire
to maintain just 2 instead of 3 Cleaner(s), then my proposal to migrate JDK
Low hanging fruit to avoid unnecessary allocations when deserializing.
readUTF knows the string size ahead of the read and can avoid
expandCapacity() by constructing the StringBuilder with the expected size.
It is an implementation detail, but if the size is larger than
Integer.MAX_VALUE,
then O
Gentle Reminder!
On 2/5/2016 6:48 PM, Paul Sandoz wrote:
On 29 Jan 2016, at 12:43, shilpi rastogi wrote:
Hi All,
Please review the updated patch-
http://cr.openjdk.java.net/~srastogi/8138578/webrev.01/
I verified Lookup.unreflectSpecial() also throws
java.lang.IllegalAccessException so upd
Gentle Reminder!
On 2/5/2016 9:18 PM, Vladimir Ivanov wrote:
Proposed fix looks good.
Quoting John: "The use of erased types (any ref => Object) in the MH
runtime is an artifact of bootstrapping difficulties, early in the
project. I hope it is not necessary any more."
Best regards,
Vladimir
Looks good.
Best regards,
Vladimir Ivanov
On 1/29/16 3:43 PM, shilpi rastogi wrote:
Hi All,
Please review the updated patch-
http://cr.openjdk.java.net/~srastogi/8138578/webrev.01/
I verified Lookup.unreflectSpecial() also throws
java.lang.IllegalAccessException so updated the JavaDoc.
Than
On 2016-02-05 21:50, Alan Bateman wrote:
On 05/02/2016 18:55, Xueming Shen wrote:
Hi
Please help codereview the change to build the jdk9 runtime to use
the system zlib on
Solaris and Linux platforms by default.
Issue: https://bugs.openjdk.java.net/browse/JDK-8031767
Webrev: http://cr.openjdk
Hello!
PS> 188 public Spliterator trySplit() {
PS> 189 if (isParallel && !finished) {
PS> 190 init();
PS> 191
PS> 192 if (buffer != null && buffer.count() > 0) // partial
traversal started
PS> 193 return null;
PS> Why
Hi Tagir,
It’s certainly easier to review if one avoids the temptation to change other
things at the same time :-)
There is a possible simplified approach to sharing one Spliterator impl between
ArrayList and ArrayList.SubList. The initial (origin, fence) for ArrayList can
be (0, -1) and Array
> On 8 Feb 2016, at 14:53, Tagir F. Valeev wrote:
>
> Hello!
>
> PS> 188 public Spliterator trySplit() {
> PS> 189 if (isParallel && !finished) {
> PS> 190 init();
> PS> 191
> PS> 192 if (buffer != null && buffer.count() > 0) // partial
Hi all,
Could someone review this fix?
Thanks,
Yuji
2016-02-04 2:27 GMT+09:00 KUBOTA Yuji :
> Hi all,
>
> Could someone please review and sponsor this fix ?
> I write the details of this issue again. Please review it.
>
> =Problem=
> Potential infinite waiting at TCPChannel#createConnection.
>
>
Hello!
PS> Would you mind updating the date in the license headers and the
PS> test with the bug id. Then i will push. I forgot to tell you about
PS> those little things, see the following for one of your fixes i
PS> pushed with such updates (to avoid any email/review latency):
Ah, sorry. I saw t
Hello!
Sorry, I don't understand how passing AbstractList would help. We
still need direct access to the elementData array of the original
ArrayList for efficiency, and this field is also late-binding, so we
need to have a reference to the ArrayList as well even in SubList
case. SubList reference
> On 8 Feb 2016, at 15:23, Tagir F. Valeev wrote:
>
> Hello!
>
> PS> Would you mind updating the date in the license headers and the
> PS> test with the bug id. Then i will push. I forgot to tell you about
> PS> those little things, see the following for one of your fixes i
> PS> pushed with su
> On 8 Feb 2016, at 15:53, Tagir F. Valeev wrote:
>
> Hello!
>
> Sorry, I don't understand how passing AbstractList would help.
Yeah, sorry ignore what i sad about AbstractList, was not thinking properly in
my attempt to unify.
> We
> still need direct access to the elementData array of the
It was suggested to me off-list that the implementation should choose a
reasonable initial capacity value ,to size the StringBuilder, rather than
the value read from the stream ( in case of bad or corrupt data ). So the
proposed changes are:
diff --git a/src/java.base/share/classes/java/io/Object
Receiving some feedback off list, this code needs to be able to run on
older releases, so the new Thread constructor, added in JDK 9, should
be accessed reflectively. Webrev updated in-place:
http://cr.openjdk.java.net/~chegar/8148861/
-Chris.
On 8 Feb 2016, at 10:52, Chris Hegarty wrote:
> M
Hi all,
lower-case thumbs up, and I'll be happy to sponsor this push.
Best,
Michael
> Am 08.02.2016 um 14:26 schrieb Vladimir Ivanov :
>
> Looks good.
>
> Best regards,
> Vladimir Ivanov
>
> On 1/29/16 3:43 PM, shilpi rastogi wrote:
>> Hi All,
>>
>> Please review the updated patch-
>>
>> h
> On Feb 8, 2016, at 8:20 AM, Chris Hegarty wrote:
>
> Receiving some feedback off list, this code needs to be able to run on
> older releases, so the new Thread constructor, added in JDK 9, should
> be accessed reflectively. Webrev updated in-place:
>
> http://cr.openjdk.java.net/~chegar/81488
Hi,
I would not (did not) see this as significant but given the discussion
I'll break it down into two independent updates:
1) for JEP 260, clone the s.m.Signal Api into a JDK internal package
for use with
java.lang.Terminator and jshell with s.m.Signal layered on top
that will end up
And of course, this should read...
> On 8 Feb 2016, at 15:34, Chris Hegarty wrote:
>
> It was suggested to me off-list that the implementation should choose a
> reasonable initial capacity value ,to size the StringBuilder, rather than
> the value read from the stream ( in case of bad or corrupt
On 09.02.2016 00:40, Chris Hegarty wrote:
> And of course, this should read...
>
>
>> On 8 Feb 2016, at 15:34, Chris Hegarty wrote:
>>
>> It was suggested to me off-list that the implementation should choose a
>> reasonable initial capacity value ,to size the StringBuilder, rather than
>> the va
> On Feb 4, 2016, at 7:52 PM, Mandy Chung wrote:
>
>
>> On Feb 4, 2016, at 2:37 PM, Hans Boehm wrote:
>>
>> The discussion at https://bugs.openjdk.java.net/browse/JDK-8052260
>> correctly points out that the spec implies that this should be true if the
>> reference has ever been enqueued, whil
Out of curiousity, what class loader is using to define
org.apache.river.api.security.CombinerSecurityManager?
Mandy
> On Feb 7, 2016, at 1:54 AM, Peter wrote:
>
> Thanks Peter & David,
>
> That's good to know.
>
> I've altered the SecurityManager to perform a permission check prior to
> be
On Mon, Feb 8, 2016 at 2:09 AM, Paul Sandoz wrote:
>
>> On 1 Feb 2016, at 19:45, Martin Buchholz wrote:
>>
>> After much debate on what to do when CompleteableFuture.whenComplete
>> encounters an exception in both the source and the action, we chose
>> what was acceptable to the most people - add
Hi Yuji,
Not sure who would look at this so cc'ing net-dev.
Also note that contributions can only be accepted if presented via
OpenJKDK infrastructure. Links to patches on
http://icedtea.classpath.org are not acceptable. The patch needs to be
included in the email (beware stripped attachments
Why not, just prior to instantiating an object just prior to deserializing, add
each class' ProtectionDomain in the objects hierarchy to an
AccessControlContext and pass this to the SecurityManager's two argument
checkPermission call?
This permission could never be granted to a principal, it is
Hi David,
Thank you for your advice and cc-ing!
I do not have any role yet, so I paste my patches as below.
diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
--- a/src/java.rmi/share/classes/sun/rmi/tr
Hello!
This is a request to help review a fix for the problem which can lead to
memory leakage under some rare circumstances.
The fix itself is quite simple - it just makes sure the handler being
released is also removed from the set of tracked handlers.
I've also augmented an existing regres
38 matches
Mail list logo
