On 04/28/2014 05:43 PM, Claes Redestad wrote:
On 04/28/2014 08:57 AM, David Holmes wrote:
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more readable than
just string.toString. This way is more understandable which field is
On 04/29/2014 12:43 AM, Jim Graham wrote:
We refer to these strings as constants in many places. If you have:
class Foo {
static final String bar = really long string;
}
class Blah {
// uses Foo.bar
}
Then Blah will incorporate that string by content, not by reference.
I don't know
On Apr 28, 2014, at 7:53 PM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
Firstly, I was informed that there are not supposed to be binary files in the
jdk9/jdk/test tree. My webrev listed in the above post includes one such
file, a GZIPped text file of prime numbers. Apparently this
On 29 Apr 2014, at 09:22, Paul Sandoz paul.san...@oracle.com wrote:
On Apr 28, 2014, at 7:53 PM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
Firstly, I was informed that there are not supposed to be binary files in
the jdk9/jdk/test tree. My webrev listed in the above post includes
On 2014-04-29 09:31, Remi Forax wrote:
On 04/28/2014 05:43 PM, Claes Redestad wrote:
On 04/28/2014 08:57 AM, David Holmes wrote:
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more readable
than
just string.toString. This way
On 04/28/2014 07:57 AM, David Holmes wrote:
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more readable than
just string.toString. This way is more understandable which field is
required and doesn't impact on performance.
An
On 29/04/2014 7:40 PM, Andrew Haley wrote:
On 04/28/2014 07:57 AM, David Holmes wrote:
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more readable than
just string.toString. This way is more understandable which field is
required
On 04/29/2014 10:58 AM, David Holmes wrote:
On 29/04/2014 7:40 PM, Andrew Haley wrote:
On 04/28/2014 07:57 AM, David Holmes wrote:
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more readable than
just string.toString. This way
On Apr 29, 2014, at 1:53, Brian Burkhalter brian.burkhal...@oracle.com wrote:
1 - Binary test data files are in fact illegal to check in, correct?
They should be avoided as much as you can, but it's not illegal.
Meanwhile I suppose that I could convert my test file and use the
On 29/04/2014 11:31, Wang Weijun wrote:
:
If I understand correctly, the reason why binary data is not preferable is not
because they are not printable, but not human readable. Encoding them to BASE64
or HEX does not really solve the problem. What you need to do is precisely
describing how
On 25/04/2014 22:26, Brian Burkhalter wrote:
Hello,
Issue: https://bugs.openjdk.java.net/browse/JDK-8041683
Patch: http://cr.openjdk.java.net/~bpb/8041683/webrev.00/
It’s not really a solution but the patch changes BitLengthOverflow and
DoubleValueOverflow to catch the OOME and print a
On Apr 29, 2014, at 7:01 AM, Alan Bateman alan.bate...@oracle.com wrote:
This looks okay although I suspect these tests will will throw OOME most of
the time, as it's so common to limit the heap size (512MB is common, I think
is what the make files use for example).
Understood.
Thanks,
On 25/04/2014 00:07, Mandy Chung wrote:
Thanks Sean.
I have updated the webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/
Erik - I'm including build-dev to review the build change for
java.policy file.
Just catching up on this thread.
The update to ZipFileSystem and
Thanks Kumar. Will check these.
I have FXLauncherTest.java open right now as I type. I started looking
at it yesterday. Good
that I am looking at the right test case. Good organization. I might
also have to add a
non FX jar file to test.. unless I've missed that.
-neil
On 4/29/2014
On 4/29/2014 8:50 AM, Neil Toda wrote:
Thanks Kumar. Will check these.
I have FXLauncherTest.java open right now as I type. I started
looking at it yesterday. Good
that I am looking at the right test case. Good organization. I might
also have to add a
non FX jar file to test.. unless
Great. Thanks.
On 4/29/2014 9:45 AM, Kumar Srinivasan wrote:
On 4/29/2014 8:50 AM, Neil Toda wrote:
Thanks Kumar. Will check these.
I have FXLauncherTest.java open right now as I type. I started
looking at it yesterday. Good
that I am looking at the right test case. Good
Hello,
Issue: https://bugs.openjdk.java.net/browse/JDK-8032016
Patch: http://cr.openjdk.java.net/~bpb/8032016/webrev.00/
The performance improvements of this change are marginal but the logic seems
reasonable and the code looks cleaner so I am posting this as an RFC.
Comments?
Thanks,
Thanks, everyone, for comments.
The issue has been circumvented in this case by programmatically generating the
contents of the data file in question:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026668.html
Brian
On Apr 29, 2014, at 5:35 AM, Alan Bateman
diff -r ff056d90e349 make/jprt.properties
--- a/make/jprt.properties
+++ b/make/jprt.properties
@@ -33,7 +33,7 @@
# This tells jprt what default release we want to build
-jprt.hotspot.default.release=jdk8
+jprt.hotspot.default.release=jdk9
19 matches
Mail list logo
