Thank you Alan!
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).
Now I've got two suggestions that somehow contradict each other.
Martin suggested to check for particular OS only as a last resort,
On 03/20/2014 11:06 AM, Peter Levart wrote:
I was thinking about last night, for question: Why is this
double-checked non-volatile-then-volatile trick not any faster than pure
volatile variant even on ARM platform where volatile read should have
some penalty compared to normal read?, might be
On 03/19/2014 06:51 PM, Jeremy Manson wrote:
I'm told that the diff didn't make it. I've put it in a Google drive
folder...
https://drive.google.com/file/d/0B_GaXa6O4K5LY3Y0aHpranM3aEU/edit?usp=sharing
Jeremy
Hi Jeremy,
Your factoring-out of expandReplacement() method exposed an
On 2014-03-19 15:57, Andrew Hughes wrote:
I think that's something we must fix ourselves. What we really
need from OpenJDK is a way to build with complete debuginfo in
both binaries and jarfiles.
This was my intent with #2. The jstack/jmap issue needs to be fixed by
stripping less debuginfo
Am 19.03.2014 23:37, schrieb Ulf Zibis:
Am 19.03.2014 23:32, schrieb Martin Buchholz:
No one is as performance obsessed as Ulf.
:-D :-D :-D
And additionally footprint obsessed
-Ulf
On 18/03/2014 6:59 PM, Magnus Ihse Bursie wrote:
On 2014-03-18 02:19, Andrew Hughes wrote:
Do we need more than just the following three alternatives?
#1. No debugging information at all.
#2. Debugging information left in the original binaries.
#3. Debugging information stripped from the
On 20/03/2014 07:25, Ivan Gerasimov wrote:
Now I've got two suggestions that somehow contradict each other.
Martin suggested to check for particular OS only as a last resort, but
without knowing that we run under Unix, we cannot treat a command
absence as an error.
It's always hard to get
I think this OK.
The comments with the o--o did not do much for me though and found them a bit
confusing but perhaps I need more coffee this morning ?
Also, not sure we need the @author tag but I think its usage varies in the
workspace
Best
Lance
On Mar 19, 2014, at 7:10 PM, David Li wrote:
2009? I do have something similar back to 2009 :-)
http://cr.openjdk.java.net/~sherman/regex_replace/webrev/
Then the ball was dropped around the discussion of whether or not
the IOE should be thrown.
But if we are going to/have to have explicit StringBuilder/Buffer pair
anyway, then we can
Thank you Alan!
I think we can assume that none of the tests which need UnixCommands
are for Windows, so I added explicit checking for that.
Having made sure the OS is a Unix (i.e. not Windows), the absence of
a required command now causes an exception to be thrown.
Would you please take a
Hi there,
It would be great if I could get a review please.
The patch is viewable in plain text at JIRA (for IP reasons):
https://bugs.openjdk.java.net/secure/attachment/19216/ParseWithZone.patch
The same patch is viewable in a nice format at GitHub
https://gist.github.com/jodastephen/9505761
On 3/20/2014 8:40 AM, Lance Andersen - Oracle wrote:
I think this OK.
The comments with the o--o did not do much for me though and found them a bit
confusing but perhaps I need more coffee this morning ?
Black or white? :-)
It illustrates an intersection. For example, the result of the
Hi,
Looking for a quick review of the following javadoc clean-up
ljanders-mac:rowset ljanders$ hg diff
diff -r 95e72182e615 src/share/classes/javax/sql/rowset/package.html
--- a/src/share/classes/javax/sql/rowset/package.html Thu Mar 20 16:19:08
2014 +
+++
* Daniel Fuchs:
While playing with JDK 9 javadoc command I noticed that it
seems to treat all single method interfaces as if they were
functional interfaces - even though they don't have the
@FunctionalInterface annotation.
Does it take inheritence into account? If yes, why is this even a
It's a bug because it was an early decision in JDK 8 that got changed:
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-November/002379.html
And then the change:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024165.html
On Thu, Mar 20, 2014 at 2:51 PM,
* Paul Benedict:
It's a bug because it was an early decision in JDK 8 that got changed:
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-November/002379.html
And then the change:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024165.html
So it's a
Hi Stephen,
Given the fact that the parser context is no longer public, the parsed from the
formatter is either unresolved or resolved, just wonder if we really need those
effective chrono and zone fields in Parsed. It appears perfect for me to
simply
keep these info inside the parser context
On 3/19/14 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 from
Obj.java:#482
It appears sun.misc.BASE64Decoder.decodeBuffer(String) uses
String's deprecated
String.getBytes(int srcBegin, int srcEnd, byte[] dst, int
dstBegin). The proposed change
now uses the jvm's default charset. It might trigger incompatible
behavior if the default
19 matches
Mail list logo
