Adding core-libs-dev and re-asking for a review.
Thanks,
/Staffan
On 27 feb 2013, at 15:59, Staffan Larsen staffan.lar...@oracle.com wrote:
Please review the following test fix.
webrev: http://cr.openjdk.java.net/~sla/8006637/webrev.00/
bug:
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 staffan.lar...@oracle.com wrote:
Please review the following test fix.
webrev:
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
!
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 damjan@gmail.com, Chris Hegarty
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
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
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
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]:
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]:
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
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
!
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
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
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
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
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
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
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
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
Hi,
for me this is more readable than current naming.
ComparatorPeople cmp1 = compareWith(People::getFirstName).
thenCompareWith(People::getLastName);
Ali Ebrahimi
On Thu, Mar 7, 2013 at 12:22 AM, Henry Jen henry@oracle.com wrote:
On 03/06/2013 03:28
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
On Wed, Mar 6, 2013 at 1:01 PM, Henry Jen henry@oracle.com wrote:
On 03/06/2013 02:31 AM, Michael Hixson wrote:
1. Why disable the following code even though it is (theoretically) safe?
ComparatorCharSequence a = comparing(CharSequence::length);
ComparatorString b =
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 Thu, Mar 7, 2013 at 3:26 PM, Dean Long dean.l...@oracle.com 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
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
On Mar 2, 2013, at 12:46 AM, Jeroen Frijters jer...@sumatra.nl 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.
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
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,
I think it all boiled down to re-use an existing Comparator to compare
for another type.
What about we added this to ComparatorT as a default method,
default S ComparatorS apply(FunctionS, ? extends T keyExtractor) {
Objects.requireNonNull(keyExtractor);
return
29 matches
Mail list logo
