Hi,
http://cr.openjdk.java.net/~psandoz/tl/JDK-8021863-concat-size/webrev/
This patch just tidies up calculating whether the concatenating spliterator is
unsized or not before splitting. There was a typo when checking spliterator
characteristics, but it turns out the characteristics do not
On Jul 30, 2013, at 3:43 AM, Henry Jen henry@oracle.com wrote:
Sorry, the webrev is at
http://cr.openjdk.java.net/~henryjen/tl/8020977/0/webrev/
Looks ok to me.
Paul.
This whole issue started with the fix of
http://bugs.sun.com/view_bug.do?bug_id=8016814 because, obviously, throwing an
UnsupportedOperationException is a straightforward and reasonable way of fixing
an off-by-one problem with the description returns the wrong stack frame (see
On 07/27/2013 09:01 PM, Nick Williams wrote:
All,
In the last two months, there have been a number of discussions surrounding
stack traces, Classes on the stack trace, and caller classes [1], [2], [3].
These are all related discussions and the solution to them is equally related,
so I
42 MILLION uses of Reflection.getCallerClass(int) on Ohloh!?!? Holy crap...
In case anyone is interested, I am almost finished implementing the public API
StackTraceFrame and associated C/C++ code. It has been an eye-opening
experience, but I think I have it figured out now. I just have to
For caller-sensitive methods, the approach taken with new
Reflection.getCallerClass() is the right one, I think. There's no need to
support a fragile API when caller-sensitivity is concerned, so the lack of
int parameter, combined with annotation for marking such methods is correct
approach, I
On 07/30/2013 12:02 PM, Paul Sandoz wrote:
On Jul 30, 2013, at 3:43 AM, Henry Jen henry@oracle.com wrote:
Sorry, the webrev is at
http://cr.openjdk.java.net/~henryjen/tl/8020977/0/webrev/
Looks ok to me.
+1 looks good to me too.
-Chris.
Paul.
I think there are various techniques to use new API when running on JDK8
and still use old API when running on JDK6 or 7. One way is to have 2
classes implementing the same interface or extending basic class where
one is compiled with JDK6/7 and the other with JDK8. During runtime the
correct
Omitting the int parameter would be a bad idea since it would prevent
wrappers. One could imagine a common interface to obtain the caller class where
the proper implementation is chosen via fallback, e.g.
- if available, use our new API (fastest?)
- else, try to use Reflection.getCallerClass
On Jul 30, 2013, at 7:45 AM, Peter Levart wrote:
I think there are various techniques to use new API when running on JDK8 and
still use old API when running on JDK6 or 7. One way is to have 2 classes
implementing the same interface or extending basic class where one is
compiled with
On Tue, Jul 30, 2013 at 8:25 AM, Nick Williams
nicholas+open...@nicholaswilliams.net wrote:
42 MILLION uses of Reflection.getCallerClass(int) on Ohloh!?!? Holy crap...
Considering that the Ohloh search results page also bolds occurrences of
Reflection, class and get for that search [0], I
Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
So what would give Groovy or other language runtimes headaches when all
there was was a parameter-less getCallerClass() API? Aren't the
intermediate frames inserted by those runtimes controlled by the
runtimes? Couldn't the surface
On 29/07/2013 10:06, Alexey Utkin wrote:
Thanks, Alan
I did if reformatting and small refactoring for the code in function
in accordance with
https://jbs.oracle.com/bugs/browse/JDK-5008166
recommendations. I am sure that the presence of path separator has no
dependence from search
I'm working on a patch for some core libraries (hence why I'm emailing here --
hopefully someone will be sympathetic and help) and need to run the JDK tests.
I'm following the instructions on http://openjdk.java.net/jtreg/build.html to
get jtreg installed so that I can run it. I have JDK15HOME
Hi,
http://cr.openjdk.java.net/~psandoz/tl/JDK-8021883-random-stream-test/webrev/
This patch updates tests for ThreadLocalRandom streams and increases the
timeout duration. Although the original should be enough for most cases in
certain virtualized and emulated environments it might not be. I
The jtreg-use list is probably the right place for this question.
-Alan.
On 30/07/2013 06:37, Nick Williams wrote:
I'm working on a patch for some core libraries (hence why I'm emailing here --
hopefully someone will be sympathetic and help) and need to run the JDK tests.
I'm following the
On 7/30/2013 5:24 PM, Alan Bateman wrote:
On 29/07/2013 10:06, Alexey Utkin wrote:
Thanks, Alan
I did if reformatting and small refactoring for the code in
function in accordance with
https://jbs.oracle.com/bugs/browse/JDK-5008166
recommendations. I am sure that the presence of path
On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
So what would give Groovy or other language runtimes headaches when all
there was was a parameter-less getCallerClass() API? Aren't the
intermediate frames inserted by those runtimes controlled by
On 07/29/2013 09:06 PM, Brian Burkhalter wrote:
Joe / Chris:
The updated webrev is in the same place,
http://cr.openjdk.java.net/~bpb/8020539/
If this looks good I will need an approval.
It looks ok to me.
-Chris.
On Jul 29, 2013, at 12:05 AM, Joe Darcy wrote:
I recommend a few changes
Hi Peter,
Given that the user cannot specify gamma values and the for the first 2^16+1
gamma values the minimum bit count is 15, the maximum bit count is 50 and the
minimum width is 45, is that not sufficient? i.e. is it likely there will be
more than 65537 splits?
In the streams API one
On 07/30/2013 04:25 PM, Paul Sandoz wrote:
Hi Peter,
Given that the user cannot specify gamma values and the for the first 2^16+1
gamma values the minimum bit count is 15, the maximum bit count is 50 and the
minimum width is 45, is that not sufficient? i.e. is it likely there will be
more
On 07/29/13 14:29, Peter Levart wrote:
On 07/16/2013 06:01 PM, Guy Steele wrote:
So I think we will not hit any really bad gamma values in practice.
Would it be possible to skip gammas with less than 12 or more than 52 bits?
Or better, eliminate dependence on bit density.
I'm working
Looks ok to me Paul.
-Chris.
On 07/30/2013 11:53 AM, Paul Sandoz wrote:
Hi,
http://cr.openjdk.java.net/~psandoz/tl/JDK-8021863-concat-size/webrev/
This patch just tidies up calculating whether the concatenating spliterator is
unsized or not before splitting. There was a typo when checking
Am 30.07.2013 16:16, schrieb Peter Levart:
On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
So what would give Groovy or other language runtimes headaches when all
there was was a parameter-less getCallerClass() API? Aren't the
intermediate
Hello everybody!
HashTable needs to calculate the power of two that is not less that the
given number.
This calculation used to be implemented as a relatively inefficient loop
(that's why the issue 7192942 was created).
The implementation was improved with
Paul,
This looks like a nice cleanup, as well as fixing the timeout issue.
I just don't get the change in failure criteria. The old test used to
verify that the arrays of random numbers of all generating threads were
not equal, but now your checking the number of tasks?
-Chris.
Hi,
On Jul 30, 2013, at 4:57 PM, Chris Hegarty chris.hega...@oracle.com wrote:
Paul,
This looks like a nice cleanup, as well as fixing the timeout issue.
I just don't get the change in failure criteria. The old test used to verify
that the arrays of random numbers of all generating threads
On 07/30/2013 05:14 PM, Paul Sandoz wrote:
On Jul 30, 2013, at 4:57 PM, Chris Hegarty chris.hega...@oracle.com wrote:
Paul,
This looks like a nice cleanup, as well as fixing the timeout issue.
I just don't get the change in failure criteria. The old test used to verify
that the arrays of
Hi Ivan;
This looks like a good improvement. My only disappointment is that I didn't
notice it when adding the roundUpToPowerOf2 method!
Do you need a sponsor to push the fix?
Mike
On Jul 30 2013, at 08:35 , Ivan Gerasimov wrote:
Hello everybody!
HashTable needs to calculate the power of
On Jul 30, 2013, at 5:25 PM, Chris Hegarty chris.hega...@oracle.com wrote:
On 07/30/2013 05:14 PM, Paul Sandoz wrote:
On Jul 30, 2013, at 4:57 PM, Chris Hegarty chris.hega...@oracle.com wrote:
Paul,
This looks like a nice cleanup, as well as fixing the timeout issue.
I just don't get
Thanks, Mike!
Yes, I need a sponsor and would really appreciate your help.
Sincerely yours,
Ivan
On 30.07.2013 20:32, Mike Duigou wrote:
Hi Ivan;
This looks like a good improvement. My only disappointment is that I didn't
notice it when adding the roundUpToPowerOf2 method!
Do you need a
Looks good to me as well.
Mike
On Jul 29 2013, at 19:30 , Henry Jen wrote:
Hi,
Please review a simple fix for 8020977.
The fix grab the length before initiate copying operation, so that the
'delimiter' added for this won't be included in copy.
For rest cases, the timing window
On 07/30/2013 07:35 PM, Ivan Gerasimov wrote:
I also created a benchmark test to make sure the improvement is observable.
Here's the jmh benchmark I used:
http://cr.openjdk.java.net/~igerasim/bench/powoftwo/src/main/java/org/benches/PowerOfTwoBench.java
Hi Henry,
A couple minor comments on this.
I don't think it's necessary to snapshot other.value into a local otherBuilder
variable. If other == this, when the value is mutated by prepareBuilder(),
otherBuilder still points to this.value, whose contents have changed. So the
actual data isn't
On 30.07.2013 20:47, Aleksey Shipilev wrote:
On 07/30/2013 07:35 PM, Ivan Gerasimov wrote:
I also created a benchmark test to make sure the improvement is observable.
Here's the jmh benchmark I used:
I'm running the core libs tests locally (for the first time), and every java.io
test is failing. They're all failing for the same reason (output below), and I
suspect it's something local and not an actual problem. But the test output is
not very helpful. Note that all of the java.beans tests
Changeset: c76f89695c90
Author:juh
Date: 2013-07-30 11:04 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c76f89695c90
8021833: javadoc cleanup in java.net
Summary: code and tt converted to {@code }; package.html to
package-info.java
Reviewed-by: darcy, chegar
!
On 30/07/2013 11:02, Nick Williams wrote:
I'm running the core libs tests locally (for the first time), and every java.io
test is failing. They're all failing for the same reason (output below), and I
suspect it's something local and not an actual problem. But the test output is
not very
On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
On 30/07/2013 11:02, Nick Williams wrote:
I'm running the core libs tests locally (for the first time), and every
java.io test is failing. They're all failing for the same reason (output
below), and I suspect it's something local and not an
On Jul 30, 2013, at 1:16 PM, Nick Williams wrote:
On Jul 30, 2013, at 1:10 PM, Alan Bateman wrote:
On 30/07/2013 11:02, Nick Williams wrote:
I'm running the core libs tests locally (for the first time), and every
java.io test is failing. They're all failing for the same reason (output
On Jul 30, 2013, at 10:00 AM, Stuart Marks stuart.ma...@oracle.com wrote:
Hi Henry,
A couple minor comments on this.
I don't think it's necessary to snapshot other.value into a local
otherBuilder variable. If other == this, when the value is mutated by
prepareBuilder(), otherBuilder
On 7/29/13 7:48 AM, Alan Bateman wrote:
On 29/07/2013 07:12, Bob Vandette wrote:
Excuse me if I'm a bit frustrated by this issue ...
We keep going around and around on this issue. We had a discussion with
Stuart and the JCK
team and Stuart didn't want to change the specification. Has he now
Okay, this is indeed very interesting. After two hours it was only about
half-way through the java.io tests and all of them had failed so far. On a
sheer hunch and nothing more, I unplugged my ethernet cable, thus disconnecting
me from any/all networks and the Internet. BOOM. The rest of the
jtreg itself does not stop on error. If you're driving the tests
through the makefiles, the makefiles may partition the work into
separate jtreg runs on separate parts of the test suite.
-- Jon
On 07/30/2013 01:13 PM, Nick Williams wrote:
Okay, this is indeed very interesting. After two
Regarding the hostname, jtreg is executing the following code for all
tests, not just java.io tests
String hostname;
try {
hostname = InetAddress.getLocalHost().getCanonicalHostName();
} catch (UnknownHostException e) {
hostname = unknown;
Ahhh. I know what's going on.
http://blog.leon-rosenberg.net/2012/08/oracle-kills-getlocalhost-on-macos-x-in.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7180557
Maybe someone can fix this year-old Java 7 bug that makes getLocalHost() not
work sometimes on Mac OS X? :-)
N
On Jul
Updated webrev adapting feedback from Stuart.
I need a sponsor to push the fix. Thanks for reviewing.
Cheers,
Henry
On 07/30/2013 11:27 AM, Henry Jen wrote:
On Jul 30, 2013, at 10:00 AM, Stuart Marks stuart.ma...@oracle.com wrote:
Hi Henry,
A couple minor comments on this.
I don't
Gotchya.
I commented out the java.io tests locally for now.
By the way, I noticed something. Before, when the java.io tests were failing,
the output said hostname=unknown. However, now that I'm connected to the VPN
and they're passing, the output says hostname=10.211.55.2. When I unplug from
On 07/30/2013 01:58 PM, Henry Jen wrote:
Updated webrev adapting feedback from Stuart.
I need a sponsor to push the fix. Thanks for reviewing.
Sigh, again, the webrev is at
http://cr.openjdk.java.net/~henryjen/tl/8020977/1/webrev/
Cheers,
Henry
Bumped the isue to P2, marked it Affect 8 and added a link to this thread.
-- Jon
On 07/30/2013 01:57 PM, Nick Williams wrote:
Ahhh. I know what's going on.
http://blog.leon-rosenberg.net/2012/08/oracle-kills-getlocalhost-on-macos-x-in.html
Changeset: 8bc1bbd5b659
Author:sherman
Date: 2013-07-30 14:43 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8bc1bbd5b659
8021767: test/java/time/tck/java/time/format/TCKFormatStyle.java failing
Summary: Correct to use fixed locale, not locale of test environment
On 7/30/13 1:59 PM, Henry Jen wrote:
On 07/30/2013 01:58 PM, Henry Jen wrote:
Updated webrev adapting feedback from Stuart.
I need a sponsor to push the fix. Thanks for reviewing.
Sigh, again, the webrev is at
http://cr.openjdk.java.net/~henryjen/tl/8020977/1/webrev/
Looks good, thanks
My bad, you should be on the reviewer list. After all, this update is based on
your feedback.
Webrev updated with Reviewed-by.
Cheers,
Henry
On Jul 30, 2013, at 3:03 PM, Stuart Marks stuart.ma...@oracle.com wrote:
On 7/30/13 1:59 PM, Henry Jen wrote:
On 07/30/2013 01:58 PM, Henry Jen
Apple is highly unlikely to change the behavior of nl_langinfo().
There is already code in the JDK that calls into JRSCopyPrimaryLanguage(),
JRSCopyCanonicalLanguageForPrimaryLanguage(), and JRSSetDefaultLocalization()
for exactly this purpose.
Please proceed with setting the encoding to
I was about to chime in that UTF-8 has been the preferred encoding for (stored)
text on Mac OS X as long as I've been hacking on it (think Rhapsody), so why
is this even an issue?
Judging from the docs, nl_langinfo seems like a Unix portability function
(something more likely to be happier
Quick question for those of you that know anything about @CallerSensitive...
After looking at the code and experimenting some, I've discovered that
getCallerClass() doesn't actually keep going until it finds the first method
without @CallerSensitive. It only returns the caller of the caller.
Changeset: 09a77a1bdbc3
Author:henryjen
Date: 2013-07-30 15:47 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09a77a1bdbc3
8020977: StringJoiner merges with itself not as expected
Reviewed-by: psandoz, chegar, mduigou, smarks
! src/share/classes/java/util/StringJoiner.java
On 7/30/13 4:06 PM, David DeHaven wrote:
I was about to chime in that UTF-8 has been the preferred encoding for (stored) text on
Mac OS X as long as I've been hacking on it (think Rhapsody), so why is this
even an issue?
Judging from the docs, nl_langinfo seems like a Unix portability
On Jul 29 2013, at 04:20 , Paul Sandoz wrote:
Hi Mike,
V. quick review below.
On Jul 27, 2013, at 12:31 AM, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
This patch adds some missing checks for null that, according to interface
contract, should be throwing NPE. It also
If Mike endorses this approach then I step aside.
My point, as Scott noted, is that we get this info from the OS. So
either the OS is at fault or we're asking the wrong question. Based on
Mike's response we're asking the wrong question - but if the end result
will be UTF-8 regardless then
60 matches
Mail list logo
