On 02/11/2013 00:07, Brian Burkhalter wrote:
Please review at your convenience:
Issue:
https://bugs.openjdk.java.net/browse/JDK-8027625
Patch:
Thanks for that, this test has been failing with OOME in some
environments since the recent change.
-Alan.
On 01/11/2013 11:18, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8.
Most of tests in the sound area, and some tests in the client,
java.lang, security, jmx etc has incorrect copyright.
According to the http://openjdk.java.net/faq
GPL v2 + the Classpath exception for the class
On 31/10/2013 19:54, huizhe wang wrote:
A quick fix to remove path for the temporary output file so that it's
created in the working directory instead:
http://cr.openjdk.java.net/~joehw/jdk8/8024876/webrev/
Just reading this now and wondering about xslFilename - is that closed
(as it's not
On 04/11/2013 08:33, Peter Levart wrote:
:
What about the following helper class in java.lang package:
If public then it leaks into the Java SE API. I think using
SharedSecrets should be okay, assuming we can sort out any potential
races getting to JavaLangAccess.
-Alan.
On 04/11/2013 12:10, David Holmes wrote:
My commit pulled in a bunch of local changes that should never have
been pushed (the import commit failed due to whitespace and when I
re-issued the commit I didn't restrict it to the single test file).
Can anyone roll this back on the actual server?
On 04/11/2013 22:32, huizhe wang wrote:
:
It's closed, but outFilename was not. Since the behaviors are
different among parsers, I've added them all in a try-with-resources
statement.
Please review:
http://cr.openjdk.java.net/~joehw/jdk8/8024876/webrev/
Thanks, that makes it clear.
(I see
On 05/11/2013 09:26, Amy Lu wrote:
:
Please review ProblemList.txt changes:
https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html
This looks okay to me although I'm not sure about
sun/util/resources/TimeZone/Bug6317929.java (for some reason Aleksej
fixed the test
On 01/11/2013 17:57, Paul Sandoz wrote:
Hi,
This is a eating humble pie and should of correctly listened to Henry in
review kind of email :-)
The changes to DistinctOpTest recently committed result in a test failure,
since one of the tests is incorrectly asserting on a particular element,
On 05/11/2013 02:21, Mandy Chung wrote:
Fixed. Revised webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/
I looked at the latest webrev.
Having runFinalization and runAllFinalizers be a no-open during
initialization is reasonable (it should never happen).
I
Adding i18n-dev as this is the mailing list where this area is maintained.
On 05/11/2013 17:26, Aleksej Efimov wrote:
Hi,
Can I have a review for a 8027848 [1] bug fix . There is unimplemented
functionality related to the future GMT offset changes.
The ZoneInfoFile class doesn't analyses if
On 05/11/2013 16:38, Aleksej Efimov wrote:
Hi,
Can I have a review for tzdata2013h integration [1]. The webrev link
can be located here [2].
The following test sets were executed on build with fix:
test/sun/util/calendar test/java/util/Calendar
test/sun/util/resources/TimeZone
On 06/11/2013 13:30, Rob McKenna wrote:
Yes, absolutely. I'm looking for approval for the code in principle.
Particularly the change in the default property value on Solaris since
thats the only change. Once approved I will of course seek approval
for integration.
I think the proposal is
On 06/11/2013 03:51, Mike Duigou wrote:
I have updated the webrev to backout the changes to how JT_HOME is set. This
will be addressed in the next set of changes (8020779
https://bugs.openjdk.java.net/browse/JDK-8020779 and 8009683
https://bugs.openjdk.java.net/browse/JDK-8009683) which will
On 05/11/2013 21:37, Rob McKenna wrote:
Apologies, I forgot to mention the dependency on:
8008118: (process) Possible null pointer dereference in
jdk/src/solaris/native/java/lang/UNIXProcess_md.c
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/0111bab8dc35
-Rob
To keep the changes the same
On 07/11/2013 03:48, Patrick Zhang wrote:
Hi Everyone,
I am working on https://bugs.openjdk.java.net/browse/JDK-8019502. The
problem is, some java.util test does use ${TESTVMOPTS} to launch java
program in script. Then it may lose VM setting from high level.
The fix will refer to
On 05/11/2013 16:28, Sergey Bylokhov wrote:
Hello,
Updated version:
http://cr.openjdk.java.net/~serb/8027696/webrev.01/
Dates and spaces were fixed.
Thanks Sergey, I sampled a few and they look correct.
The only thing is that I'm not sure about is test/Makefile, it's just
not clear whether
On 07/11/2013 11:34, Chris Hegarty wrote:
:
I've also received another comment offline about the method names.
They should be more descriptive, and highlight the difference between
these methods and regular delete. So maybe move to public
deleteWithRetry?
That might be a bit better as
On 07/11/2013 13:52, Rob McKenna wrote:
I've added a review showing the differences to jdk8 to:
http://cr.openjdk.java.net/~robm/5049299/7/webrev.02/
That makes it easy, thanks. At L100 then I assume you mean posix_spawn
rather than spawn.
-Alan
On 07/11/2013 17:33, Volker Simonis wrote:
Hi,
I have a question related to change 8017298: Better XML support
which went into the last security update. Because it was considered a
security fix, there's not much information available (i.e. no webrev,
no bug description, no discussion on the
On 07/11/2013 14:59, Chris Hegarty wrote:
Given both Michael and Alan's comments. I've update the webrev:
http://cr.openjdk.java.net/~chegar/fileUtils.01/webrev/
1) more descriptive method names
2) deleteXXX methods return if interrupted, leaving the
interrupt status set
3) Use Files.copy
On 08/11/2013 00:39, David Holmes wrote:
And linux? It has changed to vfork right?
So OSX has changed, linux has changed, but Solaris remains as-is. All
platforms allow selecting the mechanism via the property
jdk.lang.Process.launchMechanism
The only change is OSX where the default
On 08/11/2013 03:41, Patrick Zhang wrote:
Sorry, I have some problems to connect to cr.openjdk.java.net yesterday.
Now the webrev and result are attached. Please help to review.
After checking the scripts in java.util, most of scripts have been
finished in 8003890. So the webrev only change 2
On 08/11/2013 09:45, Yuri Gaevsky wrote:
Hi Stuart,
Unfortunately, several Java SE interfaces have public SVUIDs, so the fix can
cause confusion:
I think Stuart's suggestion is good for the case where the class doesn't
have the serialVersionUID already, you just paste it into the source
code
On 06/11/2013 18:44, Xueming Shen wrote:
Hi,
The latest spec and implementation of java.util.Base64.getXXXEncoder()
is to add appropriate padding character(s) at the end of the output
encoded data stream, to follow the note explicitly specified in the
RFC
Implementations MUST include
On 08/11/2013 19:40, Joe Darcy wrote:
Hello,
Please review the simple patch below which addresses a handful of raw
types lint warning in the core reflection implementation code.
(If memory serves, this code dates back from a time during the
development of JDK 5 when wildcards could not be
Changeset: 50df04934e86
Author:alanb
Date: 2013-11-08 21:07 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50df04934e86
8028074: InetAddress.getByName fails with UHE invalid IPv6 address if host
name starts with a-f
Reviewed-by: chegar
!
On 08/11/2013 20:56, roger riggs wrote:
Hi,
Please review this correction to the documentation of the serialized
form of String.
There is no change to the specification or behavior of the
serialization of strings.
It seemed safer to refer to the serialization specification and remove
the
On 08/11/2013 10:13, Patrick Zhang wrote:
Hi Alan,
I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to
hold it.
Thanks, I'll push this for you with this new bug number.
One thing that would be good to do is to go through all the issues in
JDK-8019502 as it doesn't appear
Changeset: 9130770fb6e3
Author:alanb
Date: 2013-11-09 16:46 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9130770fb6e3
8028044: [TEST_BUG] Calendar shell tests do not pass TESTVMOPTS
Reviewed-by: dholmes, alanb
Contributed-by: patrick.zh...@oracle.com
!
Changeset: 2525b91ca5a6
Author:alanb
Date: 2013-11-11 08:36 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2525b91ca5a6
8028099: Many com/sun/management/OperatingSystemMXBean tests failing with CCE
(win)
Reviewed-by: mchung
!
On 06/11/2013 21:54, Robert Stupp wrote:
Hi,
I was wondering why the mostly allocated class in nearly all applications is char[]. A deeper
inspection showed that a lot of these char[] allocations are caused by the code from
java.lang.StringBuilder.toString(), which created a copy of its
On 07/11/2013 00:19, Robert Stupp wrote:
Hi,
the current implementation of java.util.UUID.fromName() and java.util.UUID.toString()
unnecessarily produce a lot of temporary objects. Especially the fromName() method
creates some instances of java.lang.Long and indirectly via name.split() many
On 06/11/2013 21:14, Robert Stupp wrote:
Hi,
I'm trying to build openjdk8 on OSX 10.9 but it fails.
This may be something to bring up on the build-dev list, I think there
was a bit of discussion recently on this list about Xcode 5 and clang.
-Alan.
On 12/11/2013 09:28, Joe Darcy wrote:
Hello,
Please review the patch below which would remove another batch of raw
type javac lint warnings from the core libraries.
No signatures of public or protected methods in the Java SE
specification have been modified. Regression tests in affected
On 12/11/2013 11:01, Patrick Zhang wrote:
Hi Everyone,
I am working on https://bugs.openjdk.java.net/browse/JDK-8016519. The
test uses fixed port(8080) to publish webservice and it will fail
periodically when the port has been occupied by other tests or
applications.
This test is not in
Changeset: 0c414ac10700
Author:alanb
Date: 2013-11-12 17:37 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c414ac10700
8028208: (aio) Assertion in clearPendingIoMap when closing at around time file
lock is acquired immediately (win)
Reviewed-by: chegar
!
On 12/11/2013 18:42, Daniel Fuchs wrote:
Hi,
This is a trivial fix to replace a wrong @bug id
in TestRootLoggerLevel.java:
Looks fine.
-Alan.
Changeset: c4c84b5a3dfa
Author:alanb
Date: 2013-11-13 07:43 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4c84b5a3dfa
8028239: test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh with
NoClassDefFoundError
Reviewed-by: mchung, egahlin
!
On 13/11/2013 14:55, harold seigel wrote:
Hi,
Please review this fix, submitted by Ekaterina Pavlova, to update the
CDS classlist files for JDK 8.
The classlist files were generated using the process described in
jdk/make/tools/sharing/README.txt. In addition, a checksum was included.
On 13/11/2013 04:21, Bill Shannon wrote:
:
There's really no error recovery possible, and certainly no program is
going to attempt error recovery. As I said, there's only two reasonable
things to do: 1) throw up your hands, claim the data is corrupt, and tell
the user there's nothing you can
Changeset: a493871959c2
Author:alanb
Date: 2013-11-13 16:52 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a493871959c2
8028270: Files.readSymbolicLink calls AccessController directly so security
manager can't grant the permission
Reviewed-by: mchung, martin, chegar
!
On 13/11/2013 20:02, huizhe wang wrote:
Hi,
The issue is that the limits applied to each processing process rather
than each file processing. This applies to not only StAX as reported,
but also other parsers and validators. The fix is to add reset to
XMLSecurityManager and call it upon each
If you have a preliminary patch then I would suggest bringing it to
serviceability-dev to discuss it.
-Alan
On 14/11/2013 03:17, Eric Wang wrote:
Hi Everyone,
I'm working on the bug https://bugs.openjdk.java.net/browse/JDK-7067973.
It is a test bug as the test doesn't guarantee memory
Changeset: ecf85f4aecf0
Author:alanb
Date: 2013-11-14 10:40 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecf85f4aecf0
8028343: More ProblemList.txt updates (11/2013)
Reviewed-by: chegar
! test/ProblemList.txt
On 13/11/2013 22:08, huizhe wang wrote:
:
Each parser has its own copy of XMLSecurityManager that maintains the
values of the limits. The parser is reset before it starts to parse a
document. Resetting the values managed by XMLSecurityManager therefore
makes sure that the limits are per
On 13/11/2013 20:28, Xueming Shen wrote:
Yes, the plan is to see what other implementations do.
I think we've run out road on this for JDK 8. Even if we had agreement
on dealing with corrupt input then there is little/no time to get
feedback and do any further adjustments. Technically only
On 14/11/2013 21:37, Mark Sheppard wrote:
Hi,
please oblige and review the following fix
http://cr.openjdk.java.net/~msheppar/8028215/webrev/
which addresses the issue detailed in
https://bugs.openjdk.java.net/browse/JDK-8028215
This addresses an ORB initialization problem, which has
On 14/11/2013 23:27, Bill Shannon wrote:
:
I'd prefer that all variants of the API report the error in a way that allows
the users of the API to ignore the error, access the data that caused the error,
and supply replacement data if desired.
For most of the APIs, decoding as much data as
On 14/11/2013 20:59, Xueming Shen wrote:
:
Here is the webrev for the undo (keep the mime encoder(...) rename
change)
http://cr.openjdk.java.net/~sherman/8028397/webrev
I think is okay except for the restoring of the buffer position when an
error occurs. If we try to keep consistent with
On 14/11/2013 23:56, Stuart Marks wrote:
On 11/14/13 2:04 AM, David Holmes wrote:
Sorry for the delay (been enroute). Only issue I have remains the
subSequence
change - you can't weaken the post-condition of
CharSequence.subSequence without
breaking subtype substitutability.
Hi David,
On 15/11/2013 17:12, Xueming Shen wrote:
I'm happy to put the IAE with advanced positions change back, the
webrev has been updated
according.
http://cr.openjdk.java.net/~sherman/8028397/webrev/
That looks much better.
One case that is still a bit awkward is where there are insufficient
On 15/11/2013 22:48, Mandy Chung wrote:
:
Looks okay. Seems like it worths some refactoring and change
create_impl to take the classname of the default implementation and
move the creation of the default implementation class instance in the
create_impl method.
It used to do that but we
On 18/11/2013 14:59, Jochen Theodorou wrote:
Hi,
java.lang.Class has multiple methods annotated with CallerSensitive
(see
http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/file/tip/src/share/classes/java/lang/Class.java).
Now if we in Groovy here want to build our runtime structure for this
On 19/11/2013 11:48, Weijun Wang wrote:
Is this just changed? jdk8b118 shows 1 and now it's 0.
b118 or your own build? I wonder if you have 6559590 but not the un-do.
-Alan.
On 19/11/2013 10:23, Daniel Fuchs wrote:
Hi,
Please find below a webrev for:
8028185: XMLFormatter.format emits incorrect year
https://bugs.openjdk.java.net/browse/JDK-8028185
The fix is trivial:
http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/
This one is a good reminder as to
On 19/11/2013 12:09, Weijun Wang wrote:
b114: 1
my (previous) own build: 0
I fetched changes for JDK-8028321 (the un-do) and now it's back to 1.
So we are keeping this compatibility even if it does not look correct?
I think it will require careful analysis to see what is possible (as
there
Changeset: 2e574350a2b6
Author:alanb
Date: 2013-11-19 14:08 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e574350a2b6
8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests
Reviewed-by: dholmes, sla, tbell
! test/Makefile
Changeset: 9937f406e27e
Author:alanb
Date: 2013-11-19 14:11 +
URL: http://hg.openjdk.java.net/jdk8/tl/rev/9937f406e27e
8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests
Reviewed-by: dholmes, sla, tbell
! make/jprt.properties
! test/Makefile
The test tools/jar/JarEntryTime.java has been failing intermittently
(but very rarely) for some time. The failure seems to be that the
extracted time it out by more than 10 seconds compared to the original
file time but it isn't always so (esp. when the test runs in a fraction
of a second).
On 19/11/2013 14:28, Rob McKenna wrote:
Hi folks,
Looking for a quick review for a test failure we're encountering.
Seemingly no bar is too high for our test infrastructure. Hopefully
this will put this particular failure to rest.
http://cr.openjdk.java.net/~robm/8022206/webrev.01/
On 19/11/2013 16:46, Rob McKenna wrote:
Hi folks,
Running this test with fastdebug binaries results in a few warning
messages getting lumped into the commandOutput. I've decided to filter
these test wide.
https://bugs.openjdk.java.net/browse/JDK-6703075
On 19/11/2013 19:08, Dan Xu wrote:
Hi All,
We have java/io/pathNames/GeneralWin32.java testcase to do the general
exhaustive test of pathname handling on windows. I am adding a new
test GeneralSolaris.java to test the pathname handling in unix-like
platforms. In the changes, I also make sure
On 19/11/2013 20:14, Martin Buchholz wrote:
In jsr166 tests we have mostly switched to 10 second timeouts to mean
forever.
But in ProcessBuilder tests we are starting up new java processes with
their well-known startup problems, so using a much larger value of
forever seems reasonable. I vote
On 19/11/2013 19:58, Martin Buchholz wrote:
I propose a fix like the diff below, that asks the VM to separate
regular output and JVM output into stdout and stderr, so that we can
do matching on each independently, and so that we can rely on stdout
not being corrupted by JVM output.
Good, it's
On 19/11/2013 23:57, Dan Xu wrote:
Hi All,
Please review the simple fix towards Size.java testcase. It failed
once on windows platform in the recent same binary run, which is
mostly due to some interferences and the special delete handling on
windows.
In the fix, I remove the delete
Changeset: ecd6c25b54ce
Author:alanb
Date: 2013-11-20 21:34 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecd6c25b54ce
8028734: test/java/util/Locale/InternationalBAT.java changes does not restore
the default TimeZone
Reviewed-by: naoto
!
On 21/11/2013 05:20, huizhe wang wrote:
Thanks for working on the issue. The fix looks good.
Looks good to me too (very subtle).
(A side point but should jdk be dropped from the directory name so
that it is a bit more consistent with the tests in the test/javax/xml tree).
-Alan
On 21/11/2013 04:04, Stuart Marks wrote:
OK, I'll remove the String.subSequence change from this changeset and
push it when I get approval.
I've filed this bug:
https://bugs.openjdk.java.net/browse/JDK-8028757
to cover the CharSequence.subSequence issue and potential spec change.
It
On 20/11/2013 18:26, Volker Simonis wrote:
Hi,
this is the second review round for 8024854: Basic changes and files
to build the class library on AIX
https://bugs.openjdk.java.net/browse/JDK-8024854. The previous
reviews can be found at the end of this mail in the references section.
I've
On 21/11/2013 17:02, Dan Xu wrote:
Hi Alan,
I think the map is used to enlarge the size of the largeFile to
testSize + 10. In initTestFile(), it initiates the file with size 10.
My understanding is that it avoids writing large amount of data into
the largeFile by using the map. Thanks!
On 21/11/2013 01:09, Dan Xu wrote:
Hi All,
I have updated my fix based on your suggestions. I have changed to
create testing files in the working directory, moved those static
member variables into local method variables, and used
try-with-resources to read and write the testing files. After
On 21/11/2013 19:29, Dan Xu wrote:
Hi All,
Please review the simple fix towards
test/java/nio/file/Files/Misc.java. It only fails when it is run by
root. As Alan commented in the bug, the root has all permissions, so
the test assumptions are wrong. Thanks!
Bug:
On 22/11/2013 11:02, Charles Oliver Nutter wrote:
Apologies if this is not the correct place to post this, bit i18n
seemed more focused on languages and localization than the mechanics
of transcoding.
I have noticed a behavioral difference in JDK8 decoding a two-byte
Shift-JIS sequence.
On 21/11/2013 15:54, Volker Simonis wrote:
:
But actually I've just realized that it is not need at all, because
'aix_close.c' isn't in the PATH for any other OS than AIX (that could
be probably called a feature of the new file layout:) So I'll simply
change it to:
48 ifeq
On 21/11/2013 10:48, Patrick Zhang wrote:
Hi Alan,
I have renamed jdk8004476 to 8004476. And as Daniel's suggestion,
add some comments to XSLTExFuncTest.java.
I have updated the webrev for review.
http://cr.openjdk.java.net/~pzhang/8027973/webrev/
Thanks for moving it. One thing I notice in
On 25/11/2013 15:43, Paul Benedict wrote:
On 10/16, I wrote:
If you look at the current classes (b111) that have documented
annotations,
the first annotation is correctly left-aligned but all others are indented
by one space. If this is already reported, my apologies; if not, please
confirm.
On 24/11/2013 17:07, Philippe Marschall wrote:
Hi
The following issue was been bothering me for a while:
When you have an annotation with a value that is an array of classes
[1] and one of those classes can't be loaded with the class loader of
defining class of the element the annotation is
On 26/11/2013 13:27, Thomas Stüfe wrote:
:
The real problem is that zlib deflateParams(), unlike zlib deflate(), does
not handle output-buffer-too-small correctly. The workaround is to fully
flush the stream before calling deflateParams(), so that the deflate() call
inside deflateParams()
On 26/11/2013 14:06, Thomas Stüfe wrote:
Hi Alan,
On 26 November 2013 14:55, Alan Bateman alan.bate...@oracle.com
mailto:alan.bate...@oracle.com wrote:
I think you're right but I wonder if this is something that needs
to be brought upstream to the zlib project in order to get
On 25/11/2013 21:51, huizhe wang wrote:
Hi,
This is a patch to fix an error in StAX factories' newFactory(String
factoryId, ClassLoader classLoader). In the 3 step of the
documentation, it should have stated that the specified ClassLoader is
used.
On 26/11/2013 16:23, Volker Simonis wrote:
Hi,
thanks to everybody for the prompt and helpful reviews. Here comes the
final webrev which incorporates all the corrections and suggestions from
the second review round:
http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/
I've successfully
On 26/11/2013 18:38, huizhe wang wrote:
Hi all,
Here's revised webrev, as Alan suggested, including the implementation.
http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/
So is this handling the null case correctly? It is spec'ed to use the
TCCL but it looks like it's going
On 26/11/2013 22:13, huizhe wang wrote:
Ah, I missed that. I took it for granted that since
ServiceLoader.load(service) uses TCCL, load(service, null) would use
TCCL. I've updated the webrev now:
http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/
It looks good now but I'm
On 26/11/2013 23:59, Mandy Chung wrote:
This is a simple patch that adds a new jdeps -jdkinternals option to
make it easier for developers to find dependencies on the JDK internal
APIs:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00/
This looks good (and I can't think of a
On 27/11/2013 08:33, Thomas Stüfe wrote:
I can see arguments for both sides (linking statically vs using the
system zlib) and I'm leaning toward the former. Errors or
incompatibilities in the zlib could be really harmful, and I rather
use the zlib I ran all my tests with instead of the
On 29/11/2013 14:43, Alex Yursha wrote:
Hi everyone, the summary of this issue is that it seems like
java.security.BasicPermission.implies() executes a useless check that
duplicates the functionality provided by java.lang.String.startsWith().
Below is a jdk7 code for
On 29/11/2013 10:08, Daniel Fuchs wrote:
However, removing or just moving the lock around might well introduce new
unknown issues - so it will need to be carefully anaIyzed, and I am
not sure
it can/should be attempted in a minor JDK release.
Yes, we have to be very careful as the logging
On 29/11/2013 14:21, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8025211/webrev/
which address the issue raised in the bug
https://bugs.openjdk.java.net/browse/JDK-8025211
an intermittent failure occurs on some windows test
On 19/11/2013 17:58, Ivan Gerasimov wrote:
Hello all!
Would you please help review a fix for the bug?
https://bugs.openjdk.java.net/browse/JDK-6968459
It was reported that creating new InitialLdapContext() can fail with
javax.naming.NamingException: LDAP response read timed out, timeout
On 01/12/2013 18:29, Nick Williams wrote:
I filed these bugs back in June. I noticed today that they were migrated to the
JIRA instance:
https://bugs.openjdk.java.net/browse/JDK-8016742
https://bugs.openjdk.java.net/browse/JDK-8016743
I filed the bugs, though they say someone else did.
Webbug
On 29/11/2013 20:06, Ivan Gerasimov wrote:
I modified the patch in the way you suggest.
http://cr.openjdk.java.net/~igerasim/6968459/1/webrev/
The timeOut variable now holds the remaining time.
If the system time had changed back, we start counting from the
beginning.
If it had changed
On 02/12/2013 19:25, Xueming Shen wrote:
Hi,
Based on the feedback so far here is the latest webrev, and the link
to the bug.
http://cr.openjdk.java.net/~sherman/8028397/webrev
https://bugs.openjdk.java.net/browse/JDK-8028397
During the discussion it became clearthat methods
On 02/12/2013 21:49, Mandy Chung wrote:
On 11/27/13 4:04 AM, Alan Bateman wrote:
On 26/11/2013 23:59, Mandy Chung wrote:
This is a simple patch that adds a new jdeps -jdkinternals option to
make it easier for developers to find dependencies on the JDK
internal APIs:
http
On 03/12/2013 18:15, Stuart Marks wrote:
Hi all,
Please review this small change to the subSequence() method specs of
CharSequence and String. Essentially this removes the requirement of
returning a new character sequence at each call. This brings the
spec in line with String's
On 04/12/2013 08:24, Jeroen Frijters wrote:
Hi,
I'd like to propose to change Class.checkInitted() to check if the VM
initialization has completed by using sun.misc.VM.isBooted() instead of
System.out != null.
This should be changed (I can only guess that whoever added this wasn't
aware of
On 04/12/2013 10:31, Paul Sandoz wrote:
I have reviewed Doug's code, just need someone to quickly review the test code.
Paul.
Tests looks good, I guess I would use shorter names as the directory
name makes it clear that the tests are for ConcurrentHashMap but that is
a minor point.
-Alan.
On 04/12/2013 14:16, Chris Hegarty wrote:
A trivial one on our JDK8 list. Doug has already accepted this into
the 166 CVS.
Stuart brought this up a while back, and given our short deadline to
get doc changes into jdk8. I'll just go ahead with the review now on
his behalf. I have already
On 04/12/2013 15:44, Seán Coffey wrote:
Recent jdk8 builds seem to be more ambitious on the GC front. It turns
out that we've no strong reference for the Logger being created in
this testcase and it's collected before use.
Thanks Sean, I've seen this fail many times recently due to the logger
On 05/12/2013 14:19, Rob McKenna wrote:
This failure cropped up again and Roger Riggs spotted that I was
looking at it from completely the wrong direction. He contributed the
following fix:
http://cr.openjdk.java.net/~robm/8029525/webrev.01/
This is to avoid a race between:
On 05/12/2013 17:25, Serge wrote:
Hi all,
please review the fix
http://cr.openjdk.java.net/~yan/8028712/webrev.02/
http://cr.openjdk.java.net/%7Eyan/8028712/webrev.02/
for
https://bugs.openjdk.java.net/browse/JDK-8028712
This patch cleanup tidy warnings for generated html documentation, and
1 - 100 of 5195 matches
Mail list logo
