I think it all boiled down to re-use an existing Comparator to compare
for another type.
What about we added this to Comparator as a default method,
> default Comparator apply(Function keyExtractor) {
> Objects.requireNonNull(keyExtractor);
> return (Comparator & Serializable
Hi Bharadwaj,
Given 8009697 [1] this work would only seem to be one part of what is
needed to use invokestatic with an interface method.
David
-
[1] The JVMS 4.9.2 states:
"Each invokespecial instruction must name an instance initialization
method (ยง2.9), a method in the current class,
Moved the string allocation into buildJniFunctionName as Alan suggested.
Built and tested on windows and linux. Updated the webrev:
http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/
bill
On 3/7/2013 3:50 PM, Alan Bateman wrote:
On 07/03/2013 16:36, BILL PITTORE wrote:
I updated the
On Mar 2, 2013, at 12:46 AM, Jeroen Frijters wrote:
> This is really great. I've been using an annotation for caller sensitive
> methods for many year in IKVM as a performance enhancement and I can say that
> my experiences with my simple mechanism are really great.
Hi Jeroen. I'm glad you (a
Not sure which is best list for this given Alan will likely be the only
reviewer anyway :)
Webrevs under:
http://cr.openjdk.java.net/~dholmes/8009428_8009429/
Two related sets of fixes here:
JDK-8009428: Revert changes to $ substitution performed as part of
nashorn integration
This removes
On Thu, Mar 7, 2013 at 3:26 PM, Dean Long wrote:
> On 3/7/2013 10:18 AM, Jeremy Manson wrote:
>
> Hi guys,
>
> I'm really glad to see you are doing this. We've done something similar
> to good effect within Google (and we'll probably drop our similar, internal
> patch and pick up this patch on
On 3/7/2013 10:18 AM, Jeremy Manson wrote:
Hi guys,
I'm really glad to see you are doing this. We've done something
similar to good effect within Google (and we'll probably drop our
similar, internal patch and pick up this patch once it is pushed).
Have you thought about support for having
On Wed, Mar 6, 2013 at 1:01 PM, Henry Jen wrote:
> On 03/06/2013 02:31 AM, Michael Hixson wrote:
>
>> 1. Why disable the following code even though it is (theoretically) safe?
>>
>> Comparator a = comparing(CharSequence::length);
>> Comparator b = a.thenComparing(CASE_INSENSITIVE_ORDER);
>>
>>
Hi,
This is Mohankumar working based in Hyderabad India working for MNC
Recently i have worked on PKCS11 support for 64 bit Sun/oracle java i found
the SUNPKCS11.jar and j2pkcs11.dll are not present in jdk and which are
core elements for PKCS11 support due to absence of this on* 64bit java* we
Hi,
for me this is more readable than current naming.
Comparator cmp1 = compareWith(People::getFirstName).
thenCompareWith(People::getLastName);
Ali Ebrahimi
On Thu, Mar 7, 2013 at 12:22 AM, Henry Jen wrote:
> On 03/06/2013 03:28 AM, Ali Ebrahimi wrote:
>
On 03/06/2013 03:42 PM, Mandy Chung wrote:
LoggerResourceBundleRace.java: I think what you really want is to
add a new test that sets a context class loader to a class loader
that finds the resource bundle for a logger that a system class
loader can't find. I suggest to leave this test a
Are you talking about windows-64 bit? All the other platforms should
have 64-bit support.
JDK 8 does have windows-x64 support for PKCS11.
http://openjdk.java.net/jeps/131
I don't know of any plans to backport.
Brad
On 3/6/2013 9:16 PM, mohankumar kanaka wrote:
Hi,
This is Mohankum
I would like to request for a review of changes whose details are as
follows:
Bug fixed: https://jbs.oracle.com/bugs/browse/JDK-8009552
Webrev: http://cr.openjdk.java.net/~bharadwaj/8009552/webrev/
Summary of changes :
To support JDK 8 features, javac now generates invokespecial
instructions t
On 3/7/2013 3:50 PM, Alan Bateman wrote:
On 07/03/2013 16:36, BILL PITTORE wrote:
I updated the code based on the feedback. To fix the windows symbol
name issue that Dean brought up I added a platform specific function,
buildJniFunctionName. In windows it will properly convert
_JNI_OnLoad@8 to
On 07/03/2013 16:36, BILL PITTORE wrote:
I updated the code based on the feedback. To fix the windows symbol
name issue that Dean brought up I added a platform specific function,
buildJniFunctionName. In windows it will properly convert
_JNI_OnLoad@8 to _JNI_OnLoad_libname@8 as well as handle J
On 3/7/2013 1:18 PM, Jeremy Manson wrote:
Hi guys,
I'm really glad to see you are doing this. We've done something
similar to good effect within Google (and we'll probably drop our
similar, internal patch and pick up this patch once it is pushed).
Have you thought about support for having a
Hi guys,
I'm really glad to see you are doing this. We've done something similar to
good effect within Google (and we'll probably drop our similar, internal
patch and pick up this patch once it is pushed).
Have you thought about support for having a JNI_OnLoad inside of a main
executable that *d
Changes look good to me.
Mike
On Mar 7 2013, at 08:36 , BILL PITTORE wrote:
> I updated the code based on the feedback. To fix the windows symbol name
> issue that Dean brought up I added a platform specific function,
> buildJniFunctionName. In windows it will properly convert _JNI_OnLoad@8 to
Nice fix!
This is more clear and robust.
Extra memory allocation is Ok.
Thanks,
Serguei
On 3/7/13 3:54 AM, Staffan Larsen wrote:
Here is a webrev for fixing this problem. I actually removed all of
our own tokenization code in dll_build_name() and replaced it with
calls to strtok_r (strtok_s o
I updated the code based on the feedback. To fix the windows symbol name
issue that Dean brought up I added a platform specific function,
buildJniFunctionName. In windows it will properly convert _JNI_OnLoad@8
to _JNI_OnLoad_libname@8 as well as handle JNI_OnLoad symbol name.
Fixed copyright h
Changeset: a02c3ddc182b
Author:rfield
Date: 2013-03-07 08:26 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a02c3ddc182b
8009582: Method reference generic constructor gives: IllegalArgumentException:
Invalid lambda deserialization
Reviewed-by: mcimadamore
! src/share/
Robert - LambdaAccessControlTest is a problem when running the jdk tests
concurrently (jtreg -concurrency...). The test extends LUtils so it's
only going to compile if LambdaAccessControlDoPrivilegedTest.java has
been previously compiled into the same work directory. I'd like to move
LUtils i
Can I say two word about the file
http://cr.openjdk.java.net/~dxu/8001334/webrev.01/src/windows/native/java/io/io_util_md.c.frames.html
and function
getLastErrorString(char *buf, size_t len)
Here is the documentation for [FormatMessage]:
http://msdn.microsoft.com/en-gb/library/windows/deskto
On 07/03/2013 13:21, Alexey Utkin wrote:
Can I say two word about the file
http://cr.openjdk.java.net/~dxu/8001334/webrev.01/src/windows/native/java/io/io_util_md.c.frames.html
and function
getLastErrorString(char *buf, size_t len)
Here is the documentation for [FormatMessage]:
http://ms
On 05/03/2013 18:39, Dan Xu wrote:
Hi All,
Thanks for your good suggestions. I have updated this fix and put the
new webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.01/.
Please help review it. Thanks!
-Dan
I've looked at the latest webrev and it looks quite good. There are
several
On 07/03/2013 02:57, Martin Buchholz wrote:
Pushed to jdk8/tl/jdk.
I recommend this be backported to jdk7u.
I agree that it would be good to backport. It doesn't happen
automatically so you'll need to mail jdk7u-dev asking for approved to
push it to jdk7u/jdk7u-dev.
-Alan
Here is a webrev for fixing this problem. I actually removed all of our own
tokenization code in dll_build_name() and replaced it with calls to strtok_r
(strtok_s on windows) instead. I think this should be more robust, at the cost
of an extra memory allocation. I've also added the const qualifi
Changeset: 48b7295f02f8
Author:chegar
Date: 2013-03-07 10:07 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48b7295f02f8
6370908: Add support for HTTP_CONNECT proxy in Socket class
Reviewed-by: chegar
Contributed-by: Damjan Jovanovic , Chris Hegarty
+ src/share/classes/jav
Changeset: 823fb9229724
Author:vromero
Date: 2013-03-07 10:12 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/823fb9229724
8009170: Regression: javac generates redundant bytecode in assignop involving
arrays
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/ja
Changeset: 3806171b52d8
Author:vromero
Date: 2013-03-07 10:04 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3806171b52d8
8009138: javac, equals-hashCode warning tuning
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classe
Looks good.
Thanks,
Serguei
On 3/7/13 12:10 AM, Staffan Larsen wrote:
Adding core-libs-dev and re-asking for a review.
Thanks,
/Staffan
On 27 feb 2013, at 15:59, Staffan Larsen wrote:
Please review the following test fix.
webrev: http://cr.openjdk.java.net/~sla/8006637/webrev.00/
bug: htt
Adding core-libs-dev and re-asking for a review.
Thanks,
/Staffan
On 27 feb 2013, at 15:59, Staffan Larsen wrote:
> Please review the following test fix.
>
> webrev: http://cr.openjdk.java.net/~sla/8006637/webrev.00/
> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006637
>
> The pr
32 matches
Mail list logo
