Thank you Ulf!
On 19.03.2014 2:12, Ulf Zibis wrote:
Am 18.03.2014 19:28, schrieb Ivan Gerasimov:
Assuming this last iteration is OK, should the next step be a CCC
request?
Do you mean? :
/*
* ...
+ * It is assumed that fromIndex = toIndex, otherwise the
behaviour of this
Fine by me.
David
On 19/03/2014 4:37 AM, Ivan Gerasimov wrote:
Sorry, here's the link:
http://cr.openjdk.java.net/~igerasim/8014066/4/webrev/
On 18.03.2014 22:28, Ivan Gerasimov wrote:
Hello!
Would you please take a look at the next iteration of webrev?
I incorporated the last suggestions
On 19/03/14 08:29, David Holmes wrote:
Fine by me.
David
On 19/03/2014 4:37 AM, Ivan Gerasimov wrote:
Sorry, here's the link:
http://cr.openjdk.java.net/~igerasim/8014066/4/webrev/
Looks fine to me too.
-Chris.
On 18.03.2014 22:28, Ivan Gerasimov wrote:
Hello!
Would you please take a
On 17/03/2014 14:51, roger riggs wrote:
Hi,
This looks fine (not a Reviewer).
Looks okay to me too.
I'm checking on how to handle the change in TCK tests.
The same question (and answer) applies to JDK-8036818:
DateTimeFormatter withResolverFields() fails to accept null
There is a process
On 12/03/2014 10:52, Stephen Colebourne wrote:
This is a request for review of this bug:
https://bugs.openjdk.java.net/browse/JDK-8036785
During development, ChronoLocalDate had a generic type parameter. It
was removed during the development of JSR-310. The Javadoc was not
updated to reflect
At the time it was originally written I don't think @apiNote existed.
I agree it would be good to get the separation in there. However my
current concern is getting the change back to jdk8u, and it seems that
the simplest solution might be the best to achieve that.
Perhaps later, I might then
On 19/03/2014 10:59, Stephen Colebourne wrote:
At the time it was originally written I don't think @apiNote existed.
I agree it would be good to get the separation in there. However my
current concern is getting the change back to jdk8u, and it seems that
the simplest solution might be the best
On 03/18/2014 06:22 PM, Andrew Hughes wrote:
The intent was for #3 to cover this case (i.e. whatever Oracle does now)
and for #2 to be what the GNU/Linux distributions want (i.e. binaries with
all debuginfo generated and left intact so they can do their own stripping).
Mmm, but maybe that will
On 2014-03-18 19:25, Andrew Haley wrote:
On 03/18/2014 06:22 PM, Andrew Hughes wrote:
The intent was for #3 to cover this case (i.e. whatever Oracle does now)
and for #2 to be what the GNU/Linux distributions want (i.e. binaries with
all debuginfo generated and left intact so they can do their
Thanks Alan!
These two tests used the commands run from non very common location
(/usr/bin/ instead of /bin/), so I suspect they have been rarely run.
As it follows from the summaries, one of them ensures the VM doesn't
crash; the other checks, whether the input/output streams are left open.
On 03/19/2014 01:51 PM, Magnus Ihse Bursie wrote:
On 2014-03-18 19:25, Andrew Haley wrote:
On 03/18/2014 06:22 PM, Andrew Hughes wrote:
The intent was for #3 to cover this case (i.e. whatever Oracle does now)
and for #2 to be what the GNU/Linux distributions want (i.e. binaries with
all
- Original Message -
On 03/19/2014 01:51 PM, Magnus Ihse Bursie wrote:
On 2014-03-18 19:25, Andrew Haley wrote:
On 03/18/2014 06:22 PM, Andrew Hughes wrote:
The intent was for #3 to cover this case (i.e. whatever Oracle does now)
and for #2 to be what the GNU/Linux distributions
Here's the (hopefully final) polished webrev: removed 'othervm' and
replaced stderr with stdout in reporting of the wrong OS.
Would you please take a look?
http://cr.openjdk.java.net/~igerasim/6943190/4/webrev/
Sincerely yours,
Ivan
On 19.03.2014 20:11, Martin Buchholz wrote:
On Wed, Mar 19, 2014 at 1:19 AM, Ivan Gerasimov
ivan.gerasi...@oracle.com mailto:ivan.gerasi...@oracle.com wrote:
Improving modCound handling can be done with a different RFE I
guess, as it doesn't connected to the rest of the fix.
I
Similar suggestion has been on the to-do list for a while. There were
discussion back
then that it might be interesting to add the more general interface
Appendable...
The issue was how to deal with the IOE declared by the Appendable methods then.
If the appendable is not going to happen, then
Thanks Martin!
On 19.03.2014 20:23, Martin Buchholz wrote:
I expected to see System.out used instead (not that it matters much).
I would write:
System.out.println('true' command not found; skipping test);
Two cases are mixed here:
- normal run (OS does not have this command),
- erroneous
Thanks Anthony!
Can somebody from the core-libs team take a look?
On 3/17/14 10:31 PM, Anthony Petrov wrote:
Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds good
to me too. Either way, I'm fine with the fix.
--
best regards,
Anthony
On 3/17/2014 7:01 PM, Sergey Bylokhov
https://bugs.openjdk.java.net/browse/JDK-8035807
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/
This patch converts the last 2 references to
sun.misc.BASE64Encoder/Decoder from the jdk repo with
java.util.Base64. We should also update the tests and I have
Fix looks fine. You just need to update the import statements in Obj.java
On 19 Mar 2014, at 18:37, Mandy Chung mandy.ch...@oracle.com wrote:
https://bugs.openjdk.java.net/browse/JDK-8035807
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/
This patch
OK. Thanks.
On 19 Mar 2014, at 19:06, Mandy Chung mandy.ch...@oracle.com wrote:
On 3/19/2014 12:03 PM, Vincent Ryan wrote:
Fix looks fine. You just need to update the import statements in Obj.java
Fixed. Not sure how it's missed in the webrev :)
thanks
Mandy
On 19 Mar 2014, at
On 3/19/2014 12:03 PM, Vincent Ryan wrote:
Fix looks fine. You just need to update the import statements in Obj.java
Fixed. Not sure how it's missed in the webrev :)
thanks
Mandy
On 19 Mar 2014, at 18:37, Mandy Chung mandy.ch...@oracle.com wrote:
On 19/03/2014 18:37, Mandy Chung wrote:
https://bugs.openjdk.java.net/browse/JDK-8035807
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/
This patch converts the last 2 references to
sun.misc.BASE64Encoder/Decoder from the jdk repo with
java.util.Base64. We
On 03/19/2014 11:37 AM, Mandy Chung wrote:
https://bugs.openjdk.java.net/browse/JDK-8035807
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/
This patch converts the last 2 references to sun.misc.BASE64Encoder/Decoder
from the jdk repo with java.util.Base64. We
Definitely a useful macro.
I too would prefer a name like TO_JBOOLEAN since it reveals the result type.
Also all uppercase to identify it as a macro. If we are paranoid and want to
reduce the chance of a name collision then JNU_TO_JBOOLEAN perhaps.
I would also define the macro as:
#define
Hi,
Well... When JNU_RETURN was added, there was a long discussion about
NOT using JNU unless the JNI environment was an argument to the macro.
So, the simple name is preferred.
Roger
On 3/19/2014 4:08 PM, Phil Race wrote:
PS .. so maybe whilst you are touching this file you could do
On 3/19/2014 12:28 PM, Xueming Shen wrote:
On 03/19/2014 11:37 AM, Mandy Chung wrote:
https://bugs.openjdk.java.net/browse/JDK-8035807
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/
This patch converts the last 2 references to
sun.misc.BASE64Encoder/Decoder
On 19/03/2014 17:34, Ivan Gerasimov wrote:
Here's the (final?) webrev:
http://cr.openjdk.java.net/~igerasim/6943190/5/webrev/
This looks okay although I would prefer for a number of these tests to
fail if the command is not found (otherwise it is will just hide
issues). We can create another
On 19/03/2014 20:33, Mandy Chung wrote:
:
I believe both cases don't have the 76 characters constraint although
it uses MIME type encoder/decoder previously unless Vinnie and Alan
say otherwise.
Sherman makes a good point and we should double check the LDAP spec to
see which base64 scheme
Am 19.03.2014 09:19, schrieb Ivan Gerasimov:
Thank you Ulf!
On 19.03.2014 2:12, Ulf Zibis wrote:
Am 18.03.2014 19:28, schrieb Ivan Gerasimov:
Assuming this last iteration is OK, should the next step be a CCC request?
Do you mean? :
/*
* ...
+ * It is assumed that fromIndex =
On Mar 14, 2014, at 7:17 AM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
On Mar 14, 2014, at 3:39 AM, Peter Levart wrote:
But in general it would be better to just use ThreadLocalRandom.current()
everywhere you use rnd variable. This is precisely it's purpose - a random
number
Am 19.03.2014 23:32, schrieb Martin Buchholz:
No one is as performance obsessed as Ulf.
:-D :-D :-D
Hi,
This is an update from Xerces for file
impl/xpath/regex/TokenRange.java. For details, please refer to:
https://bugs.openjdk.java.net/browse/JDK-8035577.
Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/
Existing tests: JAXP SQE and unit tests passed.
Test cases added for
On 03/19/2014 11:01 PM, Brian Burkhalter wrote:
On Mar 14, 2014, at 7:17 AM, Brian Burkhalter
brian.burkhal...@oracle.com mailto:brian.burkhal...@oracle.com wrote:
On Mar 14, 2014, at 3:39 AM, Peter Levart wrote:
But in general it would be better to just use
ThreadLocalRandom.current()
I
On Mar 19 2014, at 15:01 , Brian Burkhalter brian.burkhal...@oracle.com wrote:
On Mar 14, 2014, at 7:17 AM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
On Mar 14, 2014, at 3:39 AM, Peter Levart wrote:
But in general it would be better to just use ThreadLocalRandom.current()
On Mar 19, 2014, at 4:32 PM, Mike Duigou mike.dui...@oracle.com wrote:
Since the Unsafe.getObjectVolatile() allows use of volatile semantics without
having to declare the field volatile I think this is a better idiom than what
I had previously suggested. Hopefully this is a pattern we can
Hi Peter,
On Mar 19, 2014, at 4:32 PM, Peter Levart peter.lev...@gmail.com wrote:
So the solution is to reduce number of bytecodes in toString(). For
example, the following:
public String toString() {
String sc = stringCache;
if (sc == null) {
sc =
Thanks.
So if nobody objects, the final version will be:
#define IS_NULL(obj) ((obj) == NULL)
#define JNU_IsNull(env,obj) ((obj) == NULL)
+#define TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE)
On 3/20/14 12:07 AM, roger riggs wrote:
Hi,
Well... When JNU_RETURN was added, there
On Mar 19, 2014, at 4:41 PM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
Benchmark Mode Samples Mean Mean error
Units
o.s.Bench6375303.testToString avgt10 80.9250.313
ns/op
That’s great! I can re-try that
Hi Sergey,
Please give this a day to stew.
I'd like some time to consider other names before agreeing.
(Not that my agreement is necessary or sufficient).
Thanks, Roger
On 3/19/14 7:43 PM, Sergey Bylokhov wrote:
Thanks.
So if nobody objects, the final version will be:
#define IS_NULL(obj)
39 matches
Mail list logo
