Re: Code review request for 6857789: (reflect) Create common superclass of reflective exceptions

This request seems dangerous, InvocationTargetException should not be retrofitted because usually its catch block is different from the others. As is, this patch will introduce more burden than it tries to revolve. Let me try to explain, all other exceptions can be avoided by checking modifiers,

Re: Code review request for 6857789: (reflect) Create common superclass of reflective exceptions

Thanks for this; I had a chance to use it in the past week, if it had been there. - typo + * Conqstructs a new exception with {...@code null} as its detail - Start paragraphs on new lines. + * and cause. Note that the detail message associated with - Otherwise, looks good!

Code review request for 6857789: (reflect) Create common superclass of reflective exceptions

Hello. Please review the patch below to fix 6857789: (reflect) Create common superclass of reflective exceptions Half a dozen checked exceptions thrown by methods in core reflection don't have a superclass more specific than Exception, requiring multiple catch blocks around code using cor

Re: Miscellaneous improvements to "jar".

Thanks Martin! -Joe Martin Buchholz wrote: Alright, I am all done with "jar" improvements. (although the jar command is still far from perfect) All the fixes (in particular, to make "jar" faster) are in openjdk7 and openjdk6. Martin On Mon, Jul 6, 2009 at 13:58, Martin Buchholz

Re: Miscellaneous improvements to "jar".

Alright, I am all done with "jar" improvements. (although the jar command is still far from perfect) All the fixes (in particular, to make "jar" faster) are in openjdk7 and openjdk6. Martin On Mon, Jul 6, 2009 at 13:58, Martin Buchholz wrote: > I will atone for my use of nio2 > by providing the

execvpe and glibc 2.10

Sorry, I should never have named a function (not even a static one) 'execvpe'. It's amusing that I broke myself by requesting that glibc implement 'execvpe'. Here's the webrev: http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/ For those following things, there are now 3 pendin

Re: malloc failures in java/util/zip/Deflater

Il 09/07/2009 19:41, Xueming Shen ha scritto: Zero length entry should be allowed. This is a regression, the result of the un-successful fix for 6728376:-( The webrev for 6728376 is http://cr.openjdk.java.net/~sherman/6728376/webrev We have the same in Inflater as well. I will file a bug for i

Re: malloc failures in java/util/zip/Deflater

Il 09/07/2009 18:57, Kelly O'Hair ha scritto: I tend to agree. Shouldn't a zero length entry be treated special, or disallowed? -kto Hi Kelly, Maybe I misunderstood the code, because I didn't went into it in so great details, but I think that the zero length is already considered special b

hg: jdk7/tl/jdk: 6628737: Specification of wrapper class valueOf static factories should require caching

Changeset: ae60bb671e54 Author:darcy Date: 2009-07-09 12:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ae60bb671e54 6628737: Specification of wrapper class valueOf static factories should require caching Reviewed-by: mr ! src/share/classes/java/lang/Byte.java ! src/shar

Re: Code review request for 6628737: Specification of wrapper class valueOf static factories should require caching

Mark Reinhold wrote: Looks fine to me. Minor formatting nit in each delta except the first: ... --- old/src/share/classes/java/lang/Character.java2009-07-08 18:38:13.0 -0700 +++ new/src/share/classes/java/lang/Character.java2009-07-08 18:38:13.0 -0700 @@ -2571,6 +25

Re: patch to address sun bug 6562614

2009/7/9 Jon VanAlten : > Hi, > > I've put up a webrev at > http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/index.html to address > http://bugs.sun.com/view_bug.do?bug_id=6562614, also referenced on Icedtea > bugzilla as http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=289 .   > Com

patch to address sun bug 6562614

Hi, I've put up a webrev at http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/index.html to address http://bugs.sun.com/view_bug.do?bug_id=6562614, also referenced on Icedtea bugzilla as http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=289 . Comments? Concerns? If this is an okay

RE: [concurrency-interest] LinkedBlockingDeque deadlock?

Hi, > The poll()ing thread is blocked waiting for the internal lock, but > there's > no indication of any thread owning that lock. You're using an OpenJDK 6 > build ... can you try JDK7 ? I got a chance to do that today. I downloaded JDK 7 from http://www.java.net/download/jdk7/binaries/jdk-7-ea-

Re: malloc failures in java/util/zip/Deflater

Zero length entry should be allowed. This is a regression, the result of the un-successful fix for 6728376:-( The webrev for 6728376 is http://cr.openjdk.java.net/~sherman/6728376/webrev We have the same in Inflater as well. I will file a bug for it. Thanks Mario for catching this. Sherman K

Re: malloc failures in java/util/zip/Deflater

I tend to agree. Shouldn't a zero length entry be treated special, or disallowed? -kto David Holmes - Sun Microsystems wrote: Hi Mario, I'm not familiar with this particular code but doesn't a value of this_len==0 imply that there's nothing to do and a whole chunk of code here can be skippe