There are two tests under jdk/test/java/util/Base64 that have dependency
on internal API sun.misc.BASE64Encoder sun.misc.BASE64Decoder
java/util/Base64/TestBase64Golden.java
java/util/Base64/TestBase64.java
This fix is to remove the internal API dependency from the tests.
bug:
There are jdk tests that have dependency on sun.misc.DoubleConsts and
sun.misc.FloatConsts.
This fix is to remove above internal API dependency from the tests.
bug: https://bugs.openjdk.java.net/browse/JDK-8042003
webrev: http://cr.openjdk.java.net/~ewang/amylu/JDK-8042003/webrev.00/
The fix:
Hi Peter, Joe,
On 2014-08-14, Peter Levart wrote:
On 08/14/2014 08:47 AM, Joel Borggren-Franck wrote:
On 2014-08-13, Joe Darcy wrote:
Hi Joel,
Does your changeset alter the support (or non-support) of redefining
an annotation?
Hi Joe,
It does not interact with the current non-support
Approved pending a positive review.
On 15.08.2014 17:41, Ivan Gerasimov wrote:
Hello!
I'd like to ask an approval to backport 8017212 into 7u-dev.
The patch does not apply cleanly, however the required modifications are
quite small.
Nevertheless, I will need a peer review for this.
The
Dne Pá 15. srpna 2014 08:39:20, Doug Lea napsal(a):
Sorry for not answering this before you filed JDK-8055183.
No need to apologize, Doug. I don't mind filling issues. We use their mutual
dependencies to track related but otherwise independent problems in NetBeans
bugzilla. I thought OpenJDK
Hi,
As the title says there is a major bug with HttpsURLConnection as it breaks
the contract of equals. So the instance cannot be contained (mostly
removed) in any collection reliably. (Concurrent)HashMap has a provision to
test equality by reference prior calling equals, though.
Finding the bug
I'll file a bug for this Stanimir. Thanks for reporting it.
Should be able to fix it in JDK 9 fairly promptly
and we'll see about back porting it then.
- Michael.
On 18/08/14 15:04, Stanimir Simeonoff wrote:
Hi,
As the title says there is a major bug with HttpsURLConnection as it breaks
the
On 8/18/14 12:08 AM, Amy Lu wrote:
There are two tests under jdk/test/java/util/Base64 that have
dependency on internal API sun.misc.BASE64Encoder sun.misc.BASE64Decoder
java/util/Base64/TestBase64Golden.java
java/util/Base64/TestBase64.java
This fix is to remove the internal API dependency
On 08/18/2014 12:08 AM, Amy Lu wrote:
There are two tests under jdk/test/java/util/Base64 that have dependency on
internal API sun.misc.BASE64Encoder sun.misc.BASE64Decoder
java/util/Base64/TestBase64Golden.java
java/util/Base64/TestBase64.java
This fix is to remove the internal API dependency
Hi Amy,
A few comments here.
This change basically adds a dependency from each of the test files to
both DoubleUtils and FloatUtils test libraries.
This is generally unnecessary. If the use of constants in a test is
fully satisfied by java.lang.{Float, Double}, the test should not depend
Hi Joe, Alan and others
We’re working on moving our internal jaxp functional tests to open idk
repo(Include refactoring effort). This is the first open review I am asking for
SAX and Transform. Would you please review these tests. Any comment will be
appreciated.
I put the webrev as follows:
On Aug 16 2014, at 16:24 , Ulf Zibis ulf.zi...@cosoco.de wrote:
Additionally nice to have:
(initial capacity with initial char(s))
StringBuilder(int,char)
This one is unlikely.
StringBuilder(int,CharSequence)
I don't see much advantage to this API. If it enabled a significant
On Aug 15 2014, at 22:38 , Jeremy Manson jeremyman...@google.com wrote:
No love from core-libs-dev?
Pavel has been looking into this and doing corpus and historical bug checks. It
seems possible that we might consider fixing it as it does seem to be an
ongoing source of errors.
Mike
It's
On 8/18/14 12:49 AM, Amy Lu wrote:
There are jdk tests that have dependency on sun.misc.DoubleConsts and
sun.misc.FloatConsts.
This fix is to remove above internal API dependency from the tests.
bug: https://bugs.openjdk.java.net/browse/JDK-8042003
webrev:
Is there a bug?
Jeremy
On Mon, Aug 18, 2014 at 12:02 PM, Mike Duigou mike.dui...@oracle.com
wrote:
On Aug 15 2014, at 22:38 , Jeremy Manson jeremyman...@google.com wrote:
No love from core-libs-dev?
Pavel has been looking into this and doing corpus and historical bug
checks. It seems
As a general comment, in a new platform release like Java SE 9, it can
be acceptable to add new overrides that would change the meaning of
existing code:
http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy
Truth be told, we've
On Aug 14 2014, at 06:39 , Alan Bateman alan.bate...@oracle.com wrote:
On 14/08/2014 14:23, Claes Redestad wrote:
How about methods only taking beginIndex? Integer.parseInt(x: 1000, 3,
10)? I guess these could to be dropped
to avoid ambiguity and instead allow for variations where radix
Hi Tristan,
Nice work! As with those converted by Eric (8051561), the new tests
looked much better and cleaner than the original ones.
I see that you're using jaxp.library instead of a base class as in
Eric's previous webrev. Is this the final decision on the whole test
structure? It
Thanks Joe
We intend to replace the base class with test library because that doesn’t look
like a real base class but an utilities class.
I haven’t tried to run these tests with security manager, I will run them with
security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014,
What you should have written was:
String s = whatever.stream().collect(joining(, ));
On 8/11/2014 1:31 PM, Pavel Rappo wrote:
Sorry, I should've written this:
Iterable? whatever = ...
StringJoiner joiner = new StringJoiner(, );
whatever.forEach(w -
20 matches
Mail list logo
