These changes are already committed in the jsr166 CVS, this is a request
to pull them into jdk8.
Specdiff has been run, and there is nothing surprising.
The doclint issues are specifically around the addition of a caption to
the tables, the remaining changes are cleanup, -> {@code ..}, etc.
Changeset: c49b538ef054
Author:chegar
Date: 2013-08-01 12:38 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c49b538ef054
8022061: More ProblemList.txt updates (7/2013)
Reviewed-by: alanb, psandoz
! test/ProblemList.txt
Changeset: cc11a0efb4f9
Author:aefimov
Date: 2013-08-01 14:59 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cc11a0efb4f9
8015987: The corba repo contains unneeded .sjava files
Reviewed-by: alanb, chegar, coffeys
- src/share/classes/com/sun/corba/se/impl/copyobject/JavaInp
Hello,
As a follow-up from Joe Darcy's proposal (2013-02-06) to add
@FunctionalInterface to some interfaces matching the requirements of
FI.
I propose that this improvement is applied to all the VM Java libs.
Doing a quick search, I've found some interfaces are not tagged as
FunctionaInterfaces
On 7/30/13 2:01 PM, Jörn Huxhorn wrote:
> See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough
> estimate about the impact of this change.
Eh, no. Try
http://code.ohloh.net/search?s=%22Reflection.getCallerClass%28%22&pp=0&fl=Java&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true
i
On Aug 1, 2013, at 8:01 AM, Dalibor Topic wrote:
> On 7/30/13 2:01 PM, Jörn Huxhorn wrote:
>> See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough
>> estimate about the impact of this change.
>
> Eh, no. Try
> http://code.ohloh.net/search?s=%22Reflection.getCallerClass%28%
On 8/1/13 3:58 PM, Nick Williams wrote:
>
> On Aug 1, 2013, at 8:01 AM, Dalibor Topic wrote:
>
>> On 7/30/13 2:01 PM, Jörn Huxhorn wrote:
>>> See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough
>>> estimate about the impact of this change.
>>
>> Eh, no. Try
>> http://code.
Changeset: 36f4cf8872f3
Author:igerasim
Date: 2013-07-30 21:11 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36f4cf8872f3
7192942: (coll) Inefficient calculation of power of two in HashMap
Reviewed-by: mduigou
! src/share/classes/java/util/HashMap.java
Changeset: 54329c24c
Changeset: d6de149b9f20
Author:xuelei
Date: 2013-08-01 07:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6de149b9f20
7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID
Reviewed-by: vinnie
! src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator
Hi Chris,
All the changes look good.
Thanks,
-Joe
On 08/01/2013 03:34 AM, Chris Hegarty wrote:
These changes are already committed in the jsr166 CVS, this is a
request to pull them into jdk8.
Specdiff has been run, and there is nothing surprising.
The doclint issues are specifically around
Some of these don't feel like "functions", e.g. Formattable, it's
unlikely that anyone would use lambda expression to instantiate them.
What is the general guideline to apply @FunctionalInterface? For
example, why should AutoCloseable be marked as @FI?
Zhong Yu
On Thu, Aug 1, 2013 at 7:28 AM, Je
Hi,
This patch fixes numerous spliterators that do not throw NPEs for null
consumers:
http://cr.openjdk.java.net/~psandoz/tl/JDK-8020016-spltr-traverse-npe/webrev/
Paul.
In StremSpliterator:366, I assume the NULL check should be before if.
There are a couple
if {
}
else if
and
try {
}
catch
Isn't the style recommended to be on the same line?
Cheers,
Henry
On Aug 1, 2013, at 8:32 AM, Paul Sandoz wrote:
> Hi,
>
> This patch fixes numerous spliterators that
On Aug 1, 2013, at 4:45 PM, Henry Jen wrote:
> In StremSpliterator:366, I assume the NULL check should be before if.
>
It saves a redundant check if the wrapping spliterator uses buffering, since
the tryAdvance will also check:
public void forEachRemaining(IntConsumer consumer) {
Changeset: cd13a4a45a37
Author:chegar
Date: 2013-08-01 16:53 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd13a4a45a37
8022087: Fix doclint issues in j.u.Deque & Queue
Reviewed-by: chegar, darcy
Contributed-by: Doug Lea
! src/share/classes/java/util/Deque.java
! src/share
On 26/07/2013 16:31, Mike Duigou wrote:
Hello all;
This patch adds some missing checks for null that, according to interface
contract, should be throwing NPE. It also improves the existing tests to check
for these cases.
http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/
The changes t
I did the Windows 8.1 Preview installation and faced with the same
problem as described in the article:
http://social.msdn.microsoft.com/forums/windowsazure/zh-tw/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200
To fix the problem, java executable modules nee
On 01/08/2013 09:06, Alexey Utkin wrote:
I did the Windows 8.1 Preview installation and faced with the same
problem as described in the article:
http://social.msdn.microsoft.com/forums/windowsazure/zh-tw/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200
To fi
I see, thanks. Looks good to me.
Cheers,
Henry
On Aug 1, 2013, at 8:49 AM, Paul Sandoz wrote:
> On Aug 1, 2013, at 4:45 PM, Henry Jen wrote:
>> In StremSpliterator:366, I assume the NULL check should be before if.
>>
>
> It saves a redundant check if the wrapping spliterator uses buffering,
On Aug 1 2013, at 09:34 , Martin Buchholz wrote:
> Overall, I hate these kinds of changes to be super-pedantically correct, at
> the cost of a small performance loss and a small compatibility hit. I
> resisted doing them when I was maintaining these classes. So there's an edge
> case where a
Looks OK to me with the clarifications in your response to Henry.
Mike
On Aug 1 2013, at 08:32 , Paul Sandoz wrote:
> Hi,
>
> This patch fixes numerous spliterators that do not throw NPEs for null
> consumers:
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8020016-spltr-traverse-npe/webrev/
Looks good to me. Thanks for incorporating the 6546713 changes.
Can we also incorporate the changes in JDK-7178639:
http://cr.openjdk.java.net/~mduigou/JDK-7178639/0/webrev/
into this changeset? It seems like an an opportune time.
Mike
On Aug 1 2013, at 03:34 , Chris Hegarty wrote:
> These ch
That was the ticket! All the tests run with this command, despite the fact that
some of them fail. Thanks!
You might want to update the readme with this command, at least as an
alternative to the one there now.
Nick
On Jul 31, 2013, at 10:12 AM, Chris Hegarty wrote:
>
> try:
> make
> PRODU
On Wed, Jul 31, 2013 at 02:38:26PM -0700, Stuart Marks wrote:
> The alternative is to add "@throws SocketException never" to the
> javadoc, just to get rid of the doclint warning, but this has the
> consequence of requiring people to keep dead code around
> indefinitely, and furthermore it requires
Hi Nick,
This topic is related to HotSpot Server Compiler instead of the Java core
library, so I'm cc'ing this email to hotspot-compiler-dev and dropping
core-libs-dev.
As you already know, HotSpot compilers are shielded from VM runtime
implementation details via the Compiler Interface (CI). That
On 7/30/13 4:28 PM, Naoto Sato wrote:
On 7/30/13 4:06 PM, David DeHaven wrote:
I was about to chime in that UTF-8 has been the preferred encoding for
(stored) text on Mac OS X as long as I've been hacking on it (think
"Rhapsody"), so why is this even an issue?
Judging from the docs, nl_langinf
Sure. Send me the final diff to me.
Naoto
On 8/1/13 11:22 AM, Brent Christian wrote:
On 7/30/13 4:28 PM, Naoto Sato wrote:
On 7/30/13 4:06 PM, David DeHaven wrote:
I was about to chime in that UTF-8 has been the preferred encoding for
(stored) text on Mac OS X as long as I've been hacking on
On Aug 1 2013, at 10:38 , Nick Williams wrote:
> That was the ticket! All the tests run with this command, despite the fact
> that some of them fail. Thanks!
>
> You might want to update the readme with this command, at least as an
> alternative to the one there now.
>
> Nick
>
> On Jul 31,
Reviewers:
This is a test-only issue.
Issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022094 (not public
quite yet)
Webrev http://cr.openjdk.java.net/~bpb/8022094/
Summary:
1) BigDecimal
* The compareToTest() method was modified to correctly print and report errors.
* The set of t
Thanks, Alan.
On 27.07.2013 17:45, alan.bate...@oracle.com wrote:
> Changeset: d4b2436892c8
> Author:bpb
> Date: 2013-07-26 17:03 -0700
> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4b2436892c8
>
> 8014319: Faster division of large integers
> Summary: Implement Burnickel-Ziegl
On 01/08/2013 08:49, Paul Sandoz wrote:
On Aug 1, 2013, at 4:45 PM, Henry Jen wrote:
In StremSpliterator:366, I assume the NULL check should be before if.
It saves a redundant check if the wrapping spliterator uses buffering, since
the tryAdvance will also check:
It looks like the explicit
On Aug 1, 2013, at 9:38 PM, Alan Bateman wrote:
> On 01/08/2013 08:49, Paul Sandoz wrote:
>>
>> On Aug 1, 2013, at 4:45 PM, Henry Jen wrote:
>>> In StremSpliterator:366, I assume the NULL check should be before if.
>>>
>> It saves a redundant check if the wrapping spliterator uses buffering,
Changeset: 0be7839d4599
Author:psandoz
Date: 2013-08-01 15:28 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0be7839d4599
8020016: Numerous splitereator impls do not throw NPE for null Consumers
Reviewed-by: mduigou, alanb, henryjen
! src/share/classes/java/util/stream/Spine
On 7/31/13 2:39 PM, Matthew Hall wrote:
On Wed, Jul 31, 2013 at 02:38:26PM -0700, Stuart Marks wrote:
The alternative is to add "@throws SocketException never" to the
javadoc, just to get rid of the doclint warning, but this has the
consequence of requiring people to keep dead code around
indefi
On 01/08/2013 14:18, Stuart Marks wrote:
:
To my eye the InetAddress/port constructors are used quite a bit more
often than the SocketAddress ones. I did a web search for "java
DatagramPacket example" and looked at all the examples on the first
page of hits. All of them used the InetAddress+p
On 2/08/2013 1:57 AM, Alan Bateman wrote:
On 26/07/2013 16:31, Mike Duigou wrote:
Hello all;
This patch adds some missing checks for null that, according to
interface contract, should be throwing NPE. It also improves the
existing tests to check for these cases.
http://cr.openjdk.java.net/~mdu
I propose the patch below to fix a theoretical bug in
divideAndRemainderBurnikelZiegler(). That method assumes the quotient
parameter to be zero which is the case in all places it is called from.
But there is no guarantee this won't change in the future and besides,
the assumption is not documented
Hi Tim,
Thanks for keeping an eye on this and for the patches. We'll need to have an
issue on file to track this. I can take care of that tomorrow.
Brian
On Aug 1, 2013, at 4:47 PM, Tim Buktu wrote:
> I propose the patch below to fix a theoretical bug in
> divideAndRemainderBurnikelZiegler().
Okay, thanks!
On 02.08.2013 01:57, Brian Burkhalter wrote:
> Hi Tim,
>
> Thanks for keeping an eye on this and for the patches. We'll need to
> have an issue on file to track this. I can take care of that tomorrow.
>
> Brian
>
> On Aug 1, 2013, at 4:47 PM, Tim Buktu wrote:
>
>> I propose the patc
Changeset: 29f153e11683
Author:weijun
Date: 2013-08-02 08:59 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29f153e11683
8021789: jarsigner parses alias as command line option (depending on locale)
Reviewed-by: vinnie
! src/share/classes/sun/security/tools/jarsigner/Main.jav
Looks good. Always a good idea to make sure that failures are reported
properly. :-)
It does look like the following cases are repeated, in both tests:
{valueOf(Long.MIN_VALUE+1), valueOf(Long.MAX_VALUE), MINUS_ONE},
{valueOf(Long.MIN_VALUE+1).negate(), valueOf(Long.MAX_VALUE),
On 08/01/2013 03:08 PM, Alan Bateman wrote:
On 01/08/2013 14:18, Stuart Marks wrote:
:
To my eye the InetAddress/port constructors are used quite a bit more
often than the SocketAddress ones. I did a web search for "java
DatagramPacket example" and looked at all the examples on the first
pag
42 matches
Mail list logo
