Hi,
after recent changes, this patch has been revisited and improved
slightly, primarily simplifying and speeding up the toString method
slightly more:
http://cr.openjdk.java.net/~redestad/8006627/webrev.1/
/Claes
On 2014-06-15 00:41, Claes Redestad wrote:
Hi,
please review this patch
On 19.07.2014 3:07, Martin Buchholz wrote:
I took a quick look at StringJoiner. It looks to me like this won't
be an optimization, because StringJoiner uses StringBuilder
internally, and will actually perform more total operations.
Unfortunately this is true.
Microbenchmarking shows that S
On 07/18/2014 06:36 PM, Stuart Marks wrote:
On 7/18/14 2:17 AM, Michael Kay wrote:
On 18 Jul 2014, at 10:09, Wang Weijun wrote:
A .with(k, v) to create a new immutable map with an extra pair.
Yes, that's the same as my A.add(k,v) -> A proposal.
Works whether A is mutable or immutable.
I d
On 7/18/14 2:17 AM, Michael Kay wrote:
On 18 Jul 2014, at 10:09, Wang Weijun wrote:
A .with(k, v) to create a new immutable map with an extra pair.
Yes, that's the same as my A.add(k,v) -> A proposal.
Works whether A is mutable or immutable.
I don't think we want to have a Map.add(k,v) ins
Oh sorry, I missed that you had tightened the imports.
I took a quick look at StringJoiner. It looks to me like this won't be an
optimization, because StringJoiner uses StringBuilder internally, and will
actually perform more total operations. It looks to me like StringJoiner
itself could be opt
You are correct. I will switch to a do-while.
Mike
On Jul 18 2014, at 15:20 , Ivan Gerasimov wrote:
> Hi Claes!
>
> Wouldn't it be better to use do-while here:
> 339 while (charPos > offset) {
> 340 buf[--charPos] = Integer.digits[val & mask];
> 341 val >>>=
In the test I only replaced
import java.lang.reflect.*;
with
import java.lang.reflect.Modifier;
and added the new bugid to the @bug tag.
Sincerely yours,
Ivan
On 19.07.2014 2:53, Martin Buchholz wrote:
It looks like the test has a new import, but no actual new code that
uses it.
On Fri,
It looks like the test has a new import, but no actual new code that uses
it.
On Fri, Jul 18, 2014 at 3:39 PM, Ivan Gerasimov
wrote:
> Hello!
>
> StringBuilder can be replaced with StringJoiner, which will make the code
> shorter and, probably, more efficient.
> The existing regtest (java/lang/
Hello!
StringBuilder can be replaced with StringJoiner, which will make the
code shorter and, probably, more efficient.
The existing regtest (java/lang/reflect/Modifier/toStringTest.java) can
be used to make sure nothing is broken.
Would you please help review the fix?
BUGURL: https://bugs.o
Hi Claes!
Wouldn't it be better to use do-while here:
339 while (charPos > offset) {
340 buf[--charPos] = Integer.digits[val & mask];
341 val >>>= shift;
342 }
given the precondition
// assert len > 0 && (offset + len) <= buf.length : "illeg
On Jul 18, 2014, at 1:15 PM, Remi Forax wrote:
> I like the way the proposed API is composable but i fear that people will
> still forget to first call throwIfUnchecked() most of the time.
>
> I think we should not implement a throwSuppressedIf because a suppressed
> exception is not a primary
Looks good. I will complete some additional testing and push this changeset for
you.
On Jul 18 2014, at 14:14 , Claes Redestad wrote:
> Hi,
>
> Mike Duigou suggested some simplifications to the formatUnsigned methods.
> Shows a slight speed-upon some micros as well:
>
> http://cr.openjdk.jav
Hi,
Mike Duigou suggested some simplifications to the formatUnsigned
methods. Shows a slight speed-upon some micros as well:
http://cr.openjdk.java.net/~redestad/8050114/webrev.2/
/Claes
On 2014-07-13 00:26, Claes Redestad wrote:
Hi,
please review this patch to expose formatUnsignedInt/
On 07/18/2014 03:54 AM, John Rose wrote:
FTR, I captured this issue:
https://bugs.openjdk.java.net/browse/JDK-8051294
(Wish they were all so easy to catch.)
— John
Hi John,
I like the way the proposed API is composable but i fear that people
will still forget to first call throwIfUnchec
I support Peter at al's plan to add an API that ThreadLocalRandom et al can
use to get some system entropy without unbounded class dependency loading.
It should not surprise anyone that at Google, we are most interested in
running on Linux, so while we're waiting for a proper fix to happen we are
On 18.07.2014 20:14, Joe Darcy wrote:
Hello Georgiy,
On 07/18/2014 05:29 AM, Georgiy Rakov wrote:
Hello Joe,
could you please clarify by short example following assertion:
154 * If the exact sum is infinite, a properly-signed infinity is
155 * returned.
I'm afraid I don't quit
Alright, we can abandon this change. In practice, tests on different
platforms will usually catch SOE before users encounter it, because the
stacks are all almost identical. Unless there is e.g. a hotspot bug that
causes thread local variables to be allocated inside the stack size instead
of outs
Thanks Kumar. Yes, misspoke here. Will correct the comment.
On 7/18/2014 10:35 AM, Kumar Srinivasan wrote:
Neil,
The fix looks good. However there is an inaccuracy in the comment:
+ * Normally, JNI calls do not return if an exception is thrown.
+ * However, this behavior can change in the
Neil,
The fix looks good. However there is an inaccuracy in the comment:
+ * Normally, JNI calls do not return if an exception is thrown.
+ * However, this behavior can change in the future,
+ * so check for thrown exceptions.
This is not true, JNI calls *will* return if an exception is throw
> This is a small code review request for an issue I encountered when trying to
> compare the result of the output of a docs build from two JDK repos. I’ll
> file a bug on it soon.
>
> The issue is that the 'Annotation Type Hierarchy' & 'Enum Hierarchy’ sections
> of ‘Use' and ‘Tree’ view for
Please review this launcher change.
Issue: https://bugs.openjdk.java.net/browse/JDK-8046545
webrev: http://cr.openjdk.java.net/~ntoda/8046545/webrev-01/
Summary:
Introduce a set of macros for launcher to be used to check for certain
conditions after
return from select functions.
Hello Georgiy,
On 07/18/2014 05:29 AM, Georgiy Rakov wrote:
Hello Joe,
could you please clarify by short example following assertion:
154 * If the exact sum is infinite, a properly-signed infinity is
155 * returned.
I'm afraid I don't quite understand what you mean here by 'exac
Looks good.
Mandy
On 7/18/2014 2:42 AM, Miroslav Kos wrote:
Good catch Mandy, thanks!
updated webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.06/
JBS: https://bugs.openjdk.java.net/browse/JDK-8038970
Added JAF files (overwritten during integration from upstream),
removed throws/catch(e
On 7/17/14 9:56 PM, Mandy Chung wrote:
This is a regression caused by JDK-8038177 that changed
sun.nio.cs.ext.ExtendedCharsets to use lambda. It turns out that
ExtendedCharsets is loaded during the initialization of the extension
class loader when opening jre/lib/ext/meta-index on windows with s
So doing a bit of homework should probably have been my first approach.
Interestingly, we are never actually going to have only 32k allocated
for the stack. The VM will allocate the
os::Solaris|Linux|etc::min_stack_allowed size which is a minimum of 48k
on some platforms but generally 64k+. Wi
On 17/07/2014 23:05, Mike Duigou wrote:
Hello all;
While investigating another issue I ran across some code in
java.nio.StringCharBuffer.toString(int, int) which might be possible to
improve. Currently the implementation calls toString() on the source
CharSequence and then uses String.substri
On 18/07/2014 13:37, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8051350?
http://cr.openjdk.java.net/~prappo/8051350/webrev.00/
This is just a one-liner javadoc fix.
Looks okay. Just skimming through this file then there are bunch of odd
formatting issues (with
Hi everyone,
Could you please review my change for JDK-8051350?
http://cr.openjdk.java.net/~prappo/8051350/webrev.00/
This is just a one-liner javadoc fix.
-Pavel
Hello Joe,
could you please clarify by short example following assertion:
154 * If the exact sum is infinite, a properly-signed infinity is
155 * returned.
I'm afraid I don't quite understand what you mean here by 'exact sum'.
Thank you,
Georgiy.
On 16.07.2014 16:37, Paul Sandoz
Thanks for review, Paul.
Looks good.
Same question as in previous email on @Stable for MethodHandles.IDENTITY_MHS.
FWIW for MethodHandles.IDENTITY_MHS the Wrapper.ordinal() is used as an index
rather than using an EnumMap.
Yes, caching logic is inconsistent across java.lang.invoke. I'll try t
Thanks for review, Paul.
MethodHandleImpl
Merge the the 'if' into an 'else if':
365 } else {
366 if (dst.isPrimitive()) {
Done.
ValueConversions
I can see why an EnumMap is used for convenience mapping the Wrapper to MH.
IIUC it means the MH ref values are not @Sta
Good catch Mandy, thanks!
updated webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.06/
JBS: https://bugs.openjdk.java.net/browse/JDK-8038970
Added JAF files (overwritten during integration from upstream), removed
throws/catch(es) in XMLStreamWriterFactory.
Thanks
Miran
On 17/07/14 18:0
On 18 Jul 2014, at 10:09, Wang Weijun wrote:
> A .with(k, v) to create a new immutable map with an extra pair.
>
Yes, that's the same as my A.add(k,v) -> A proposal.
Works whether A is mutable or immutable.
Michael Kay
Saxonica
A .with(k, v) to create a new immutable map with an extra pair.
--Max
On Jul 18, 2014, at 16:11, Michael Kay wrote:
>>
>> Well, Remi had proposed raising the limit. Suppose we offered 7 key-value
>> pairs instead of 5. Would you then complain about having to rewrite your
>> code if you had t
>
> Well, Remi had proposed raising the limit. Suppose we offered 7 key-value
> pairs instead of 5. Would you then complain about having to rewrite your code
> if you had to add an 8th entry to the map?
Yes, I would. In fact, the higher you make the limit, the bigger the surprise
when I find
On 18/07/2014 05:56, Mandy Chung wrote:
:
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050968/webrev.00/
This looks okay for now. We've had a few other issues like this too, you
might remember trying to use lambda in ServiceLoader which leads to
recursive initialization. It's d
Hi Mike,
Just a warning that CharSubSequenceView is a public class, which is not
what you wanted it to be, I think, since its constructors are pkg private.
IntSupplier trick is nice, but it makes the wrapper object heavier. If the
purpose was to support tracking source sequence length with some o
37 matches
Mail list logo
