Kelly O'Hair said the following on 06/10/10 05:52:
It's been a while since I worked with this stuff, but I would have done a:
jclass cls = env->FindClass("Test");
Which, if I recall, FindClass actually initializes the class.
Yes but in this case they are actually creating their own classlo
Am 09.06.2010 11:50, schrieb Andrew Haley:
On 09/06/10 10:11, Andrew John Hughes wrote:
On 9 June 2010 07:55, Florian Weimer wrote:
* Andrew John Hughes:
On 7 June 2010 23:04, Xueming Shen wrote:
Hi Andrew,
6959197: When building with JAVAC_MAX_WARNINGS=true, t
It's been a while since I worked with this stuff, but I would have
done a:
jclass cls = env->FindClass("Test");
Which, if I recall, FindClass actually initializes the class.
Just a stab in the dark.
-kto
On Jun 9, 2010, at 12:39 PM, Martin Buchholz wrote:
David, Thanks for the bug arc
Hi Sherman,
I'm happy to see those enhancements.
Please allow me to note, that IIRC many of them and similar others I had
addressed by my patches on
https://bugs.openjdk.java.net/show_bug.cgi?id=10009x.
Unfortunately https://bugs.openjdk.java.net is down today, so I can't be
more specific.
David, Thanks for the bug archaeology. Judging by the other
commenters, this bug is a regression from jdk5, and has cost many
other users hours of frustrating debugging time, so I think an
increase to P2 is in order. Since it used to work, it shouldn't be
too hard to fix - all you need to do is t
Changeset: af68ad345389
Author:alanb
Date: 2010-06-09 18:51 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/af68ad345389
6935563: (dc) Improve connection reset/port unreachable handling [win]
Reviewed-by: chegar
! src/windows/native/sun/nio/ch/DatagramChannelImpl.c
! src/wind
Andrew John Hughes wrote:
On 9 June 2010 07:55, Florian Weimer wrote:
* Andrew John Hughes:
On 7 June 2010 23:04, Xueming Shen wrote:
Hi Andrew,
6959197: When building with JAVAC_MAX_WARNINGS=true, the build fails in
sun/nio/cs due to the use of -Werror
(1)sun/io/ByteTochar
Hi Martin,
Turns out this is a known (and old) issue (thanks Yuri!):
CR 6493522 "JNI_RegisterNatives fails to bind a method of an
uninitialized class"
I'll add this email info to the CR.
David
Martin Buchholz said the following on 06/09/10 09:12:
Hi ClassLoader maintainers,
This is a bug
On 09/06/10 10:11, Andrew John Hughes wrote:
> On 9 June 2010 07:55, Florian Weimer wrote:
>> * Andrew John Hughes:
>>
>>> On 7 June 2010 23:04, Xueming Shen wrote:
Hi Andrew,
6959197: When building with JAVAC_MAX_WARNINGS=true, the build fails in
sun/nio/cs due to the use of
On 9 June 2010 07:55, Florian Weimer wrote:
> * Andrew John Hughes:
>
>> On 7 June 2010 23:04, Xueming Shen wrote:
>>> Hi Andrew,
>>>
>>> 6959197: When building with JAVAC_MAX_WARNINGS=true, the build fails in
>>> sun/nio/cs due to the use of -Werror
>>>
>>> (1)sun/io/ByteTocharISO2022JP.java
>>>
Hi,
>From performance point of view, it does not matter whether we use
>Float.isNaN(ak) or (ak != ak). Hotspot generates the same native code.
As for not skipping trailing nans, can you explain why it could be faster?
Thank you,
Dmytro Sheyko
> Date: Tue, 8 Jun 2010 18:09:42 +0400
> From: iar
11 matches
Mail list logo
