Alan Eliasen wrote:
[snip]
Since I haven't heard of any progress on including my previous patch,
Sorry, still saturated with OpenJDK 6,
-Joe
Rémi Forax wrote:
Hi all,
Is someone knows why package sun.reflect.generics is so complex ?
Because it was written by Gilad ;-)
This package (and subpackage) it used to reify a generics signatures
to a java.lang.reflect.Type tree.
It creates a parser, parse the signature to create an
Martin Buchholz wrote:
If I had known when I started how hard it would be,
I would never have started writing one...
That is the case with many endeavors ;-)
Where are annotations tests supposed to go?
They seem under-test-covered.
I've put it into a new directory,
Hello.
Clemens Eisserer wrote:
Hi,
I currently use an utility-class heavily for the XRender Java2D
backend, which performs saturated casts:
1.) return (short) (x Short.MAX_VALUE ? Short.MAX_VALUE : (x
Short.MIN_VALUE ? Short.MIN_VALUE : x));
2.) return (short) (x 65535 ? 65535 : (x 0) ? 0
Vote: yes
Iris Clark wrote:
Greetings, voting members of the Core Libraries Group!
I nominate Josh Bloch to Membership in the Core Libraries Group.
Please cast your vote by replying, publicly, to this message with
either
Vote: yes
or
Vote: no
as the first line of the message body.
You
Looks good -- approved.
-Joe
Alan Bateman wrote:
6807702: Integer.valueOf cache should be configurable
This is a forward-port from 6u14, which in turn is an update to the
original library updates that Tom Rodriguez did in an earlier 6
update. Joe, you'll probably want to review this one as
Alan Bateman wrote:
Andrew Haley wrote:
:
OK, here it is. I put the test in java/lang/Double/ToString.java
rather than sun/misc/FloatingDecimal because the bug manifested
itself in Double.toString although the fix was in
FloatingDecimal.dtoa.
I agree that test/java/lang/Double is the best
Andrew Haley wrote:
Joseph D. Darcy wrote:
Alan Bateman wrote:
Andrew Haley wrote:
:
OK, here it is. I put the test in java/lang/Double/ToString.java
rather than sun/misc/FloatingDecimal because the bug manifested
itself in Double.toString although the fix
Christopher Hegarty -Sun Microsystems Ireland wrote:
Hi Joe,
The changes look good, but could I ask you to make the same change to
the throws param for getTypeParameters. It looks like it has the same
issue.
Good catch; I'll fix that too.
Thanks,
-Joe
Thanks,
-Chris.
Joe Darcy wrote:
Hello.
Since JDK 5, to implement autoboxing, javac has relied on various static
factory methods in the wrapper classes to perform the caching in the
required range. While the factories said they could cache, they did not
state they would definitely cache in the required range given in JLSv3
Mark Reinhold wrote:
Looks fine to me.
Minor formatting nit in each delta except the first:
...
--- old/src/share/classes/java/lang/Character.java2009-07-08
18:38:13.0 -0700
+++ new/src/share/classes/java/lang/Character.java2009-07-08
18:38:13.0 -0700
@@ -2571,6
Thanks Martin!
-Joe
Martin Buchholz wrote:
Alright, I am all done with jar improvements.
(although the jar command is still far from perfect)
All the fixes (in particular, to make jar faster)
are in openjdk7 and openjdk6.
Martin
On Mon, Jul 6, 2009 at 13:58, Martin Buchholz
Hello.
Please review the patch below to fix
6857789: (reflect) Create common superclass of reflective exceptions
Half a dozen checked exceptions thrown by methods in core reflection
don't have a superclass more specific than Exception, requiring multiple
catch blocks around code using
Rémi Forax wrote:
This request seems dangerous,
InvocationTargetException should not be retrofitted because
usually its catch block is different from the others.
As is, this patch will introduce more burden than it tries to revolve.
If needed InvocationTargetException can continue to have a
Jason Mehrens wrote:
Joe,
Wouldn't LinkageException be a better fit than
ReflectiveOperationException? Shorter name and it would mimic the
LinkageError inheritance tree introduced in JDK1.0. I.E. LinkageError
- NoClassDefFoundError, LinkageException - ClassNotFoundException
this before it goes back.
Otherwise, looks good!
Thanks for the review,
-Joe
Martin
On Thu, Jul 9, 2009 at 15:47, Joseph D. Darcy joe.da...@sun.com
mailto:joe.da...@sun.com wrote:
Hello.
Please review the patch below to fix
6857789: (reflect) Create common superclass
Hello.
Please review this simple patch below to document the long-standing
behavior of parseFloat and parseDouble regarding null inputs. (Yes, the
various string - value methods have inconsistent behavior with respect
to null inputs; however, at this point the safest course of action is
Florian Weimer wrote:
* Rémi Forax:
The solution is to not rely on reflection and to parse the bytecode
using by example ASM :
see http://asm.ow2.org/
I think you'd still need to sort based on line numbers, which requires
debugging information which is not always available.
The only
Rémi Forax wrote:
Florian Weimer a écrit :
* Eamonn McManus:
The proposed change could be made, but it is not just a spec
change. All JVMs that don't currently conform to the spec would need
to change, as Rémi Forax notes, and that includes the JDK and its
derivatives. I'm not a HotSpot
Martin Buchholz wrote:
Of course, it's all my fault.
First, for having used a symbol that libc implementers are likely to add.
Second, for actually asking glibc implementers to add that very symbol.
Third, for forgetting that this is an issue in openjdk6 as well.
Anyways, I intend to commit
Andrew John Hughes wrote:
When java.lang.ReflectiveOperationException was added in:
http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/aaf0cb20646e
it wasn't added to make/java/java/FILES_java.gmk. Although it still
seems to end up in rt.jar when building with IcedTea as the bootstrap
JDK, it fails
Hello.
Please review the patch below is clarify the use of certain exception
types to address bug 6378701 (enum) Unclear purpose of
EnumConstantNotPresentException. Five exceptions/errors can be thrown
by the methods of the AnnotatedElement interface; those methods are used
to retrieve
Alan Bateman wrote:
Joseph D. Darcy wrote:
Hello.
Please review the patch below is clarify the use of certain exception
types to address bug 6378701 (enum) Unclear purpose of
EnumConstantNotPresentException. Five exceptions/errors can be
thrown by the methods of the AnnotatedElement
Hello.
More cleanup of docs build warnings; this time from
javax.sql.rowset.BaseRowSet.java where non-existent getter methods are
repeatedly referenced. Assuming someone approves the change, I'll file
a bug and commit the fix.
-Joe
---
Hello.
Martin Buchholz wrote:
Joe, here's a fix for the stray double quote.
Mea culpa!
I've used {...@code with \u005C with the hope of making Ulf happy.
As usual, we'll need bug filed, etc...
I've filed bug 6879368 Remove stray quote in Character javadoc for
this issue.
diff
Mike Morris wrote:
Joe Darcy wrote:
For JDK 7, I think it is high-time the platform included a class like
java.util.Objects to hold commonly-written utility methods. For
...
What other utility methods would have broad enough use and
applicability to go into a common java.util class?
Ah!
Joe Darcy wrote:
Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 16:48, Joe Darcyjoe.da...@sun.com wrote:
Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 15:48, Joe Darcyjoe.da...@sun.com wrote:
On 09/09/09 08:01 PM, Joe Darcy wrote:
I noticed that the Character class should be similarly
David Holmes - Sun Microsystems wrote:
Stephen Colebourne said the following on 10/07/09 18:10:
BTW, I don't accept the argument that one and only one way to do
something is part of the JDK.
While the JDK is far from a model example of providing one way to do
something, that doesn't mean we
Jason Mehrens wrote:
+1, return empty string for the one arg and add the two arg
variant. The j.u.Properties.getProperty(String, String) could use it
first. Just curious, what does project jigsaw think of j.u.Objects?
I'm preparing the first round of java.util.Objects with the
.
+ */
+
+/*
+ * @test
+ * @bug 6797535
+ * @summary Basic tests for methods in java.util.Objects
+ * @author Joseph D. Darcy
+ */
+
+import java.util.*;
+
+public class BasicObjectsTest {
+public static void main(String... args) {
+int errors = 0;
+errors += testEquals();
+errors
Paul Benedict wrote:
Joe,
I'm preparing the first round of java.util.Objects with the
single-argument static toString method return null for null for final
review.
Why would you choose to return null for any null object?
Because that is how the platform has always treated null in
Paul Benedict wrote:
Why would you choose to return null for any null object?
Because that is how the platform has always treated null in string
concatenation.
If you were defining new operations for String, StringBuilder, or
StringBuffer, I would agree with your choice. Since you
Hello.
In the discussion about java.util.Objects, a few existing JDK methods
were mentioned for possible var-argification:
java.util.Arrays.hashCode(Object[] a)
java.util.Arrays.deepHashCode(Object[] a)
java.util.Arrays.toString(Object[] a)
Also of possible general interest are some methods
Hello.
During the vigorous discussion of what Objects.toString(Object) should
be defined to do, a number of alternatives were suggested:
public static toString(Object a, String default) // return default if (a
== null) else a.toString()
public static toDefaultString(Object a) // return the
Another piece of functionality requested in the j.u.Objects thread was a
deepEquals(Object a, Object b.) method that did the right thing if the
arguments happened to dynamically be arrays.
I've been thinking a bit how this might be implemented.
The array-ness of a and b would need to be
Ulf Zibis wrote:
Am 08.10.2009 20:34, Joseph D. Darcy schrieb:
Hello.
In the discussion about java.util.Objects, a few existing JDK methods
were mentioned for possible var-argification:
java.util.Arrays.hashCode(Object[] a)
java.util.Arrays.deepHashCode(Object[] a)
java.util.Arrays.toString
Please review this tiny doc fix to make EnumSet and EnumMap just a bit
easier to find; patch below
-Joe
--- old/src/share/classes/java/lang/Enum.java2009-10-09
11:41:23.0 -0700
+++ new/src/share/classes/java/lang/Enum.java2009-10-09
11:41:23.0 -0700
@@ -44,6 +44,8 @@
Eamonn McManus wrote:
David Holmes - Sun Microsystems wrote:
So to me: String toString(Object o, String useIfNull) is the only
method
that provides true utility in this case.
I agree with that, and would just suggest to the person specifying the
method
to add a @see String#valueOf(Object).
Paul Benedict wrote:
Joe,
I think java.util.Objects could benefit from the final modifier.
Since its constructor always fails, there is no reason to subclass it
(i.e., super constructor always fails). I believe Josh's Effective
Java book makes such a point about static utility classes.
Paul
, Oct 9, 2009 at 4:13 PM, Joe Darcy joe.da...@sun.com
mailto:joe.da...@sun.com wrote:
Neal Gafter wrote:
Do EnumSet and EnumMap exist on all platform profiles?
They exist on JDK 7 where this change is intended.
-Joe
On Fri, Oct 9, 2009 at 11:43 AM, Joseph D. Darcy
Joshua Bloch wrote:
Joe,
I'm not sure I like this idea. My one experience with forcing an
array method to do double duty as varargs method was a disaster. The
method was Arrays.asList, and the result was Puzzler # 7 from The
Continuing Adventures of Java™Puzzlers: Tiger Traps. Here it is:
Rémi Forax wrote:
Le 12/10/2009 19:25, Joseph D. Darcy a écrit :
Joshua Bloch wrote:
Joe,
I'm not sure I like this idea. My one experience with forcing an
array method to do double duty as varargs method was a disaster.
The method was Arrays.asList, and the result was Puzzler # 7 from
Joshua Bloch wrote:
I don't think method really pays for itself. If it belongs anywhere,
it belongs in java.util.Arrays.
Josh
I think there is room in the platform for this functionality. Even if
this is mostly used in tests, code used in tests is code too :-)
I think Objects
Paul Benedict wrote:
Joe,
I am confused over this warning:
* bWarning: When a single object reference is supplied, the returned
* value does not equal the hash code of that object reference./b This
* value can be computed by calling {...@link #hashCode(Object)}.
I first looked into
Jesús Viñuales wrote:
I agree with Stephen. There are a slew of validation methods that
would be beneficial, and if you really want to drive the JDK towards
standard validation, refactor them out into a Validation class. Look
at what Spring has written for themselves:
Dmitry Nadezhin wrote:
BigInteger is a class implementing arbitrary-precision integers. Of
course, it is an idealization. Let's look at implementation limits of
this type.
The bits are stored in int[] mag array. This sets the maximum bit
length 32*(2^31 - 1).
The
Paul Benedict wrote:
I saw in the release notes the tickets regarding j.u.Objects, but I
don't see the class in the javadoc:
http://download.java.net/jdk7/docs/api/java/util/package-summary.html
Thoughts?
Paul
I believe there was a problem in either generating or posting the b74
docs and
.
On Fri, Oct 16, 2009 at 4:14 PM, Joseph D. Darcy joe.da...@sun.com wrote:
Paul Benedict wrote:
I saw in the release notes the tickets regarding j.u.Objects, but I
don't see the class in the javadoc:
http://download.java.net/jdk7/docs/api/java/util/package-summary.html
Thoughts?
Paul
Alan Bateman wrote:
Joseph D. Darcy wrote:
Hello.
Please review this simple improvement in handling an exceptional
condition in BigInteger. A stack overflow on an argument of
BigInteger.shitf{Left, Right}(Integer.MIN_VALUE) is handled as an
explicit ArithmeticException, the same exception
Dmitry Nadezhin wrote:
I want to make comments to this change from point of view of the post
BigInteger.bitLength() can return negative results.
Suppose that the range of valid BigInteger is restiricted either to
[-2^Integer.MAX_VALUE , 2^Integer.MAX_VALUE-1]
or to
[-2^Integer.MAX_VALUE+1,
Hello.
Please review this webrev to add deepEquals(Object, Object),
hash(Object...) and toString(Object, String) to j.u.Objects:
6891113 More methods for java.util.Objects: deepEquals, hash, toString
with default
http://cr.openjdk.java.net/~darcy/6891113.0/
Thanks,
-Joe
Joe Darcy wrote:
Neal Gafter wrote:
There should be a shortcut in Arrays.deepEquals0 when e1==e2.
That shortcut is in Objects.deepEquals(Object a, Object b) and
Arrays.deepEquals on lines 3947 and 3948. The nested call in
deepEquals0 is to deepEquals rather than deepEquals0 so the
Stephen Colebourne wrote:
Not wishing to confuse the debate, but perhaps the correct place for
this is a static Strings class, that parallels Objects.
We all know that there are lots of possible methods for such a class,
but even if JDK7 had just a few, that would be a good start.
Joe, would
Andrew John Hughes wrote:
2009/11/3 Joseph D. Darcy joe.da...@sun.com:
Hello.
Please review this simple change to replace several calls to val.length()
with an already cached copy of val.length(); patch below.
6897550 BigInteger constructor should use local cached String length
http
Hello.
Please review this simple change to replace several calls to
val.length() with an already cached copy of val.length(); patch below.
6897550 BigInteger constructor should use local cached String length
http://cr.openjdk.java.net/~darcy/6897550.0/
-Joe
---
Jonathan Gibbons wrote:
Andrew John Hughes wrote:
2009/12/4 joe.da...@sun.com:
Changeset: 1755493c5774
Author:darcy
Date: 2009-12-03 18:19 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1755493c5774
6907177: Update jdk tests to remove unncessary -source and -target
Kelly O'Hair wrote:
Need reviewer for JDK7 testing changes, e.g. testing via:
cd jdk/make gmake all images cd ../test gmake jdk_all
6906210: Fix another minor typo in test/Makefile
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-test-changes4/webrev/
Dan had pointed out my typo in the
Andrew John Hughes wrote:
2009/12/10 Joe Darcy joe.da...@sun.com:
Hello.
While doing a coredocs build, I noticed once again some javadoc warnings
coming out of the javax.accessibility package and I decided to fix them; the
patch is below and the full webrev is at
Hello.
Another round of javadoc build warnings fixes for review; this time
mostly in rmi, but one in security and another in management.
Patch below; webrev at
http://cr.openjdk.java.net/~darcy/6909563.0/
-Joe
---
old/src/share/classes/java/lang/management/PlatformManagedObject.java
Hello.
Please review my fix for
6908131 Pure Java implementations of StrictMath.floor(double)
StrictMath.ceil(double)
http://cr.openjdk.java.net/~darcy/6908131.0/
I've asked Doug Priest, one of Sun's numerical experts, to review the
floor/ceil algorithm and testing. I've incorporated his
Christian Thalinger wrote:
On Mon, 2009-12-14 at 01:31 -0800, Joseph D. Darcy wrote:
Hello.
Please review my fix for
6908131 Pure Java implementations of StrictMath.floor(double)
StrictMath.ceil(double)
http://cr.openjdk.java.net/~darcy/6908131.0/
I've asked Doug Priest, one of Sun's
Alan Bateman wrote:
Joseph D. Darcy wrote:
Hello.
Please review my fix for
6908131 Pure Java implementations of StrictMath.floor(double)
StrictMath.ceil(double)
http://cr.openjdk.java.net/~darcy/6908131.0/
I've asked Doug Priest, one of Sun's numerical experts, to review the
floor/ceil
Dmitry Nadezhin wrote:
The current specification of the interesting methods in
StrictMath, such as sin/cos, log, etc. are to use the FDLIBM
algorithms.
Thank you. I forgot about these lines in java.lang.StrictMath .
[snip]
As specification of java.lang.StrictMath is in terms of reference
Hi Kelly.
Can you verify the changes I've made to BigIntegerTest.java in my fix for
6908541 Bad resource management in
java/math/BigInteger/BigIntegerTest.java
http://cr.openjdk.java.net/~darcy/6908541.0/
get the test off the bad test list?
Thanks,
-Joe
Hello.
Please review this simple typo fix for 6828204 NavigableSet.subSet()
documentation refers to nonexistent parameters:
--- old/src/share/classes/java/util/NavigableMap.java2010-01-11
13:13:28.0 -0800
+++ new/src/share/classes/java/util/NavigableMap.java2010-01-11
to fixed state.
-Joe
Bruce
Joseph D. Darcy wrote:
Hello.
Please review my patch to fix 6908218 java.lang.Deprecated should
have explicit @Target meta-annotation.
For background, JSR 308 added two new enum constants to ElementType.
ElementType constants are used
Jeff Hain wrote:
Hi all.
Dmitry, here is the link:
http://sourceforge.net/projects/jafama/
The non-wrong treatments could be mainly:
- round(double), floor(float), ceil(float), round(float),
- maybe hypot(double,double) (Math.hypot delegates to StrictMath.hypot,
which is very slow on my
Jeff Hain wrote:
It seems to me that LGPL v3 is not compatible with OpenJDK's GPL v2.
OpenJDK can't include fragments of LGPL v3 code without
permission of omaamo, can it ?
Dmitry,
oma is one of my multiple names (but I'll stick to Jeff now
for my developper incarnation, in case I
Dmitry Nadezhin wrote:
Joe,
I'm interested in micro-benchmarking of math in OpenJDK .
This includes a choice of proper framework, a choice of representative
patterns (or testsuites).
Will math micro-benchmarking be ever hosted by OpenJDK ?
Or I should develop them elsewhere ?
The site
Alan Eliasen wrote:
[snip]
I'm the submitter of these patches [BigInteger] which are almost
two years old in a couple of weeks, with still no approval. And these
multiplication patches are only a small part of the work that needs to
be done on BigInteger. I also have
Andrew John Hughes wrote:
On 25 February 2010 18:19, Kelly O'Hair kelly.oh...@sun.com wrote:
Looks fine to me.
-kto
On 2/25/10 9:51 AM, Alan Bateman wrote:
There are two fixes in Sun's proprietary jdk6 updates that should also
be fixed in OpenJDK.
The first one is that the
Hi Amy,
The fix looks fine; approved to go back,
Thanks,
-Joe
On 1/19/2015 1:34 AM, Amy Lu wrote:
Please review the fix for Doclint regression in
java.nio.channels.Channels, removed the empty p tag.
bug: https://bugs.openjdk.java.net/browse/JDK-8069262
webrev:
Hi Brian,
Looks fine; just adjust the copyright dates before pushing.
Thanks,
-Joe
On 2/6/2015 12:29 PM, Brian Burkhalter wrote:
On Feb 6, 2015, at 7:46 AM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
On Feb 6, 2015, at 12:51 AM, Paul Sandoz paul.san...@oracle.com wrote:
+1, but
On 1/27/2015 12:15 PM, Doug Lea wrote:
On 01/27/2015 08:44 AM, Buis, Paul wrote:
The slowdown would be passing a single extra integer parameter,
decrementing it and comparing it to zero at the beginning of the
function.
Right. The question is whether even a small slowdown is warranted.
Hi Brian,
The new version looks fine. One suggestion to consider: creating a small
private helper method to do the len, off, array-length check. (The two
copies of the logic are slightly different.)
Thanks,
-Joe
On 1/2/2015 4:09 PM, Brian Burkhalter wrote:
Hello all,
Thanks for the
Hello,
Getting back to this issue in the new year, taking a closer look at the
existing class-level documentation, I don't really see a compelling case
for an edit this large.
I for one would be content if the bug were closed as not an issue.
HTH,
-Joe
On 12/22/2014 10:46 AM, Brian
Hello,
I don't have a comment on the changes to the test per se, but as someone
who keeps an eye on test failures that occur in regression tests in the
jdk repo of the JDK 9 dev forest, I'd like to see this test stop
failing, either by the test being fixed for, barring that, the testing
On 1/7/2015 2:04 PM, Brian Burkhalter wrote:
On Jan 7, 2015, at 12:08 AM, Andreas Lundblad
andreas.lundb...@oracle.com mailto:andreas.lundb...@oracle.com wrote:
On Mon, Jan 05, 2015 at 05:43:26PM -0800, Joseph D. Darcy wrote:
Hello,
Getting back to this issue in the new year, taking
On 1/7/2015 9:39 AM, Brian Burkhalter wrote:
On Jan 7, 2015, at 1:23 AM, Paul Sandoz paul.san...@oracle.com wrote:
In java.util.Formatter.BigDecimalLayout.layout() trailing zeroes are
erroneously appended when the unscaled value of the BigDecimal is zero and the
scale is negative. Some other
Hello,
Per recent proposals
(http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html), please
review the change below for
JDK-8075565: Define @intermittent jtreg keyword and mark
intermittently failuring jdk tests
http://cr.openjdk.java.net/~darcy/8075565.0/
which
Looks good; thanks,
-Joe
On 3/6/2015 12:03 PM, Brian Burkhalter wrote:
Please review at your convenience:
Issue: https://bugs.openjdk.java.net/browse/JDK-8074460
Patch: http://cr.openjdk.java.net/~bpb/8074460/webrev.00/
Summary: Create a utility class which creates a pseudorandom number
Hi Mandy,
If there is agreement on this internally, I suggest floating a trial
balloon on jdk9-dev.
Cheers,
-Joe
On 3/30/2015 2:37 PM, Mandy Chung wrote:
There are several existing ways to do native to ascii conversion. For
example, IDEs like NetBeans and IntelliJ support the transparent
Hello,
Sorry for the belated reply, I tried the URLs and some obvious
variations, but the webrevs didn't come up as being there.
Have they been moved?
Thanks,
-Joe
On 2/18/2015 12:17 PM, Ivan St. Ivanov wrote:
Hi Joe, core libs developers,
Last night we had a hackathon in Bulgarian Java
Hi Stuart,
Since try-with-resources is just a desugaring, I think the statements like
[The resource] must be opened as a resource within a
try-with-resources
136 * statement to ensure that it is closed promptly after its
operations have completed.
should be replaced with the
Hi Stuart,
The revised version looks good; thanks,
-Joe
On 3/2/2015 6:43 PM, Stuart Marks wrote:
Hi Joe,
Oh yes, good point. Revised webrev:
http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.1/
Thanks,
s'marks
On 3/2/15 6:14 PM, Joseph D. Darcy wrote:
Hi Stuart,
Since try
at 2:05 AM, Joseph D. Darcy joe.da...@oracle.com
mailto:joe.da...@oracle.com wrote:
Hello,
Sorry for the belated reply, I tried the URLs and some obvious
variations, but the webrevs didn't come up as being there.
Have they been moved?
Thanks,
-Joe
On 2/18/2015 12
Hi Roger,
Doesn't jtreg define a test-specific scratch directory? Is that not
available to TestNG tests?
Cheers,
-Joe
On 2/26/2015 1:14 PM, Roger Riggs wrote:
Please review this test fix to make the test more robust to
configuration and
pollution of the temp directory.
Webrev:
I don't think that usage would be inappropriate, but I don't think it is
called for here either.
Thanks,
-Joe
On 1/29/2015 1:01 PM, Brian Burkhalter wrote:
Would it be appropriate to put the parenthetic information in the new
lines 91-93 in an @implSpec or other such section?
Brian
On Jan
Hello,
I'm fine with version 1 as well.
Cheers,
-Joe
On 1/29/2015 1:07 PM, Roger Riggs wrote:
Hi Brian,
#1, The current webrev is fine as is. (Perhaps with a 2015 copyright
update).
Since the methods are abstract, the general description is sufficient and
the subclass would have more
Jon,
The actual file move looks fine to me.
Thanks,
-Joe
On 4/2/2015 4:52 PM, Jonathan Gibbons wrote:
Sorry for the relatively wide distribution.
JDK-8076583 is a conceptually simple cleanup, to move the source file
for the jdk.Exported class from the langtools repo (where it is a
Hello,
As the next step of implementing Proposed new policies for JDK 9
regression tests: tiered testing, intermittent failures, and randomness
[1], please review this changeset which adds a randomness jtreg
keyword and tags 240 regression tests in the jdk repository with the
keyword:
Hello,
I'd like to get this changeset, or something close to it, pushed soon so
we can start taking advantage of better failure triaging.
Any further concerns?
Thanks,
-Joe
On 4/24/2015 11:04 AM, joe darcy wrote:
On 4/23/2015 10:58 PM, Alan Bateman wrote:
On 24/04/2015 02:54, Joseph D
Hi Brian,
On 4/29/2015 4:25 PM, Brian Burkhalter wrote:
Hi Joe,
No, RandomFactory would have been added by the previous webrev.00
version of the patch, i.e., RandomFactory did not come from RandomSeed.
Is this reasonable?
Thanks,
Sounds reasonable (they two files didn't necessarily look
/5/2015 3:25 PM, Xueming Shen wrote:
looks fine.
On 5/5/15 2:53 PM, Joseph D. Darcy wrote:
Hello,
The regression test
test/java/util/regex/RegExTest.java
has been observed to intermittently fail. As the test uses
randomness, I'd like to update to the test to use the random number
testing
How about as a first sentence
The Documented meta-annotation indicates whether or not annotations of
the annotation types it annotates are considered part of the public
contract of the elements they in turn annotate.
(Admittedly still a bit convoluted.)
-Joe
On 5/11/2015 4:07 PM, Jonathan
Looks fine Kumar; thanks,
-Joe
On 5/5/2015 1:37 PM, Kumar Srinivasan wrote:
Hello,
Please review the simple fix which allows the test to be run in its
own vm,
there seems to be some issue with the harness running in a concurrent
mode
specifically on Windows.
Thanks
Kumar
diff --git
Hello,
The regression test
test/java/util/regex/RegExTest.java
has been observed to intermittently fail. As the test uses randomness,
I'd like to update to the test to use the random number testing library
to better identify the cause of any future failures.
Please review the patch
Hello,
Not providing a code review, but I wanted to state I think this is a
very good sort of cleanup and worthwhile to get into the platform once
the details have been worked through.
Thanks,
-Joe
On 5/12/2015 3:10 PM, Patrick Reinhart wrote:
Hi Pavel,
Is there anything I can do in the
Note that one possible feature of JDK 9 is a -platform N option to javac
which would allow compiling against older versions of the platform
libraries:
JEP draft: Compile for Specific Platform Version
http://openjdk.java.net/jeps/8058150
This feature would address some of the concerns
On 5/19/2015 7:14 PM, Martin Buchholz wrote:
Thanks, Roger. This is a much better test now (but still not actually a
good one...)
Probably want to be optimistic and delete
+ * @key intermittent
That is an interesting (and as yet unresolved) policy question: how
should removal of
1 - 100 of 265 matches
Mail list logo
