Thanks.
Daniel -- could you please push
http://cr.openjdk.java.net/~jgish/TestRB.7.2/
http://cr.openjdk.java.net/%7Ejgish/TestRB.7.2/ ?
Jim
On 05/16/2013 08:13 AM, Alan Bateman wrote:
On 16/05/2013 03:46, Mandy Chung wrote:
On 5/15/2013 2:19 PM, Jim Gish wrote:
Please review http
getGlobal()/handler test doesn't cloud the deadlock testing issue.
- replacing the references in LogManager to global with getGlobal()
(basically to get rid of deprecated usage).
Thanks,
Jim
On 04/24/2013 05:23 PM, Jim Gish wrote:
Please review
http://cr.openjdk.java.net/~jgish/Bug7184195
the
TCCL is not feasible.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
On 04/30/2013 04:29 PM, Alan Bateman wrote:
On 30/04/2013 17:48, Jim Gish wrote:
Please review http://cr.openjdk.java.net/~jgish/TestRB.2/
http://cr.openjdk.java.net/%7Ejgish/TestRB.2/
This fixes a regression caused by the removal of the search of the
call stack for resource bundles
Here's an update:
http://cr.openjdk.java.net/~jgish/TestRB.3/
http://cr.openjdk.java.net/%7Ejgish/TestRB.3/
Thanks,
Jim
On 04/30/2013 05:10 PM, Jim Gish wrote:
On 04/30/2013 04:29 PM, Alan Bateman wrote:
On 30/04/2013 17:48, Jim Gish wrote:
Please review http://cr.openjdk.java.net
developed during a recent
fix to a logging deadlock, which helps us detect and report on the
details of a deadlock.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g
Hi Henry, Can you please comment on the simplifications you did ?
Thanks,
Jim
On 04/18/2013 07:38 PM, Ulf Zibis wrote:
Am 18.04.2013 19:37, schrieb Jim Gish:
On 04/18/2013 08:49 AM, Ulf Zibis wrote:
Hi,
I'm wondering, that StringJoiner has some logic for pre/suffix, but
nothing
Martin,
I've updated the toString() method as you suggested.
http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/
http://cr.openjdk.java.net/%7Ejgish/Bugs-5015163-7172553/
Thanks,
Jim
On 04/18/2013 05:02 PM, Martin Buchholz wrote:
On Thu, Apr 18, 2013 at 10:34 AM, Jim Gish jim.g
,
Thanks for fixing this.
On 4/12/2013 1:11 PM, Jim Gish wrote:
Please review:
http://cr.openjdk.java.net/~jgish/Bug8010939-LogManager-Deadlock/
The fix looks okay. I would recommend to move the call to
manager.drainLoggerRefQueueBounded() back to LogManager.addLogger
which was originally
code to do the concatenation.
Roger
On 4/17/13 5:49 PM, Jim Gish wrote:
Here's an update:
http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/
http://cr.openjdk.java.net/%7Ejgish/Bugs-5015163-7172553/
Jim
On 04/17/2013 03:15 PM, Mike Duigou wrote:
String::
line 1253: This should use
. And if we're just talking
about pure convenience, it's hard to beat
[ + String.join(...) + ]
On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish jim.g...@oracle.com wrote:
Here's an update: http://cr.openjdk.java.net/~**
jgish/Bugs-5015163-7172553/http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/
http
properly.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
Thanks for catching that. I thought I fixed it. (In fact, I'm sure I
did in the latest rev).
On 04/18/2013 05:03 PM, Martin Buchholz wrote:
Garbled javadoc:
41 * method will, by default, return {@code prefix+{@code suffix}}.
However, if
--
Jim Gish | Consulting Member
I'm going to rip out the /li then. It's an unnecessary burden.
Thanks
Jim
On 04/16/2013 06:50 PM, Mike Duigou wrote:
On Apr 16 2013, at 08:50 , Alan Bateman wrote:
On 16/04/2013 16:13, Jim Gish wrote:
On 04/15/2013 02:02 PM, Martin Buchholz wrote:
You are fiddling with the javadoc
include emptyOutput in @throws NPE
On Apr 11 2013, at 15:33 , Jim Gish wrote:
Please review http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/
http://cr.openjdk.java.net/%7Ejgish/Bugs-5015163-7175206-7172553/
These are changes that we made in lambda that we're now bringing into JDK8
at 2:49 PM, Jim Gish jim.g...@oracle.com
mailto:jim.g...@oracle.com wrote:
Here's an update:
http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/
http://cr.openjdk.java.net/%7Ejgish/Bugs-5015163-7172553/
http://cr.openjdk.java.net/%7Ejgish/Bugs-5015163-7172553/
Jim
the exception
javadoc, then also change @exception to @throws.
The only reason I'm adding /li is Alan insisted on it in a previous
change I proposed :-)
Jim
On Thu, Apr 11, 2013 at 3:33 PM, Jim Gish jim.g...@oracle.com
mailto:jim.g...@oracle.com wrote:
Please review
http
Please review:
http://cr.openjdk.java.net/~jgish/Bug8010939-LogManager-Deadlock/
http://cr.openjdk.java.net/%7Ejgish/Bug8010939-LogManager-Deadlock/
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network
a
couple of constructors to set the emptyOutput chars.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
Thank you. Could someone push it for me please.
Cheers,
Jim
On 04/05/2013 05:21 PM, Lance Andersen - Oracle wrote:
looks ok
On Apr 5, 2013, at 5:18 PM, Jim Gish wrote:
Please review trivial change to add back in delete of test files on test
completion.
http://cr.openjdk.java.net
to avoid name
conflict with the member count and make the code more readable / obvious.
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
Hi Laurent,
If you'd like to submit an improved patch, I'll take a look. The best
way to do this is to post a webrev:
http://openjdk.java.net/guide/webrevHelp.html
Looking forward to your participation and contributions. Welcome!
Thanks,
Jim Gish
On 03/20/2013 08:45 AM, Laurent
Chung wrote:
On 3/8/2013 2:39 PM, Jim Gish wrote:
I've update the webrev with the suggested changes:
http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/
http://cr.openjdk.java.net/%7Ejgish/Bug8002070-RemoveResourceBundleStackSearch/
Thumbs up. Thanks for adding
, Jim Gish wrote:
For the LoggerResourceBundleRace test then does it have to run in
its own VM?
Because we no longer search up the stack for the bundles, this test
fails unless run in its own vm. However, to avoid this, I'll try to
change the test to set the context classloader.
I discussed
, the bundles can't be found via the system classloader.
However, both directly running the tests and running in jprt which uses
jtreg -a (agentvm) works fine. I can leave the test as is.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform
On 03/06/2013 12:58 PM, Mandy Chung wrote:
On 3/5/2013 9:16 AM, Jim Gish wrote:
On 03/01/2013 05:48 PM, Mandy Chung wrote:
On 3/1/2013 1:25 PM, Jim Gish wrote:
Please review
http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/
This removes the stack search from
On 03/01/2013 05:48 PM, Mandy Chung wrote:
On 3/1/2013 1:25 PM, Jim Gish wrote:
Please review
http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/
This removes the stack search from Logger.findResourceBundle()
It's good to see this stack walk search of resource
The webrev has been updated as requested:
http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/
A CCC request has been filed.
Thanks,
Jim
On 03/05/2013 02:12 PM, Jim Gish wrote:
On 03/03/2013 09:15 AM, Alan Bateman wrote:
On 01/03/2013 21:25, Jim Gish wrote
/functionality, a CCC
request will be filed.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
This time with the attachment...
Thanks,
Jim
On 01/22/2013 02:54 PM, Jim Gish wrote:
change set/patch attached for pushing.
Thanks,
Jim
On 01/22/2013 02:40 PM, Jim Gish wrote:
I've made the changes as suggested by Mike, and this has now been
approved by CCC. Could someone please give
-Blanket-Null-Stmt/
On 01/10/2013 11:00 AM, Jim Gish wrote:
Stephen,
Currently here's (a sampling) of how the other methods work.
Although most check indices first, not all do... (The original bug was
about this very inconsistency, however one answer given to it was that
in general we don't
change set/patch attached for pushing.
Thanks,
Jim
On 01/22/2013 02:40 PM, Jim Gish wrote:
I've made the changes as suggested by Mike, and this has now been
approved by CCC. Could someone please give it one more look and push
it for me, please?
Thanks,
Jim
http://cr.openjdk.java.net
by one until reaching the max reserved port number, which just happens
to correspond to the 10th attempt, and the code then quits trying.
The proposed fix (one of many possible alternatives, of course) simply
retries for twice the number of ports in the range.
Thanks,
Jim
--
Jim Gish
matter though.
Otherwise, it looks good.
Mike
On Jan 9 2013, at 14:46 , Jim Gish wrote:
Please review the following:
Webrev: http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/
http://cr.openjdk.java.net/%7Ejgish/Bug4247235-Add-Blanket-Null-Stmt/
Here's a specdiff: http
Would you be so kind as to push it, please?
Thanks,
Jim
On 01/10/2013 12:41 AM, Stuart Marks wrote:
On 1/9/13 10:49 AM, Jim Gish wrote:
Please review:
http://cr.openjdk.java.net/~jgish/Bug8005582-WinCommand-test-failures/
http://cr.openjdk.java.net/%7Ejgish/Bug8005582-WinCommand-test
a failed test like this, we'd have a better shot at tracking
this down.
Jim
On 01/10/2013 06:34 AM, Alan Bateman wrote:
On 09/01/2013 19:46, Jim Gish wrote:
It's a Windows feature. We discovered this recently in debugging
another test failure. Windows is documented to do asynchronous
. There really is no need for tests to delete files from the
scratch directory at the end of a test because jtreg carries a guarantee
of cleanup.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
On 01/09/2013 02:33 PM, Martin Buchholz wrote:
On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish jim.g...@oracle.com
mailto:jim.g...@oracle.com wrote:
I'm in the process of adding deletion retry behavior to jtreg, but
in the meantime we think it makes sense to provide a more stable
were previously silent on null handling, but all
already conform to the blanket statement).
Thanks,
Jim Gish
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
-consistency/
Here's the specdiff as well:
http://cr.openjdk.java.net/~jgish/Bug8005118-string-specdiff/
http://cr.openjdk.java.net/%7Ejgish/Bug8005118-string-specdiff/
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries
Thanks, Joe. Could you please submit for me?
Jim
On 12/28/2012 02:07 PM, Joe Darcy wrote:
Looks fine; cheers,
-Joe
On 12/28/2012 7:19 AM, Jim Gish wrote:
Please revieiw the following change (simple, non-functional, non-spec
change to bring some consistency to the javadoc tags - using
with this mechanism removed.
This is basically just test cleanup (no library code changes) to clear
the way for future test enhancements to improve performance and
reliability.
Thanks,
s'marks
--
Jim Gish | Consulting Member of Technical Staff
:
Hello,
Please review these changes to add core reflection support to
recognize default methods:
8005042 Add Method.isDefault to core reflection
http://cr.openjdk.java.net/~darcy/8005042.0/
Thanks,
-Joe
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java
Excuse me, a comma.
On 12/18/2012 04:20 PM, Jim Gish wrote:
Code looks good, Joe. There is just one grammatical nit with the comment:
* A default method is a non-abstract method, that is a method with
512 * a body, declared in an interface type.
that is should have a comment
On 12/15/2012 08:58 AM, Alan Bateman wrote:
On 14/12/2012 22:49, Jim Gish wrote:
Please review
http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/
http://cr.openjdk.java.net/%7Ejgish/Bug4247235-Add-Blanket-Null-Stmt/
This minor spec change (which will require CCC approval
I've created a new bug: https://jbs.oracle.com/bugs/browse/JDK-8005118 -
I'll address the consistency issues there, and treat the NPE specs
separately.
Jim
On 12/17/2012 11:29 AM, Jim Gish wrote:
On 12/15/2012 08:58 AM, Alan Bateman wrote:
On 14/12/2012 22:49, Jim Gish wrote:
Please review
,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
,
equivalent to the one already in String.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
Yes, please.
Thanks,
Jim
On 12/11/2012 07:02 PM, Stuart Marks wrote:
Looks good!
Do you need someone to push this for you?
s'marks
On 12/11/12 3:04 PM, Jim Gish wrote:
A bit more cleanup as suggested:
http://cr.openjdk.java.net/~jgish/Bug8004651-CheckLockLocationTest-Windows-delete
need to catch
IOE here at all; we can just let it propagate to the caller.
Looks like similar simplifications apply to tests 2 and 4 as well.
s'marks
On 12/7/12 11:18 AM, Jim Gish wrote:
Please review
http://cr.openjdk.java.net/~jgish/Bug8004651-CheckLockLocationTest-Windows-delete-file-fix
that have been generated over the
years for every single release since 1.4, where someone has just said
Ah that one. It's trivial. Just forget it. Jeez! (rant over :-) )
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries
, while fixing this problem another one popped up -- not
all platforms generate the same message in the FileSystemException (Not
a directory), so removing the exception content check.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core
Gish wrote:
OK -- how about a push then for now and with luck we might get some
useful
output in a day or two.
Jim
On 12/04/2012 04:22 PM, Alan Bateman wrote:
On 04/12/2012 21:10, Jim Gish wrote:
:
P.S. working on adding nestat -a output per Alan's suggestion.
BTW: I didn't mean you have
8:41 AM, Jim Gish wrote:
BTW printStackTrace() prints to standard error by default -- that's
why I don't
explicitly have it in there.
Oh yes, so it does. Sorry, I was confused.
s'marks
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core
at the top of the loop
should fix it.
You need me to push this for you? I can drop in this change before I
push, if you're OK with me doing this.
s'marks
On 12/5/12 12:51 PM, Jim Gish wrote:
Here's a new version for your consideration :-)
http://cr.openjdk.java.net/~jgish/Bug8004317
http://cr.openjdk.java.net/~jgish/Bug8003596-CheckLockLocationTest-Windows-fix/
http://cr.openjdk.java.net/%7Ejgish/Bug8003596-CheckLockLocationTest-Windows-fix/
Better? :-)
Thanks,
Jim
On 12/04/2012 06:28 AM, Alan Bateman wrote:
On 03/12/2012 15:01, Jim Gish wrote:
Thanks. Could you
Thanks. Could you please push the change.
Jim
On 12/01/2012 10:44 AM, Alan Bateman wrote:
On 30/11/2012 23:19, Jim Gish wrote:
Please review
http://cr.openjdk.java.net/~jgish/Bug8003596-CheckLockLocationTest-Windows-fix/
http://cr.openjdk.java.net/%7Ejgish/Bug8003596-CheckLockLocationTest
not support setWritable.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/
and if ok, Chris, could you please go ahead and push the changes?
thanks,
Jim
On 11/28/2012 01:27 PM, Jim Gish wrote:
Here's the list of @suppresswarnings values that are recognized by
Eclipse Juno:
Excluding warnings using
it will
not be implementable everywhere.
-Alan
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
of the property does not affect the result.
The only place where the java.awt.headless value is essential is the
image coding/decoding.
All mentioned tests (that are marked as headless - ok) was tested in
ssh session from Win to Mac OS without
additional switches.
Regards,
-uta
--
Jim Gish
?
Logger logger = Logger.getLogger(com.sun.Hello+cnt/10);
---
Logger.getLogger(com.sun.Hello+cnt/10);
... and similar for other areas?
Otherwise, I'm happy with the change and can push is for you.
-Chris
On 14/11/2012 23:13, Jim Gish wrote:
I've updated the webrev with your suggestion
it up on nio-dev unless you
know off the top of your head why we're not checking for ENOTDIR error code.
On 11/14/2012 06:08 AM, Alan Bateman wrote:
On 13/11/2012 21:30, Jim Gish wrote:
Here's a new webrev with my latest changes for your reviewing
pleasure :-)
http://cr.openjdk.java.net/~jgish
Please review
http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/
http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/
These are simple changes to eliminate compiler warnings from
java.util.logging test code.
Thanks,
Jim
--
Jim Gish | Consulting Member
to directly compare the character arrays rather than
making a copy of the substring before comparing.
http://cr.openjdk.java.net/~mduigou/6553074/0/webrev/
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
On 11/14/2012 04:38 PM, Alan Bateman wrote:
On 14/11/2012 20:56, Jim Gish wrote:
Check out the latest, please --
http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/
http://cr.openjdk.java.net/%7Ejgish/Bug6244047-FileHandler-CheckLockLocation/
-- If it's ok, please
is deprecated.
...Jim
-Chris
On 14 Nov 2012, at 21:15, Jim Gish jim.g...@oracle.com
mailto:jim.g...@oracle.com wrote:
Please review
http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/
http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/
http
I've updated the webrev with your suggestion. Here it is:
http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/
http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/
Could someone please push it?
Thanks,
Jim
On 11/14/2012 05:48 PM, Jim Gish wrote:
On 11/14
On 11/13/2012 07:08 AM, Alan Bateman wrote:
On 12/11/2012 23:22, Jim Gish wrote:
Which file(s) are you concerned about truncating/damaging? The code
I'm impacting is for creating a new lock file. Where is the
potential for truncating/damaging that you both are referring
@openjdk.java.net
Subject: Re: RFR: 6244047: impossible to specify directories to
logging FileHandler unless they exist
On 11/13/2012 07:08 AM, Alan Bateman wrote:
On 12/11/2012 23:22, Jim Gish wrote:
Which file(s) are you concerned about truncating/damaging?
The code I'm impacting
, Jim Gish wrote:
On 11/13/2012 03:36 PM, Jason Mehrens wrote:
Jim,
Looking at the webrev again I think I tricked myself into thinking
that 'parentFile' was a file that could be opened with a stream when
it actually is a directory. I think the best fix would be to add a
check in the catch
to just use FileChannel.open(lf, WRITE), that won't truncate
the file and will also throw a useful IOException in the event that it
fails. As there are specific IOException thrown for specific cases
then it may be possible to eliminate the loop completely for I/O error
cases.
-Alan
--
Jim Gish
does not do as some users would like, which is to go
ahead and create directories that don't exist.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
with this change?
Mandy
Feedback is most welcome,
/Staffan
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
for the discussion to spiral off into minutia and lose sight of the
goal -- which is to provide useful feedback on the API we're asking for
feedback on.
http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform
. Even though I am on this list, I don't read
every message that comes past. I did see your one, but I forgot to
reply and without Martijn's prompting it would have escaped into the
mists of time.
Regards
Heinz
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java
for approval.
On 10/30/2012 02:30 PM, Alan Bateman wrote:
On 30/10/2012 14:21, Jim Gish wrote:
I was one the fence with the parameter ordering and would like
additional feedback on this point. I started off as you suggested,
but didn't like the fact that the params were separated from the msg
, it makes a small refactoring change to the existing log
message to better enable sub-classing of Logger.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
/2012 4:13 PM, Jim Gish wrote:
Please review
http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-init-fix/
In JDK7, Logger.global was deprecated because of potential deadlock
problems. The method getGlobal() was introduced as a convenience
method to get the global logger in lieu
:40 PM, Mandy Chung wrote:
On 10/24/2012 12:31 PM, Jim Gish wrote:
See updated webrev:
http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler
Looks good. Thanks for the update.
MemoryHandlerTest.java - thanks for renaming it but you forget to
change L28 @run tag. jtreg
, corresponding Java codes are added for each
platform. Thanks!
-Dan
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
Fine and Dandy :-)
...Jim
On 10/25/2012 05:45 PM, Dan Xu wrote:
Hi,
Please help review the javadoc typo fix at,
http://cr.openjdk.java.net/~dxu/8001565/webrev/. Thanks!
-Dan
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries
See updated webrev:
http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler
Thanks,
Jim
On 10/17/2012 03:46 PM, Mandy Chung wrote:
Hi Jim,
On 10/11/2012 2:37 PM, Jim Gish wrote:
Please review the updated changes at
http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging
and hence results in proper setup of the logging sytem /and /a working
global logger with no assembly required :-)
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g
Fixed. Just needed to change a ul to /ul in StreamHandler.java
Jim
On 10/17/2012 02:46 PM, Jim Gish wrote:
I just discovered a small syntax error in StreamHandler (thanks to
specdiff :-)). I'll regenerate the webrev shortly.
Jim
On 10/17/2012 12:41 PM, Jim Gish wrote:
Thanks. I believe
Here's an updated webrev that fixes some javadoc syntax issues:
http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/
http://cr.openjdk.java.net/%7Ejgish/Bug7159567-set-logging-MemoryHandler/
Thanks,
Jim
On 10/11/2012 05:37 PM, Jim Gish wrote:
Please review the updated
to go
away. LoggingMXBeanTest2 has the same issue, but no bug has (yet) been
filed against it.
The fix is to simply make the Logger variables static so they don't get
gc'd.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core
is in sun.util.spi for now. Maybe in the future
it may be necessary to define a standard provider interface but it is
not needed at this time (in addition it would require getting the
security right to do that).
Thanks,
Alan.
[1] http://openjdk.java.net/jeps/161
--
Jim Gish | Consulting Member
of assurance that
modifications to StringBuffer, particularly addition of new methods, do
not break the synchronization contract. The code also includes a
self-test to guard against breaking the test program itself.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff
:22, Jim Gish wrote:
Alan Chris,
I agree with you that the new approach is less clear than the
previous approach, but the original approach suffered from code
duplication which was the motivation for the change. However, let me
propose something else. How about /all /the methods
that they are well tested.
I'm in too minds on the addition of @Override, some people like it,
some people don't. With the proposed changes then you've added it to a
subset of the methods that are overridden so it's a bit inconsistent.
-Alan.
--
Jim Gish | Consulting Member of Technical Staff
Please review the changes described below. Again, at
http://cr.openjdk.java.net/~jgish/Bug6206780-sb-append-forward/
http://cr.openjdk.java.net/%7Ejgish/Bug6206780-sb-append-forward/
Thanks,
Jim
On 09/26/2012 01:22 PM, Jim Gish wrote:
On 09/26/2012 06:12 AM, Chris Hegarty wrote:
Hi Jim
it easier to find.
The webrev, as posted at
http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/
http://cr.openjdk.java.net/%7Ejgish/Bug7159567-set-logging-MemoryHandler/
Thanks,
Jim
On 09/27/2012 10:05 AM, Jim Gish wrote:
I agree.
I reached the same conclusion, but wanted
subclass methods that are already
synchronized.
Good catch. I verified this, and you're absolutely right. Fixed.
Thanks. I'll re-spin the patch and send it your way for pushing, if you
would be so kind, please.
Cheers,
Jim
-Chris.
On 25/09/2012 23:03, Jim Gish wrote:
Please review
Sorry -- wrong list -- I mean to send to the openjdk list.
On 09/26/2012 05:19 PM, Jim Gish wrote:
Please review
http://cr.openjdk.java.net/~jgish/Bug7159567-set-MemoryHandler-target/
http://cr.openjdk.java.net/%7Ejgish/Bug7159567-set-MemoryHandler-target/
Overview - currently you can sub
Time to go home :-( I did send to the right list-- it's just that my
mailer didn't show the whole address. Yikes! Sorry about the spam.
Please review as originally requested.
On 09/26/2012 06:21 PM, Jim Gish wrote:
Sorry -- wrong list -- I mean to send to the openjdk list.
On 09/26/2012
,
java.util.logging.MemoryHandler.target. For example,
java.util.logging.MemoryHandler.target=java.util.logging.ConsoleHandler
This is clearly broken. This bug fix allows you to say:
com.foo.MyMemoryHandler.target=java.util.logging.ConsoleHandler
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff
) and
StringBuilder.append(StringBuffer) are both handled properly.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
mind adding a bit of verbiage to make things clear without having the
user guess or hop around the docs to verify.
Cheers,
Jim
On 09/18/2012 09:43 PM, David Holmes wrote:
Note that subsequent operations on this StringBuffer can reduce the
actual capacity below that requested here.
--
Jim Gish
capacity. The capacity may change as
+ * the result of subsequent operations.
*
* @param minimumCapacity the minimum desired capacity.
*/
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35
1 - 100 of 122 matches
Mail list logo
