});
ValueHandler vh = Util.createValueHandler();
vh.writeValue(os, a);
}
}
regards
Mark
On 27/06/2014 13:35, Seán Coffey wrote:
Looking for a review around this CORBA issue.
bug report : https://bugs.openjdk.java.net/browse/JDK-7095856
webrev : http://cr.openjdk.java.net/~coffeys/webrev.7095856
The JDK-8036603 fix pushed on Friday broke windows builds. Bad macro
call. Simple fix :
https://bugs.openjdk.java.net/browse/JDK-804
applicable to jdk8u-dev only.
--- a/src/windows/native/java/lang/ProcessEnvironment_md.c
+++ b/src/windows/native/java/lang/ProcessEnvironment_md.c
@@ -41,7
Changes in the ORB loading in 8u5 causes incompatibility changes for
some environments where a 3rd party plugin might be deployed over
plugin. Some CORBA deployment installations have an incorrect
expectation on finding the custom ORBSingleton class using the context
classloader. Proper
That's some nice code reduction Paul. Thanks.
http://cr.openjdk.java.net/~coffeys/webrev.8042906.v3/webrev/
I'll push these changes later unless I hear to the contrary.
regards,
Sean.
On 13/05/2014 11:22, Paul Sandoz wrote:
On May 13, 2014, at 11:34 AM, Seán Coffey sean.cof...@oracle.com
Good tip Alan/Chris.
I'll make that change and push.
Regards,
Sean.
On 12 May 2014 07:17:04 GMT+01:00, Alan Bateman alan.bate...@oracle.com wrote:
On 11/05/2014 21:56, Seán Coffey wrote:
Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can
remove use of reflection in ORB code
Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can
remove use of reflection in ORB code to access the applet context.
bug report : https://bugs.openjdk.java.net/browse/JDK-8042906
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/
regards,
Sean.
This should make the code more robust Alan.
http://cr.openjdk.java.net/~coffeys/webrev.8038491.v3/webrev/
regards,
Sean.
On 09/04/2014 22:16, Alan Bateman wrote:
On 09/04/2014 20:10, Seán Coffey wrote:
I played around with adding some skip testing Alan but didn't see it
increase the rate
into it. I'd like
to backport the below change to 8u, 7u and keep that separate.
regards,
Sean.
-Pavel
On 10 Apr 2014, at 11:35, Seán Coffey sean.cof...@oracle.com wrote:
This should make the code more robust Alan.
http://cr.openjdk.java.net/~coffeys/webrev.8038491.v3/webrev/
regards,
Sean
On re-read, I believe extending the sync block in read(..) to cover the
reading and setting of the rem variable works to resolve this fix. It
should preserve behaviour as well.
http://cr.openjdk.java.net/~coffeys/webrev.8038491.v2/webrev/
regards,
Sean.
On 08/04/14 21:28, Seán Coffey wrote
On 09/04/14 22:16, Alan Bateman wrote:
On 09/04/2014 20:10, Seán Coffey wrote:
I played around with adding some skip testing Alan but didn't see it
increase the rate of failure on an unpatched binary. Since
ZipFileInputStream.read(..) is the trouble method and now has better
synchronized
A recently reported bug shows a race condition is possible on the rem ==
0 check in ZipFile.read(byte b[], int off, int len). A bad check can
result in referencing a jzentry structure that might already be freed
and hence result in a SEGV. The fix is trivial and involves moving the
rem == 0
();
724 }
Am I reading this correctly ?
regards,
Sean.
On 08/04/2014 16:59, Xueming Shen wrote:
Hi Sean,
It might be more explicit to check if (zentry == 0) here?
-Sherman
On 4/8/14 8:21 AM, Seán Coffey wrote:
A recently reported bug shows a race condition is possible on the rem
behaviour / return value)
Regards,
Sean.
-Pavel
On 8 Apr 2014, at 18:29, Seán Coffey sean.cof...@oracle.com wrote:
Sherman,
I see rem == 0 condition becoming true before the zentry variable is set to 0
(in close()) - in a multi threaded scenario like this one, we could have zero
remaining
Chris,
ZipFileInputStream.skip(..) can also close out the stream and free up
the underlying jzentry resources.
Per Sherman's suggestion I substituted rem for jzentry == 0 check but
ran into issues with other tests [1]
Another simple change (and to preserve old behaviour) might be just to
The CORBA build issue continues. I was incorrectly using 7u40 as the
bootstrap JDK. 7u7 is still the version that RE uses and that causes an
issue since sun.misc.JavaAWTAccess wasn't introduced until 7u9.
The fix proposed is short term. There's a discussion underway on
build-dev to bump the
wrote:
I'd suggest holding off a bit until there is a conclusion on the
build-dev list (Folks using 7u7 will need to update anyway, if not
today then maybe very soon).
-Alan
On 03/04/2014 10:43, Seán Coffey wrote:
The CORBA build issue continues. I was incorrectly using 7u40 as the
bootstrap
Looks good to me Aleksej.
regards,
Sean.
On 03/04/2014 13:13, Aleksej Efimov wrote:
Hello,
Can I have a review [1] for a problem [2] in CORBA connections pool
implementation: There is a reclamation possibility of newly created
connections. The root cause of such behavior is that newly
I'm looking to port this fix from JDK 8 to 9. Other changes were made
for JDK 9 given that we have access to the
javaAwtAccess.getAppletContext() method when using JDK 8 as the boot
strap JDK for CORBA. Direct access to the sun.awt.AppContect class has
been removed.
bug :
Looks fine to me.
regards,
Sean.
On 02/04/14 11:55, Aleksej Efimov wrote:
Hello,
Can I have a review for the latest (2014b) TZ data integration to
JDK9. The webrev can be located here [1].
The following set of tests were executed without failures:
test/sun/util/calendar
On 02/04/14 15:05, Alan Bateman wrote:
On 02/04/2014 11:42, Seán Coffey wrote:
I'm looking to port this fix from JDK 8 to 9. Other changes were made
for JDK 9 given that we have access to the
javaAwtAccess.getAppletContext() method when using JDK 8 as the boot
strap JDK for CORBA. Direct
Looks good to me.
regards,
Sean.
On 12/03/2014 15:05, Aleksej Efimov wrote:
Hello,
Can I have a review for a tzdata2014a [1] integration to JDK9:
http://cr.openjdk.java.net/~aefimov/8037012/9/webrev.00
The following test sets were executed on the build with latest tzdata:
Looks good Aleksej. A future rule change doesn't necessarily mean a new
GMT offset change. Original test logic seemed buggy.
regards,
Sean.
On 12/03/2014 15:06, Aleksej Efimov wrote:
Hello,
Can I have a review for a 'test/sun/util/calendar/zi/Zoneinfo.java'
test bug failure [1] related to
On 27/02/2014 07:45, Alan Bateman wrote:
On 26/02/2014 21:47, Seán Coffey wrote:
Good points Alan. Changes uploaded here :
http://cr.openjdk.java.net/~coffeys/webrev.8035618.v2/webrev/
This looks much better. Are you sure that pmLock is needed? Is there
any reason not to synchronize
Looking to push a fix to JDK 8. A CORBA issue was discovered during
TCK-Plugin testing. The NPE seen should be handled and the
defaultPresentationManager should be returned where necessary.
Bug ID : https://bugs.openjdk.java.net/browse/JDK-8035618
webrev :
Good points Alan. Changes uploaded here :
http://cr.openjdk.java.net/~coffeys/webrev.8035618.v2/webrev/
regards,
Sean.
On 26/02/14 18:54, Alan Bateman wrote:
On 26/02/2014 16:50, Seán Coffey wrote:
Looking to push a fix to JDK 8. A CORBA issue was discovered during
TCK-Plugin testing. The NPE
Approved for pushing to jdk8u-dev.
regards,
Sean.
On 14/02/14 01:38, Phil Race wrote:
Yeah sorry about that. It built on Windows and Mac but not Linux as i
found out today.
-phil.
On 2/13/14 5:36 PM, Mandy Chung wrote:
Looks good. Sorry I didn't catch this earlier and I was counting on
Looks fine to me Rob.
regards,
Sean.
On 07/02/14 18:44, Rob McKenna wrote:
Hi folks,
When files are copied by our test harness the permissions are left
unchanged. This can cause trouble for a few tests when the test folder
is read only.
http://cr.openjdk.java.net/~robm/7152892/webrev.01/
Looking to correct some JNI handling code in java/util/zip for jdk9-dev.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8029020/webrev/
http://cr.openjdk.java.net/%7Ecoffeys/webrev.8029020/webrev/
regards,
Sean.
thanks for reviews. webrev updated :
http://cr.openjdk.java.net/~coffeys/webrev.8029020.v2/webrev/
I'll push pending positive build test results.
regards,
Sean.
On 04/02/14 13:51, Alan Bateman wrote:
On 04/02/2014 13:31, Seán Coffey wrote:
Looking to correct some JNI handling code in java
Looks good to me Aleksej. Hopefully you can get a reviewer from the i18n
dev team also.
regards,
Sean.
On 21/01/14 13:17, Aleksej Efimov wrote:
Hi,
Can I have a review for 2013i timezone data integration [1] to JDK9.
There is one change in tzdb that affects naming for Asia/Amman
timezone:
Some simple copyright year updates which should have been done during
the year when these corba files were touched. I hope to push to JDK 8
and then import the patch into JDK 9.
https://bugs.openjdk.java.net/browse/JDK-8029231
http://cr.openjdk.java.net/~coffeys/webrev.8029231/webrev/
I've created https://bugs.openjdk.java.net/browse/JDK-8029595 to track
some clean up in this area.
regards,
Sean.
On 04/12/2013 16:44, Mandy Chung wrote:
On 12/4/2013 7:51 AM, Alan Bateman wrote:
On 04/12/2013 15:44, Seán Coffey wrote:
Recent jdk8 builds seem to be more ambitious on the GC
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.
Verified that test now passes.
suggested fix :
diff -r 28ca338366ff
Sherman can answer this best. The 8008386 fix for 8 differs from earlier
updates since alot of the code was rewritten in this area. The initial
report was identified as a regression in JDK6. Back in 2005, the 6227339
fix changed behaviour which meant that invalid single byte characters
were
Looking to add two helper methods to the OpenJDK test libraries. I'm
looking to clean up a closed src test case but these methods should be
of use for future testcase development.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8028583/webrev/
bug report :
.
On 11/19/2013 01:31 PM, Seán Coffey wrote:
Looking to add two helper methods to the OpenJDK test libraries. I'm
looking to clean up a closed src test case but these methods should be
of use for future testcase development.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8028583/webrev/
bug
Hope this is a simple one. This issue is a rare intermittent one :
- port 48250 is free
- exported registry: RegistryImpl[UnicastServerRef [liveRef:
[endpoint:[10.169.79.100:48250](local),objID:[0:0:0, 0
- port 48250 is in use
- unexported registry
java.net.BindException: Address already
Looks good to me too Aleksej.
regards,
Sean.
On 08/11/2013 16:42, Xueming Shen wrote:
looks fine. I would assume you've also run the corresponding tests at
test/closed repo.
-Sherman
On 11/5/2013 8:38 AM, Aleksej Efimov wrote:
Hi,
Can I have a review for tzdata2013h integration [1]. The
Looks good here too Aleksej.. in case you need a second reviewer.
regards,
Sean.
On 06/11/2013 17:18, Xueming Shen wrote:
Looks fine.
thanks!
-Sherman
On 11/05/2013 03:21 PM, Aleksej Efimov wrote:
Sherman,
Thank you for a quick review. I totally agree with you on all items.
Actually, I
that knows how to run idlj and compile classes against
the generated output. Oh well.
s'marks
On 10/22/13 12:44 PM, Seán Coffey wrote:
This corba fix was fixed many moons ago in JDK5. Bad records meant it
didn't get
forward ported to JDK6 and later families. We need to fix that now.
I'm looking
Hi,
this is a test stabilization fix for jdk8-tl. It turns out that the
wsimport tool sets java.net.useSystemProxies to true. This can cause
connection issues to localhost for some windows environments depending
on proxy configuration. Best solution here is to disable the
systemProxies since
This corba fix was fixed many moons ago in JDK5. Bad records meant it
didn't get forward ported to JDK6 and later families. We need to fix
that now. I'm looking to push this to jdk8-tl and backport to jdk7u-dev
shortly afterwards.
bug ID : https://bugs.openjdk.java.net/browse/JDK-5036554
Looks good to me too Alan. Thanks for taking care of this. After
studying the class delegation code, it's now making sense to me why the
initial package restriction failed.
regards,
Sean.
On 21/10/13 13:45, Chris Hegarty wrote:
Very nice Alan.
I have reviewed all the changes, and am happy
Looks fine to me Dan but I'm not a official reviewer.
regards,
Sean.
On 08/10/2013 19:24, Dan Xu wrote:
Hi,
This is a backport request towards 7u-dev repository on bug
JDK-8025128 that I fixed several days ago. It is going to keep the
method, File.createTempFile(), backward compatible.
Yes - no problem pushing the changeset for Dan once the approval request
is logged and approved.
regards,
Sean.
On 08/10/2013 20:43, Alan Bateman wrote:
On 08/10/2013 19:24, Dan Xu wrote:
Hi,
This is a backport request towards 7u-dev repository on bug
JDK-8025128 that I fixed several days
Miran,
I'm assuming that all these changes were reviewed when integrated to the
upstream JAX-WS project. I confirm that my changes from 8016271 are
present and look fine. I'm not an OpenJDK reviewer though so you'll need
someone else as reviewer.
regards,
Sean.
On 26/09/2013 17:14,
On 01/10/2013 10:29, Chris Hegarty wrote:
On 10/01/2013 10:09 AM, Seán Coffey wrote:
Miran,
I'm assuming that all these changes were reviewed when integrated to the
upstream JAX-WS project. I confirm that my changes from 8016271 are
present and look fine. I'm not an OpenJDK reviewer though so
Bug report not public at moment. (should appear shortly)
Issue with wsimport tool. Use of jar files created from wsimport on
windows don't work on unix systems. Portability issue.
Simple fix. wsimport testcase to accompany it.
http://cr.openjdk.java.net/~coffeys/webrev.8016271/
regards,
, Miroslav Kos wrote:
Hi Alan,
good catch! Yes, we need to apply the fix on our side too, otherwise
it would be reverted with a new integration JAX-WS JDK.
Miran
On 09/03/2013 12:03 PM, Alan Bateman wrote:
On 03/09/2013 10:49, Seán Coffey wrote:
Bug report not public at moment. (should appear
Sockets created by the
com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory can be
affected by firewalls if that connection is left idle for long periods
of time. (closed out). A workaround for such an issue could be to have a
simple corba thread send some simple ping traffic on
codebasis. We definitely prefer the first
option.
Miran
On 09/03/2013 12:18 PM, Seán Coffey wrote:
Miran,
can you clarify how we get this fix in then. Will you patch into
JAX-WS and port to the jdk/jaxws repo or do can we push it to both
repos independently? How often does JAX-WS team sync
suggest making keepAlive final and always setting it
in the static initializer.
Otherwise, looks fine to me.
-Chris.
On 09/03/2013 01:04 PM, Seán Coffey wrote:
Sockets created by the
com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory
can be
affected by firewalls if that connection
the system property looks a little odd. But I
will admit views differ on exactly what values should be accepted.
So, trivially I would suggest making keepAlive final and always
setting it in the static initializer.
Otherwise, looks fine to me.
-Chris.
On 09/03/2013 01:04 PM, Seán Coffey wrote
Performance regression reported where a high number of threads calling
TimeZone.getDefault can run into a bottleneck on AppContext accessor
calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet.
Turns out that we're unnecessarily going through the AppContext in
certain
On 02/09/13 19:15, Chris Hegarty wrote:
On 09/02/2013 07:06 PM, Seán Coffey wrote:
This might be a slightly easier one to read. (fast path logic code
first)
http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/
The 'javaAWTAccess != null ' checks are redundant. It will always
Chris -
you're right on the redundant checks. Had to re-read it! Will get those
removed. Thanks.
regards,
Sean.
On 02/09/13 19:15, Chris Hegarty wrote:
On 09/02/2013 07:06 PM, Seán Coffey wrote:
This might be a slightly easier one to read. (fast path logic code
first)
http
Some minor modification (and further simplifying of conditions) :
http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/
regards,
Sean.
On 02/09/13 21:07, Alan Bateman wrote:
On 02/09/2013 19:06, Seán Coffey wrote:
This might be a slightly easier one to read. (fast path logic code
Looks fine to me also Sherman. On a side note, we should look at
migrating some closed TZ tests to open repo. I'm not sure why that
wasn't done from first day.
regards,
Sean.
On 09/08/2013 08:20, Yuka Kamiya wrote:
Hi Sherman,
The fix looks good to me.
Thanks,
--
Yuka
(2013/08/09 14:54),
On the regression testcase theme, it got me thinking as to whether we've
any java APIs which can query what the native heap usage of the JVM. Is
that available over JMX ?
I tried the MBeanServer approach but didn't get the expected results.
Queried the NonHeapMemoryUsage object.
something
Looks good from me also. I think these files were leftovers from some
old development projects. Good to clean up.
regards,
Sean.
On 31/07/13 13:15, Aleksej Efimov wrote:
Hi,
There are unused .sjava files in corba repository which can be deleted.
The webrev:
(SocketOrChannelAcceptorImpl.java:361)
at
com.sun.corba.se.impl.transport.CorbaTransportManagerImpl.addToIORTemplate(CorbaTransportManagerImpl.java:238)
On 24/07/13 02:01, Alan Bateman wrote:
On 15/07/2013 01:14, Seán Coffey wrote:
Mandy,
Looks fine to me. I agree that we should back it out
9:14 PM, Seán Coffey wrote:
The recent 8000450 has caused issue for JCK testing and some RMI/JMX
testing also.The CORBA package interaction between org.omg,
com.sun.corba.se.spi, javax.rmi and other packages into
com.sun.corba.se.impl classes needs better analysis and won't be
complete for 7u40
The recent 8000450 has caused issue for JCK testing and some RMI/JMX
testing also.The CORBA package interaction between org.omg,
com.sun.corba.se.spi, javax.rmi and other packages into
com.sun.corba.se.impl classes needs better analysis and won't be
complete for 7u40.
It's rare to have
Gerasimov wrote:
Please have a chance to review an updated webrev.
It now includes a change to ProblemList.txt, so both modified tests
are ignored for linux-x64.
Sincerely yours,
Ivan Gersimov
On 08.07.2013 21:27, Seán Coffey wrote:
On 08/07/13 17:55, Ivan Gerasimov wrote:
Thanks, Seán!
I
.
Sincerely yours,
Ivan
On 10.07.2013 13:15, Seán Coffey wrote:
Ivan,
I'll assume this is the latest webrev :
http://cr.openjdk.java.net/~igerasim/8016838/3/webrev/
http://cr.openjdk.java.net/%7Eigerasim/8016838/3/webrev/
One comment - should the test be excluded for all linux variants
(i.e
I'd like to move this testcase from our internal test repo and replace
the current test/java/lang/SecurityManager/CheckPackageAccess.java
testcase . It's a straightforward test to ensure that the package
restrictions enforced via the java.security file are those expected.
The testcase should
ProblemList when the
jdk8 regression is fixed.
regards,
Sean.
Sincerely yours,
Ivan
On 05.07.2013 15:45, Seán Coffey wrote:
Nice work indeed Ivan. Good to have a reliable testcase to catch
leaks in this area.
I'd also suggest that this test goes on the ProblemList until the new
leak is sorted
Nice work indeed Ivan. Good to have a reliable testcase to catch leaks
in this area.
I'd also suggest that this test goes on the ProblemList until the new
leak is sorted out for jdk8. The goal of JPRT runs is to have clean
runs. If it's on the problemList, then it's a known issue and is
You should be able to do it with scripts. Mandy designed something
similar recently :
http://opengrok.ie.oracle.com:8080/opengrok/xref/jdk7u-cpu/jdk/test/closed/java/util/logging/SystemLoggerTest.sh
In the recent infrastructure meeting, scripts for tests were frowned
upon. I don't see any
Brent,
do you need to remove the sun/misc/Hashing.java reference from the
make/java/java/FILES_java.gmk file? I suspect it could break builds for
people still using the old build system on jdk8.
regards,
Sean.
On 12/06/13 17:30, Brent Christian wrote:
Thanks for the reviews, everyone. I
Thanks for taking care of that Alan. Those changes look fine to me. Hope
the testing works out ok.
regards,
Sean.
On 10/06/13 12:11, Alan Bateman wrote:
The warnings from the build of the corba repository on missing
hashCode methods have been annoying me for some time. I was hoping
they
On 05/06/2013 07:20, Alan Bateman wrote:
On 04/06/2013 23:57, Seán Coffey wrote:
The com.sun.corba.se.impl package is a private package. The API is
subject to change at any time and no 3rd party code should be using
it. As a result, I'd like to add it to the package restricted list.
I've run
The com.sun.corba.se.impl package is a private package. The API is
subject to change at any time and no 3rd party code should be using it.
As a result, I'd like to add it to the package restricted list. I've run
our internal CORBA SQE testsuite against the proposed change and didn't
see any
Thanks for taking care of this Sherman. I was wondering what sort of
impact JSR 310 would make on tzdata updates. The Atlantic/Stanley
display name issue mentioned is a regular one, we should log a bug
against the test file generation scripts.
I just had a quick grok of the jdk8 repo. The
);
System.setSecurityManager(new SecurityManager());
On 28/11/2012 12:59, Staffan Larsen wrote:
Did we conclude that my original change was good, or was there an alternative?
Thanks,
/Staffan
On 27 nov 2012, at 17:02, Seán Coffey sean.cof...@oracle.com wrote:
I suspect this test
I suspect this test will fail with java agents too, say when doing
code coverage during test runs.
It might be better to just change the @run tag to specify -D
user.timezone= Asia/Tokyo, assuming this solves the problem too.
This test runs in othervm mode by default. Any java agents calling
Approved for jdk7u-dev.
regards,
Sean.
On 18/10/2012 13:34, Kurchi Hazra wrote:
This is a request for approval to backport the fix for 7198073 from 8
to 7u12.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198073
Webrev: http://cr.openjdk.java.net/~khazra/7198073/7u12/webrev/
steve.si...@oracle.com has contributed the following patch which I'd
like to push to jdk8 TL. It's the correction of copyright years in corba
repo.
Need a reviewer.
webrev :
http://cr.openjdk.java.net/~coffeys/webrev.7196086.jdk8/
http://cr.openjdk.java.net/%7Ecoffeys/webrev.7196086.jdk8/
bug report should be live shortly :
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195063
The introduction of a new corba testcase in recent past is showing up as
a random failure on our internal build/test harness (JPRT).
===
-
Approved.
regards,
Sean.
On 28/08/2012 01:32, Kurchi Hazra wrote:
This is a request for approval to backport the fix for 7184287 rom 8
to 7u8.
Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184287
Webrev:http://cr.openjdk.java.net/~khazra/7184287/7u8/webrev.00/
This had been
I'm looking to forward port this corba fix from 6u34 to jdk8 (and
eventually port to 7u)
d.macdon...@auckland.ac.nz originally reported this issue and I'll be
marking the fix as contributed by him. He's already signed the OCA.
There's a good description in bug report. We have a race like
7183209 : Backout 7105952 changes for jdk7u
Regards,
Sean.
On 11/07/12 11:43, Alan Bateman wrote:
On 10/07/2012 17:37, Seán Coffey wrote:
7105952 fix introduced some improvements for finalization strategy
around FileInputStream/FileOutputStream/RandomAccessFile.
However a recently reported
7105952 fix introduced some improvements for finalization strategy
around FileInputStream/FileOutputStream/RandomAccessFile.
However a recently reported issue has highlighted an issue where memory
heap can be consumed with SocketOutputStream objects as a result of
clients repeatedly calling
the test in its
current state.
-Chris.
On 10/07/2012 17:37, Seán Coffey wrote:
7105952 fix introduced some improvements for finalization strategy
around FileInputStream/FileOutputStream/RandomAccessFile.
However a recently reported issue has highlighted an issue where memory
heap can be consumed
This is a copyright patch that misha.by...@oracle.com has asked to
contribute. I'm pushing it to jdk8 for him.
corba repo found to be lacking headers on 2 files.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161925
http://cr.openjdk.java.net/~coffeys/webrev.7161925.jdk8/
regards,
Sean.
This is a copyright patch that misha.by...@oracle.com has asked to
contribute. I'm pushing it to jdk8 for him.
corba repo found to be lacking headers on 2 files.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161925
http://cr.openjdk.java.net/~coffeys/webrev.7161925.jdk8/
regards,
Sean.
15:11, Seán Coffey wrote:
Yes - good catch. I hadn't tested the sym link being a relative
path. We should always open whatever is pointed to from
DEFAULT_ZONEINFO_FILE. This simplifies the code. Tested and looks good.
I assume this is the latest:
http://cr.openjdk.java.net/~coffeys/webrev
://cr.openjdk.java.net/~coffeys/webrev.7148584.jdk8.2/
regards,
Sean.
On 09/03/2012 16:18, Alan Bateman wrote:
On 09/03/2012 15:52, Seán Coffey wrote:
Issue seen when the inner Manifest.FastInputStream.peek() method is
called just as we hit EOF of main buffer being parsed (the manifest
input file
Ok - good point on the stat change Alan. I think this is what you're after :
http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.2/
regards,
Sean.
On 12/03/12 11:04, Alan Bateman wrote:
On 09/03/2012 16:00, Seán Coffey wrote:
Issue seen on somewhat irregular linux system configuration
Yes - good catch. I hadn't tested the sym link being a relative path. We
should always open whatever is pointed to from DEFAULT_ZONEINFO_FILE.
This simplifies the code. Tested and looks good.
regards,
Sean.
On 12/03/12 14:34, Alan Bateman wrote:
On 12/03/2012 14:31, Seán Coffey wrote:
Ok
Issue seen on somewhat irregular linux system configuration where
/etc/localtime is a symbolic link to a directory outside of /usr/share/zoneinfo.
In past, when a symbolic link was seen, the end target file was assumed to be
under /usr/share/zoneinfo and a string comparison match was
Alan,
as discussed, this is the proposed backport of 7105952 to jdk7u6. It's
baked in Jdk 8 for some time now without issue. The patch is slightly
different given that the JDK 7 repo had CR 7101658 to backout the round
1 fix.
Resulting code should be identical though. I thought I'd create a
Can do Kumar. Should get these in before the week is out.
regards,
Sean.
On 29/02/12 16:16, Kumar Srinivasan wrote:
Hi,
Please review fix for launcher tests, the JVM requires a higher
stack size for 64bit systems, this fixes increases the stack size
and removes the test from the problem
ok,
I've updated the changes (and bug synopsis) based on comments.
equals method tweaked for :
Collections.SynchronizedList
Collections.SynchronizedSet
Collections.SynchronizedMap
Collections.UnmodifiableEntry
Testcase updated also. JCK java_util tests run also.
Bug recently reported. We enter infinite recursion on a boundary case
for Collections.synchronizedList.remove(..)
Fix is a simple equals check in class method before delegating the call.
bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144488
webrev :
I've worked with Masayoshi on this issue. Hoping to push to JDK8 and
backport to 7u and a jdk6 once baked for a while.
Some windows boxes were showing performance issues when attempting to
iterate through all available timezones available in the JRE. Changes
made here should reduce the amount
Valerie,
I'm porting this fix to the JDK 7u repo. It's been fixed in JDK 6 JDK
8 repos already.
full builds have been made with no issues seen.
Bug report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7058133
webrev : http://cr.openjdk.java.net/~coffeys/webrev.7058133.jdk7u/
The fix
currently not live on bugs.sun.com but hope to get it up there shortly :
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7091388
I'm porting fix for 7091388 forward to JDK8 (and then 7u)
This is a fix in the CDRInputStream_1_0.close()/
CDROutputStream_1_0.close() methods where shared
added to FileDescriptor to help read code
I'll leave the javadoc changes for another bugID/CCC request.
regards,
Sean.
On 02/11/11 06:35, Alan Bateman wrote:
On 01/11/2011 09:47, Seán Coffey wrote:
:
Are you referring to the parent.close() call ? If otherParents is
null, then we only have one
On 30/10/2011 16:33, Alan Bateman wrote:
On 28/10/2011 19:13, Seán Coffey wrote:
This is a second stab at cleaning up the close() and finalize()
methods for FileInputStream / FileOutputStream / RandomAccessFile
classes so that all parents/referents sharing the same native
FileDescriptor
201 - 300 of 310 matches
Mail list logo
