On Fri, 21 Jan 2022 17:07:37 GMT, Mark Sheppard wrote:
>> Good point. I think its better to deal with the casts at the edges since the
>> timeout handling will use long by default.
>
> yes a redeclaration of timeout with a type long across the component would
> be
On Fri, 21 Jan 2022 13:02:36 GMT, Rob McKenna wrote:
>> Well I guess the request was "why not use long everywhere to avoid casting
>> to int" ;-)
>> But I'm happy with either too - as long as the place where you have a long
>> (e.g obtained by substracting two nano times) and call a method that
On Tue, 14 Dec 2021 15:26:54 GMT, Rob McKenna wrote:
>> This fix attemps to resolve an issue where threads can stack up on each
>> other while waiting to get a connection from the ldap pool to an unreachable
>> server. It does this by having each thread start a countdown prior to
>> holding th
On Tue, 14 Dec 2021 15:26:54 GMT, Rob McKenna wrote:
>> This fix attemps to resolve an issue where threads can stack up on each
>> other while waiting to get a connection from the ldap pool to an unreachable
>> server. It does this by having each thread start a countdown prior to
>> holding th
On Wed, 1 Dec 2021 18:33:44 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review this patch to address a failure at DST->STD offset transition.
> The fix mirrors what was done for JDK-8190748
>
>
> Best,
> Lance
Marked as reviewed by msheppar (Reviewer).
-
PR: https://git.op
On Tue, 2 Nov 2021 18:17:36 GMT, Pavel Rappo wrote:
>> It's tough when a natural language clashes with a programming language. I
>> appreciate that this particular clash might cause discomfort to native
>> English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for
>> adjective order.)
On Fri, 29 Oct 2021 10:38:41 GMT, Ivan Šipka wrote:
>> cc @ctornqvi
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> removed file added by accident
Marked as reviewed by msheppar (Reviewer).
-
PR: https://git.op
On Fri, 29 Oct 2021 10:38:41 GMT, Ivan Šipka wrote:
>> cc @ctornqvi
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> removed file added by accident
bugid in title should be 8275650: i.e. the bugid for problemlist update
---
On Thu, 28 Oct 2021 15:30:49 GMT, Ivan Šipka wrote:
>> cc @ctornqvi
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> changing os id
as per comment from Igor above, the bug id in the problemlist is incorrect, and
it should be
On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov wrote:
> > So Suggestion is refector remove Configuration to simplify the interface
> > and provide the BULITIN_RESOLVER and hostname as parameters to the
> > InetAddressResolverProvider::get method
>
> During work on this JEP we've examined the
On Sun, 17 Oct 2021 16:33:57 GMT, Aleksei Efimov wrote:
> > What’s in a name? I find the method names of the InetAddressResolver
> > interface a bit ambiguous. Typically in this DNS problem space one speaks
> > of lookup to resolve a hostname to its associated addresses and reverse
> > lookup
On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov wrote:
>> This change implements a new service provider interface for host name and
>> address resolution, so that java.net.InetAddress API can make use of
>> resolvers other than the platform's built-in resolver.
>>
>> The following API classes
On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov wrote:
>> This change implements a new service provider interface for host name and
>> address resolution, so that java.net.InetAddress API can make use of
>> resolvers other than the platform's built-in resolver.
>>
>> The following API classes
On Fri, 3 Sep 2021 20:32:20 GMT, Mark Sheppard wrote:
> A number of nio DatagramChannel tests are intermittently failing on
> macosx-aarch64.
> In some instances this is a receive call blocking indefinitely waiting on
> data which has
> already been sent, and should be available
ecute in othervm mode.
>
> Additionally, to assist in the buffer allocation issue, the netstat command
> executed by the test
> failure_handler has an extra argument added to obtain additional details on
> mbuf usage.
> The failure handler will now execute with netstat -mm
Mark She
On Sat, 4 Sep 2021 06:47:43 GMT, Alan Bateman wrote:
>> A number of nio DatagramChannel tests are intermittently failing on
>> macosx-aarch64.
>> In some instances this is a receive call blocking indefinitely waiting on
>> data which has
>> already been sent, and should be available immediately
A number of nio DatagramChannel tests are intermittently failing on
macosx-aarch64.
In some instances this is a receive call blocking indefinitely waiting on data
which has
already been sent, and should be available immediately to the receive method
call.
Other test failure scenarios are problem
On Mon, 22 Mar 2021 10:35:03 GMT, Mahendra Chhipa
wrote:
> https://bugs.openjdk.java.net/browse/JDK-8064681
the tests set a system property and then clear that system property at the end
of the test. Is it always the case that the property being set in the test
does not have a value prior to
On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty
wrote:
> ProblemList two java/rmi/Naming tests on Windows in order to reduce the
> noise in the JDK16 CI. This is a trivial fix.
LGTM
-
Marked as reviewed by msheppar (Reviewer).
PR: https://git.openjdk.java.net/jdk16/pull/58
Hi Joe,
all good I think. 👍
regards
Mark
From: Joe Wang
Sent: Monday 18 May 2020 19:36
To: mark sheppard ; core-libs-dev@openjdk.java.net
Cc: Mark Sheppard
Subject: Re: RFR [15] 8244342: Compilation warnings about unexpected
serialization related method
Hi Joe,
do your changes warrant a java doc change for readObject
in each LocPathIterator PredicatedNodeTest, and UnionPathIterator ?
regards
Mark
From: core-libs-dev on behalf of Joe
Wang
Sent: Friday 15 May 2020 17:54
To: core-libs-dev@openjdk.java.net
Sub
thanks Chris
regards
Mark
On 16/06/2017 18:20, Chris Hegarty wrote:
On 16 Jun 2017, at 17:31, Mark Sheppard wrote:
Hi,
please oblige and review the javadoc changes:
http://cr.openjdk.java.net/~msheppar/8181836/webrev/
Looks good Mark.
-Chris.
Hi,
please oblige and review the javadoc changes:
http://cr.openjdk.java.net/~msheppar/8181836/webrev/
to rectify broken javadoc links, as outlined in
https://bugs.openjdk.java.net/browse/JDK-8181836
regards
Mark
hould
{@extLink jidlexception Java IDL exceptions }
be the same as others:
{@extLink jidlexception documentation on Java IDL exceptions}
I'm not sure if the is really needed. I'd remove it if not
necessary.
Otherwise looks fine.
Roger
On 5/31/2017 12:43 PM, Mark Shep
Hi,
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8176784-IV/webrev.02/
which address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8176784
this results in changes to href in the corba javadoc, such that the
relative links to technote/guid
Hi Rob,
updated change looks good and does the job (in jdk8 and jdk9) of
eliminating the socket connection build up
regressions tests show no side effects.
noticed what appears to be a peculiarity in the test, in that the test's
server object is exported on the same port as the
Registry! B
thanks for the feedback Alan, Joe, Lance
I'll look into the I18N runtime copy strategy ... might go with the
expeditious manual test option for this one
regards
Mark
On 24/02/2017 10:28, Alan Bateman wrote:
On 24/02/2017 00:00, Mark Sheppard wrote:
Hi,
please oblige and revie
Hi,
please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/8175177/webrev/
for the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8175177
the test now explicitly removes the orb.properties file created by the test.
regards
Mark
oki doki ... np ... amendments have been made ... verification testing
in progress
regards
Mark
On 15/02/2017 18:57, Stuart Marks wrote:
On 2/15/17 9:18 AM, Mandy Chung wrote:
On Feb 15, 2017, at 6:21 AM, Mark Sheppard
wrote:
please oblige and review the following change:
http
, Mark Sheppard wrote:
Hi
please oblige and review the following change:
http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/
to address the issue:
https://bugs.openjdk.java.net/browse/JDK-8146299
which is to disables a currently undocumented, and unsupported
feature in rmic
* the parsing
thanks Chris
On 15/02/2017 15:05, Chris Hegarty wrote:
On 15 Feb 2017, at 14:21, Mark Sheppard wrote:
Hi
please oblige and review the following change:
http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/
This looks good to me Mark.
-Chris.
to address the issue:
https
Hi
please oblige and review the following change:
http://cr.openjdk.java.net/~msheppar/8146299-II/webrev.03/
to address the issue:
https://bugs.openjdk.java.net/browse/JDK-8146299
which is to disables a currently undocumented, and unsupported feature
in rmic
* the parsing of the commandline
webrev has been updated as per feedback and suggestions:
http://cr.openjdk.java.net/~msheppar/8049375/test/webrev.02/
http://cr.openjdk.java.net/~msheppar/8049375/corba/webrev.02/
regards
Mark
On 07/02/2017 12:12, Mark Sheppard wrote:
thanks Lance for the feedback
TODO auto-generated in
sider removing the
“TODO” comments from your test cases prior to pushing.
Maybe it is not needed, but should the test also be run with a
SecurityManager or did you feel that was not needed?
HTH
Best
Lance
On Feb 6, 2017, at 4:20 PM, Mark Sheppard <mailto:mark.shepp...@oracle.com>> wrote:
thanks Alan yes, good spot, I lost the L114 change somewhere
between the CCC and my development environment!
I'll add that in
regards
Mark
On 07/02/2017 07:04, Alan Bateman wrote:
On 06/02/2017 21:20, Mark Sheppard wrote:
Hi,
please oblige and review the following changes t
Hi,
please oblige and review the following changes to the corba component
http://cr.openjdk.java.net/~msheppar/8049375/corba/webrev/
http://cr.openjdk.java.net/~msheppar/8049375/test/webrev/
which address the issue
https://bugs.openjdk.java.net/browse/JDK-8049375
the JDK9 rt image has chang
Hi Hamlin,
If I read the changes correctly, there would appear to be a side effect
of your refactor extract method "run", such that the static member variable
registry is no longer set in the main method, and is set in the run
method ? Thus, invoking run multiple times (, whether that is intend
Hi Chris,
change looks good to me.
just to clarify, the ClassNotFoundException in this instance is due to
the migration of
sun.misc.GC to sun.rmi.transport.GC.
from a more general scope,
the change to the latter is to relieve JreMemoryLeakPreventionListener
of the need to
perform reflective
() runs into an exception.
Regards,
Sean.
On 01/07/16 00:38, Mark Sheppard wrote:
Hi,
please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/8160240/webrev/
to address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8160240
it has been observed that, duri
That failing, maybe you can use a try/finally block in main method to
ensure that stopTestComponents() is always called. Looks like there's
potential for the test to exit early without cleaning up if
startRmiIiopServer() runs into an exception.
Regards,
Sean.
On 01/07/16 00:38, Mark Sheppard
Hi,
please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/8160240/webrev/
to address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8160240
it has been observed that, during continuous integration regression
tests on some platforms,
there is an inter
Hi Christoph,
thanks for the response ... yes, you do check the
getLastErrorString return ... sorry about that!
regards
Mark
On 27/06/2016 14:28, Langer, Christoph wrote:
Hi Mark,
thanks for looking at this. Please see my comments inline.
wrt JNU_ThrowByNameWithMessaheAndLastErro
Hi,
wrt JNU_ThrowByNameWithMessaheAndLastError, it would appear that it
doesn't allow for malloc to fail and hence
str1 could be null and a problematic input to jio_snprintf which could
result in a de-referencing of zero.
in the call flow would it not be more appropriate to manipulate nat
OK grand so, will make that change ... thanks Chris
regards
Mark
On 16/06/2016 06:40, Chris Hegarty wrote:
On 15 Jun 2016, at 19:33, Mark Sheppard wrote:
Hi,
please oblige and review the updated webrev:
http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev.01/
I’m happy with the code
probably works for you.
In RmiIiopReturnValueTest, there are a few unused imports,
DataInputStream, File, TimeUnit, CountDownLatch that could be removed.
Thanks, Roger
On 6/15/2016 2:33 PM, Mark Sheppard wrote:
Hi,
please oblige and review the updated webrev:
http://cr.openjdk.java.net/~m
, Mark Sheppard wrote:
thanks Roger ... will reduce the focus of the test
regards
Mark
On 09/06/2016 15:58, Roger Riggs wrote:
Hi Mark,
With respect to the test, it seems to do a lot more than just be the
test for the current issue.
Perhaps some javadoc in the test could identify the the
SECOND
The use of static ports could be one to watch. If we encounter port
issues, the test might have to be revisited.
Regards,
Sean.
On 08/06/2016 23:18, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8146975/jdk
arty wrote:
On 8 Jun 2016, at 23:18, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev/
http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev/
which address the issue raised in
https://bugs.openjdk.java.ne
oClient.java
line 157 : s/1000/ONE_SECOND
The use of static ports could be one to watch. If we encounter port
issues, the test might have to be revisited.
Regards,
Sean.
On 08/06/2016 23:18, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msh
sible to reduce the test to a scenario which uses Test3 and
Test4 classes only, as they emulate those
used in the customer application which triggered the problem.
regards
Mark
On 09/06/2016 13:35, Chris Hegarty wrote:
On 8 Jun 2016, at 23:18, Mark Sheppard wrote:
Hi
please oblige and r
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev/
http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev/
which address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8146975
the type checking in inputClassFields
the moniker PEPT-Transport-Thread for the SelectorImpl is a bit like the
name Sue in the Johnny Cash song ...
perhaps ORB-Selector-Thread would be more favourable
also maybe go the "whole hog" with Async-Request-Invoker-Thread, please
just like naming children very emotive :-)
regards
Mark
Hi,
based on feedback from reviews the current version of this fix can
be found at
http://cr.openjdk.java.net/~msheppar/8144144/webrev.05/
please oblige and review
regards
Mark
On 22/01/2016 11:14, Seán Coffey wrote:
On 21/01/16 17:45, Mark Sheppard wrote:
Thanks Sean
i can revert
ctor.close: " + t); --> dprint(".close:
selector.close", t);
The "while (!isClosed()) " change introduces a new hot lock on closed
variable. Hopefully, it won't impact performance too much.
Looks good to me otherwise.
Regards,
Sean.
On 20/01/16 16:16, Mark
, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8144144/webrev/
which addresses the issue
https://bugs.openjdk.java.net/browse/JDK-8144144
the changes ensure that an Acceptor and its associated
ServerSocket/ServerSocketChannel
are
6, at 17:49, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8144144/webrev/
In SelectorImpl.clearDeferredRegistrations() there is no need to call close()
on the Socket returned from channel.socket(), since you have already
close
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8144144/webrev/
which addresses the issue
https://bugs.openjdk.java.net/browse/JDK-8144144
the changes ensure that an Acceptor and its associated
ServerSocket/ServerSocketChannel
are closed.
regards
Mark
the following JBS item exists:
https://bugs.openjdk.java.net/browse/JDK-6432031
search of windows documentation suggests that SO_REUSEPORT is still not
an option
man setsockopt on Solaris shows it as an option, but without precise
description of semantics
regards
Mark
On 22/10/2015 14:33,
ent call in the RESTARTABLE loop will return
another error.
On 08/09/2015 09:28, Chris Hegarty wrote:
On 7 Sep 2015, at 17:41, Mark Sheppard
wrote:
a couple of other considerations in the context of this issue perhaps?
in this s is being duped onto fd, and part of the dup2 operation is
th
the RESTARTABLE loop will return
another error.
On 08/09/2015 09:28, Chris Hegarty wrote:
On 7 Sep 2015, at 17:41, Mark Sheppard wrote:
a couple of other considerations in the context of this issue perhaps?
in this s is being duped onto fd, and part of the dup2 operation is the closing
of
a couple of other considerations in the context of this issue perhaps?
in this s is being duped onto fd, and part of the dup2 operation is the
closing of fd, but
what's is the expected state of file descriptor fd in the event of a
dup2 failure?
s is closed in any case, but what about fd, sho
Hi Rob,
looks fine to me
thanks for handling this issue
regards
Mark
On 05/06/2015 15:41, Rob McKenna wrote:
Added some cleanup code around the BufferedReaders & the leftover test
files:
http://cr.openjdk.java.net/~robm/7130985/webrev.02/
-Rob
On 03/06/15 16:20, Rob McKenna wrote:
Thanks Chris
M.
On 30/03/2015 10:11, Chris Hegarty wrote:
On 27/03/15 19:24, Mark Sheppard wrote:
Hi
based on feedback webrev has been updated as follows:
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev.01/
The changes in the corba repo look good to me Mark.
-Chris
Hi
based on feedback webrev has been updated as follows:
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev.01/
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev.01/
regards
Mark
On 23/03/2015 21:25, Mark Sheppard wrote:
Hi
please oblige and review the following
- separate IIOPOutputStream were used.
regards
Mark
On 24/03/2015 15:46, Peter Levart wrote:
On 03/23/2015 10:25 PM, Mark Sheppard wrote:
Hi
please oblige and review the following fix
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/we
way to avoid this. I don't think jtreg has an @rmic or @idl
similar to @build or @compile?
regards
Mark
On 24/03/2015 07:34, Alan Bateman wrote:
On 23/03/2015 21:25, Mark Sheppard wrote:
Hi
please oblige and review the following fix
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/co
segmentMask);
s.writeFields();
Node[] t;
-Chris.
On Mon, Mar 23, 2015 at 2:25 PM, Mark Sheppard
wrote:
Hi
please oblige and review the following fix
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/
Hi
please oblige and review the following fix
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
which addresses the issue in
https://bugs.openjdk.java.net/browse/JDK-8068721
This relates to RMI-IIOP and the interplay
Hi
please oblige and review the following small changes
http://cr.openjdk.java.net/~msheppar/8040826/webrev/
which address the issues in
https://bugs.openjdk.java.net/browse/JDK-8040826
flagged local variables are explicitly initialized
regards
Mark
Hi
please oblige and review the small change
http://cr.openjdk.java.net/~msheppar/8055204/webrev/
which addresses the parfait issue raised in
https://bugs.openjdk.java.net/browse/JDK-8055204
frees previously allocated memory in an error return path.
regards
Mark
have followed the comments 8011989 and set this to wnf
but the fix below seemed the correct thing to do ... it is a coding
style idiom
as to whether switch statements should have an explicit default case.
regards
Mark
On 18/02/2015 13:47, Alan Bateman wrote:
On 18/02/2015 13:29, Mark Sheppard
Hi
please review the small change
http://cr.openjdk.java.net/~msheppar/8051990/webrev/
to address the parfait issue in
https://bugs.openjdk.java.net/browse/JDK-8051990
regards
Mark
OK I'll remove it.
I thought that property files had been migrated from lib to conf, as per
conf/security, so I made the change
regards
Mark
On 10/02/2015 11:37, Alan Bateman wrote:
On 10/02/2015 11:20, Mark Sheppard wrote:
thanks Alan
the updated corba part is at
thanks Alan
the updated corba part is at
http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev.02/
regards
Mark
On 10/02/2015 09:14, Alan Bateman wrote:
On 07/02/2015 00:22, Mark Sheppard wrote:
Hi Alan,
I had meant to remove the commented lines prior to generating the
patch
Okay
Hi Alan,
I had meant to remove the commented lines prior to generating the patch
regards
Mark
On 06/02/2015 21:21, Alan Bateman wrote:
On 06/02/2015 18:55, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8068682/webrev/
http
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8068682/webrev/
http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev/
which address the issue in
https://bugs.openjdk.java.net/browse/JDK-8068682
this change means CORBA ORB is loaded by the extension
:01, Chris Hegarty wrote:
Mark,
The changes in *test/com/sun/corba/5036554/TestCorbaBug.sh*look fine
to me. I don’t understand the reason for the ones in
*test/com/sun/corba/cachedSocket/7056731.sh.*
-Chris.
On 17 Dec 2014, at 00:48, Mark Sheppard <mailto:mark.shepp...@oracle.com>> wr
Hi
please oblige and review the follow changes
http://cr.openjdk.java.net/~msheppar/8067151/webrev/
to address the issue
https://bugs.openjdk.java.net/browse/JDK-8067151
which sees a test failure for JRE only in an embedded environment.
the test scripts now use the env variable COMPILEJAVA r
Hi
please oblige and review the follow minor change
diff -r c0d1026bff6f src/java.base/share/native/libfdlibm/k_standard.c
--- a/src/java.base/share/native/libfdlibm/k_standard.c Tue Nov 04
15:10:38 2014 +
+++ b/src/java.base/share/native/libfdlibm/k_standard.c Mon Nov 10
19:02:57 2014 +00
thanks Alan ... grand, I'll replace the "if (clazz == null) return; "
with a CHECK_NULL(clazz);
regards
Mark
On 10/11/2014 17:59, Alan Bateman wrote:
On 10/11/2014 17:37, Mark Sheppard wrote:
Hi
please oblige and review the follow change
diff -r c0d1026bff6f
src/java.base
Hi
please oblige and review the follow change
diff -r c0d1026bff6f src/java.base/windows/native/libnio/MappedByteBuffer.c
--- a/src/java.base/windows/native/libnio/MappedByteBuffer.cTue Nov
04 15:10:38 2014 +
+++ b/src/java.base/windows/native/libnio/MappedByteBuffer.cMon Nov
10 17:
Hi,
please oblige and review the change
http://cr.openjdk.java.net/~msheppar/8049522/webrev/
to address the issue
https://bugs.openjdk.java.net/browse/JDK-8049522
this is javadoc change, which amends the implNote in ORB.java,
relating to the ORBSingleton class loading strategy in JDK9.
regar
Hi
please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/8038861/webrev/
which addresses the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8038861
HREFs in FloatSeqHelper.java java doc are incorrect, and fix changes
cgi.omg.org to www.omg.org
regard
Hi Alan,
we retrieved the IDL from the OMG web site
http://www.omg.org/spec/CORBAe/20080201/CORBA_TypeCode.idl
to regenerate the Helper classes ... this didn't compile properly and
had to be manipulated to get the relevant exceptions required
IvalidName is defined in
http://www.omg.org/spec/CO
Hi Pavel,
the changes look ok I've run some relevant jck tests (naming
management rmi) and the CORBA regression suite
for the changeset, with no perceptible issues
regards
Mark
On 14/07/2014 12:43, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8048175?
ht
Hi Sean,
fix looks good .. surprised to see that GF has been modified to use
HashMap and not the JDK wasn't!!
In anycase this should solve a few other interop issues
WRT the test, I wonder if it is more appropriate to use the
javax.rmi.CORBA.Util class to obtain the ValueHandler rather tha
Hi Alan,
yes the differences in location was an issue and the jdk8
CoreLibraries.gmk had a clash
regards
Mark
On 02/06/2014 14:37, Alan Bateman wrote:
On 31/05/2014 23:02, Mark Sheppard wrote:
Hi,
please oblige and review the following change
http://cr.openjdk.java.net/~msheppar
Hi,
please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/8041602/webrev/
which addresses the issue
https://bugs.openjdk.java.net/browse/JDK-8041602
which is a backport of
https://bugs.openjdk.java.net/browse/JDK-8035340
the original changeset didn't apply cleanl
Hi,
please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/8044343/webrev/
which addresses issue
https://bugs.openjdk.java.net/browse/JDK-8044343
which is a backport of
https://bugs.openjdk.java.net/browse/JDK-8036603
the original changeset didn't apply cleanly an
seems that putIfAbsent would not though. This is indeed confusing.
I wish putIfAbsent had been specified similarly to
computeIfAbsent...
best regards,
-- daniel
ConcurrentHashMap seems to have something more
On 5/12/14 1:33 PM, Mark Sheppard wrote:
If I read the javdoc correctly neither computeIf
If I read the javdoc correctly neither computeIfAbsent nor putIfAbsent
seem to match the
previous semantics of the if statement?
computeIfAbsent: "If the value for the specified key is present and
non-null, attempts to compute a new mapping given the key and its
current mapped value."
or
"If
Hi Roger,
I have a few questions for your consideration, hopefully they make
sense!
Is this API to be available to the plug-in/applet? Even with appropriate
permissions?
What permissions are required to invoke operations on the API?
Do you need to differentiate between "spawning" a Java p
Hi Alan,
so L61 should be
if ((bytes = (*env)->NewByteArray(env, i)) == NULL) {
FreeEnvironmentStringsA(blockA);
return NULL;
}
regards
Mark
On 12/03/2014 17:24, Alan Bateman wrote:
On 12/03/2014 17:18, Mark Sheppard wrote:
Hi
an updated webrev as per suggested changes
h
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8035870/webrev/
which address the issues raised in
https://bugs.openjdk.java.net/browse/JDK-8035870
summary:
checks to return values from malloc added with appropriate
JNU_ThrowOutOfMemoryError added
re
Hi
an updated webrev as per suggested changes
http://cr.openjdk.java.net/~msheppar/8036603/webrev.01/
regards
Mark
On 07/03/2014 22:21, Mark Sheppard wrote:
Thanks Alan and Mandy for the feedback
I make the amendments as you both suggest
regards
Mark
On 07/03/2014 21:34, Alan Bateman
Hi,
Please oblige and review the changes
http://cr.openjdk.java.net/~msheppar/8036603/webrev/
which address the issues raised in
https://bugs.openjdk.java.net/browse/JDK-8036603
summary
JNU_ClassString extracted as parameter to GetMethodID and NewObject calls
and NUL_CHECKed
regards
Mark
Subject should read
RFR: JDK-8036609
apologies for the typo.
regards
Mark
On 07/03/2014 13:05, Mark Sheppard wrote:
Hi
Please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8036609/webrev/
for the issues raised in
https://bugs.openjdk.java.net/browse/JDK
Hi
Please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8036609/webrev/
for the issues raised in
https://bugs.openjdk.java.net/browse/JDK-8036609
summary:
changes adds a couple of ExceptionChecks and a jboolean cast for CloseHandle
regards
Mark
thanks Alan ... excellent spot (L124)
regards
Mark
On 05/03/2014 21:33, Alan Bateman wrote:
On 05/03/2014 19:53, Mark Sheppard wrote:
Hi
Please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8035340/webrev/
which address the issues raised in
https
thanks Chris
On 05/03/2014 21:50, Chris Hegarty wrote:
Looks ok to me Mark.
-Chris.
On 05/03/2014 19:53, Mark Sheppard wrote:
Hi
Please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8035340/webrev/
which address the issues raised in
https
1 - 100 of 127 matches
Mail list logo
