Fix for the previous letter:
TFV> IntStream.range(1, YearMonth.now().lengthOfMonth())
TFV> .mapToObj(YearMonth.now()::atDay)
TFV> .map(...).forEach(...)
Of course I meant IntStream.rangeClosed instead of IntStream.range in
every code sample. This just demonstrates that manual implementation
o
Hello, Roger!
Thank you for looking at my proposal.
RR> What are the use cases?
It could be used to generate some per-day/per-month/per-year reports.
For example, consider you have a collection of Deal objects, each with
LocalDate:
List deals;
Using Java-8 you can easily group them by date:
M
Vladimir, Rémi and Michael,
thanks for reviewing this!
/Claes
On 2015-12-18 16:58, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~redestad/8144723/webrev.02/
Looks good.
Best regards,
Vladimir Ivanov
On Dec 16, 2015, at 8:50 AM, Magnus Ihse Bursie
wrote:
>
> There is an interest from the community to build OpenJDK using Visual Studio
> 2015 Community edition.
>
> This patch is provided by Timo Kinnunen . I am
> sponsoring this patch.
>
> The changes to the source code files are mostly c
Hi, Joe.
It is not the intention that all JDK distributions must provide their own
specializations of jdk.Version. However, downstream users may wish to provide
additional semantics to the version string via encapsulation rather than
inheritance. In order to facilitate this, the following bug
Hi, Joe.
You make a good point regarding the inconsistency between compareTo (which
ignores $OPT) and equals (which includes $OPT). To resolve this difference, I
will introduce two new methods so that users may choose to uniformly consider
$OPT in comparisons.
We now have the following:
pu
Hi, Magnus.
Thanks for the review comments.
>> http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/
> I thought the end agreement was that the + should always be present even if
> build was empty, if opt was present but not pre. That is, "9-foo"
> should unambigiously parse as vnum=9
Hi.
Updated webrev and JavaDoc:
Webrev
http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/
JavaDoc
http://cr.openjdk.java.net/~iris/verona/8072379/doc.2/jdk/Version.html
Thanks,
iris
PS: Please note that I'll be out the week of 21 December, back on
4 January. Access to e
Hi, Roger.
Thanks for the feedback.
>> http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/
> I see the JEP says JDK specific, but does that rule out putting the version
> API in a Java.* package?
For now, we should avoid including this API in java.*. If for no other reason
but tha
Hi, Joe.
I've filed the following JDK 9 RFE to provide this functionality:
8145794: Provide Verona interpretation of historical JDK version strings
https://bugs.openjdk.java.net/browse/JDK-8145794
Thanks,
iris
-Original Message-
From: joe darcy
Sent: Sunday, November 29, 2015 4
Hi, Joe.
Thanks for the review comments.
>>> http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/
> Is the intention that downstream JDK distributions, such as
> IcedTea, whether based on OpenJDK or otherwise, would provide
> their own specialization of the jdk.Version class?
No. D
> On Dec 18, 2015, at 11:07 AM, Daniel Fuchs wrote:
>
> New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8145686/webrev.01/
Looks good.
Mandy
On Dec 18, 2015, at 12:46 AM, Tao Mao wrote:
>
>
> On Thu, Dec 17, 2015 at 9:34 PM, Mandy Chung wrote:
>
> > On Dec 17, 2015, at 6:05 PM, Tao Mao wrote:
> > On line 38, can we also add "through a chain of strong, soft, and weak
> > references." to the above, which I think is the case?
> >
>
On Fri, Dec 18, 2015 at 5:35 AM, Magnus Ihse Bursie
wrote:
> On 2015-12-15 18:25, Martin Buchholz wrote:
>>
>> _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it
>> affects interoperability between translation units. It would be good
>> to convert all of the JDK build to use -D_FI
On 12/18/2015 07:55 AM, Sundararajan Athijegannathan wrote:
inline comments below..
On 12/18/2015 6:22 PM, Alan Bateman wrote:
On 18/12/2015 12:23, Sundararajan Athijegannathan wrote:
Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/
for https://bugs.openjdk.java.net/browse
Very sorry to muddy the waters after call for votes has gone out, but
I thought of another course of action:
Instead of calling addSuppressed on the source exception, call
addSuppressed on the wrapping CompletionException. This has the
upside that the integrity of both original exceptions is maint
Hi Mandy,
Thanks for the feedback!
New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8145686/webrev.01/
On 18/12/15 03:22, Mandy Chung wrote:
It’d be helpful to add some comment in the skipLoggingFrame method.
Maybe even better to change this method to isFilteredFrame??
Done. I rename
> On Dec 18, 2015, at 2:12 AM, Peter Levart wrote:
>
> Hi,
>
> Now that PhantomReference(s) (excluding sun.misc.Cleaner(s)) are treated
> equally to sun.misc.Cleaner(s), the split between _discoveredPhantomRefs and
> _discoveredCleanerRefs is not needed any more right? Will this be a separate
Hi Kim,
34 * Suppose the garbage collector determines at a certain point
in time 35 * that an object is 36 * phantom
reachable. At that time it will atomically clear 37 * all
phantom references to that object and all phantom references to 38 *
any other phantom-reachable objects from w
On Thu, Dec 17, 2015 at 9:34 PM, Mandy Chung wrote:
>
> > On Dec 17, 2015, at 6:05 PM, Tao Mao wrote:
> >
> > Hi Kim,
> >
> > 34 * Suppose the garbage collector determines at a certain point in
> time
> > 35 * that an object is
> > 36 * phantom reachable. At that time it will atomicall
http://cr.openjdk.java.net/~redestad/8144723/webrev.02/
Looks good.
Best regards,
Vladimir Ivanov
Hi Dmitry,
thanks for the review can you please explain little bit more, as per my
testing and implementation i did not found any differences with fix and
without fix. Even i checked the java.io.File.length() and there also it
looks like we are using stat64().
as per you mail i truncate the
Looks good. Some of the new test scripts have an incomplete @summary
line, e.g. jjs-strictTest.sh:
# @summary Test that output of 'jjs -strict'
Hannes
Am 2015-12-18 um 13:23 schrieb Sundararajan Athijegannathan:
Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/
for https://bu
Hi Vinnie
I take a look and it includes a change for
src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp in the
Java_sun_security_mscapi_KeyStore_getKeyLength() function.
It seems there is no sun.security.mscapi.KeyStore#getKeyLength on the java
side. Is the function useless now?
T
On 2015-12-15 18:25, Martin Buchholz wrote:
_FILE_OFFSET_BITS is generally an all-or-nothing thing, because it
affects interoperability between translation units. It would be good
to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but
that would be a big job. So traditionally the JD
inline comments below..
On 12/18/2015 6:22 PM, Alan Bateman wrote:
On 18/12/2015 12:23, Sundararajan Athijegannathan wrote:
Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/
for https://bugs.openjdk.java.net/browse/JDK-8145750
Adding missing permissions for jdk.dynalink mo
On 18/12/2015 12:23, Sundararajan Athijegannathan wrote:
Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/
for https://bugs.openjdk.java.net/browse/JDK-8145750
Adding missing permissions for jdk.dynalink module. Note that it used
to be part of jdk.scripting.nashorn module i
On 2015-12-16 14:50, Magnus Ihse Bursie wrote:
There is an interest from the community to build OpenJDK using Visual Studio
2015 Community edition.
This patch is provided by Timo Kinnunen . I am
sponsoring this patch.
The changes to the source code files are mostly casts to uintptr_t, but the
Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8145750
Adding missing permissions for jdk.dynalink module. Note that it used to
be part of jdk.scripting.nashorn module in the past and therefore got
AllPermission.
Thanks,
-Sund
Vyom,
If I read the changes correctly, current code returns result of lseek()
but your code returns result of fstat().
I'm not sure it's a correct replacement.
dooku:test#truncate --size=102400 test.me
dooku:test#./test
STAT: 102400 0 Success
SEEK: 2 0 Success
Moreover, if you truncate a file
Hu Vyom,
On 17/12/15 17:58, Martin Buchholz wrote:
Looks good!
Since you got Martin's blessing I will sponsor this
and push it for you :-)
best regards,
-- daniel
On Thu, Dec 17, 2015 at 12:14 AM, vyom wrote:
Hi Martin,
thanks for review, i undated the
webrev(http://cr.openjdk.java.net
JDK-8144811: https://bugs.openjdk.java.net/browse/JDK-8144811
No repro on 8u66.
Test code:
import java.util.regex.Matcher;
public class JDK8144811 {
public static void main(String args[]) {
String s = "Dogs and cats are lovely pets but cost some money
to se
Looks fine.
On 17/12/15 18:28, Roger Riggs wrote:
+1
On 12/17/2015 10:15 AM, Chris Hegarty wrote:
For ease of review, I moved the complete changes into a webrev.
http://cr.openjdk.java.net/~chegar/8145589/webrev/
-Chris.
On 17 Dec 2015, at 15:08, Chris Hegarty wrote:
On 17 Dec 2015, a
Hi,
Now that PhantomReference(s) (excluding sun.misc.Cleaner(s)) are treated
equally to sun.misc.Cleaner(s), the split between _discoveredPhantomRefs
and _discoveredCleanerRefs is not needed any more right? Will this be a
separate simplification?
Regards, Peter
On 12/17/2015 10:30 PM, Kim B
34 matches
Mail list logo
