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 revie
igated.
Thanks,
Jim
On 04/30/2013 08:13 PM, Jim Gish wrote:
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/201
tion in the
basic 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
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.openj
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 bund
setting 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
ity class I 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
te:
Hi Jim,
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
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 A
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
nothi
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 Memb
), are
working 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
iner implementation. 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 wrote:
Here's an update: http://cr.openjdk.java.net/~**
jgish/Bugs-5015163-7172553/<http://cr.
rite their
own 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::
in(...) + "]"
On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish <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.j
lude 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
I'm going to rip out the 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 j
e the exception
javadoc, then also change @exception to @throws.
The only reason I'm adding is Alan insisted on it in a previous
change I proposed :-)
Jim
On Thu, Apr 11, 2013 at 3:33 PM, Jim Gish <mailto:jim.g...@oracle.com>> wrote:
Please review
http://cr.openjdk.java.net/
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 T
final and adding 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
Please review trivial change to add back in delete of test files on test
completion.
http://cr.openjdk.java.net/~jgish/Bug8006036-WinCommand/
<http://cr.openjdk.java.net/%7Ejgish/Bug8006036-WinCommand/>
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.44
he local var count could be renamed _count or c 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 A
Mandy 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. Than
13 11:12 AM, 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
th -s -- samevm. In
this case, 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 | +
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
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
On 03/03/2013 09:15 AM, Alan Bateman wrote:
On 01/03/2013 21:25, Jim Gish wrote:
Please review
http://cr.openjdk.java.net/~jgish/Bug8002070-RemoveResourceBundleStackSearch/
<http://cr.openjdk.java.net/%7Ejgish/Bug8002070-RemoveResourceBundleStackSearch/>
This removes the stack searc
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 res
e spec/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
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.jav
7235-Add-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
er
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
--
Ji
after 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
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-t
minor 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 specd
statement, and the fact that some of the
existing methods 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 Net
On 01/09/2013 02:33 PM, Martin Buchholz wrote:
On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish <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
test
est
itself. 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 Ne
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
pec-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 Plat
it. All RMI tests continue to pass
even 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'mar
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" s
arcy wrote:
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.0
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
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:
Ple
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 ap
uilder,
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-d
declared to throw IOException, so we might not even 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/Bug80
eports 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
Also, 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 Jav
I think setting unusedRandomPort back to -1 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 consi
e:
On 12/5/12 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
any
changes to the source code
s'marks
On 12/4/12 1:42 PM, Jim 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 addi
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 to r
Yeah -- I suppose that was silly. I could've started with -1. I'll
clean it up on the next round.
On 12/04/2012 04:10 PM, Jim Gish wrote:
The initial code was a bit strange in that it started out with an int
set to the min "reserved" port number. I chose an Integer s
M, Darryl Mocek wrote:
Hi Jim,
changes look OK to me, although I'm curious why you chose to use an
Integer instead of an int.
Darryl
On 12/04/2012 12:03 PM, Jim Gish wrote:
Please review
http://cr.openjdk.java.net/~jgish/Bug8004317-TestLibrary-getUnusedRandomPort-Failure/
<htt
t failures.)
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
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. Cou
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-CheckLockLocationT
s does 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
arnings/
<http://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:
the same as the words defined for -Xlint.
[1]
http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5
Whoops, the JLS defines "deprecation" as well (as Alan pointed out in
another thread the other day). But the rest of the point stands.
s'marks
--
Ji
ings("unused"), will the follow keep the compiler happy?
< 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 p
uot;headless - ok") was tested in
ssh session from Win to Mac OS without
additional switches.
Regards,
-uta
--
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
e 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
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 wro
it is on a URI is deprecated.
...Jim
-Chris
On 14 Nov 2012, at 21:15, Jim Gish <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/>
<
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
er 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
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
, etc. and bring 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 :-)
On 11/13/2012 03:52 PM, 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 b
_mehr...@hotmail.com; core-libs-dev@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/damagi
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 to?
Is
simpler 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.
-Ala
t this fix 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
along 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
ts.eu. 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.0
are time-boxed at one week. (until Nov. 7th)
- Please review the whole bunch in a single message if possible, rather than in
bits and pieces. It is far easier to extract useful feedback from one complete
review than from a dozen partial ones.
- Please wait a few days before replying to other pe
espond with
the slides perhaps you can contact them.
Mike
On Oct 13 2012, at 03:44 , fuyou wrote:
hi all
I am very interested in session of HOL6500 - Finding and Solving Java
Deadlocks(JavaOne 2012) .how can i watch video or download slides.
Thanks!
--
=====
://cr.openjdk.java.net/~ksrini/8001191/webrev.0/
Note: this webrev is generated against the master repository but
changes will be
pushed via tl after the tl-master sync is completed.
Thanks
Kumar
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group
x27;ll submit to CCC 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 we
wable thrown)*
So this will keep it consistent.
Thanks
Sandeep
*From:*Jim Gish
*Sent:* Monday, October 29, 2012 4:33 PM
*To:* core-libs-dev
*Cc:* Rajendra Inamdar; Sandeep Shrivastava
*Subject:* RFR: 6594697 - varargs message and Throwable methods for
java.util.Logger
Please review
10/24/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
dition, 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
Fine and "Dan"dy :-)
...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 Gr
, 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
Thanks,
Jim
On 10/24/2012 08: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
cha
obal() is called
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
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
Fixed. Just needed to change a to 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
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 tags are optional, and since they weren't
there before, I didn't put them in. The generated j
Thanks. I believe tags are optional, and since they weren't there
before, I didn't put them in. The generated javadoc looks ok.
Jim
On 10/17/2012 11:39 AM, Alan Bateman wrote:
On 15/10/2012 20:18, Jim Gish wrote:
Here's an updated webrev that fixes some javadoc synta
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
...@oracle.com
To: jim.g...@oracle.com
Cc: core-libs-dev@openjdk.java.net
Sent: Friday, October 12, 2012 6:59:45 PM GMT -05:00 US/Canada Eastern
Subject: Re: Please review: 7146552 LoggingMXBeanTest intermittent failure
On 10/12/2012 9:55 AM, Jim Gish wrote:
> Please review
> http://cr.openjdk.ja
1 - 100 of 143 matches
Mail list logo
