The Right Thing is to have only one C Zip implementation, shared by
launcher, zip_util, and pack200. And my change is one step towards that,
but I'm not tackling the big job right now.
On Wed, Mar 25, 2015 at 10:55 AM, Xueming Shen
wrote:
>
> It looks fine...I hope you guys also have some tests
Thanks all.
(I'm a picky reviewer myself, but sometimes I also approve changes that I
think are "Meh")
On Tue, Mar 24, 2015 at 1:04 AM, David Holmes
wrote:
> On 24/03/2015 5:55 PM, Paul Sandoz wrote:
>
>> On Mar 24, 2015, at 12:27 AM, John Rose wrote:
>>
>>> Meanwhile, Paul Sandoz is working t
On 03/25/2015 04:58 PM, Chris Hegarty wrote:
On 25 Mar 2015, at 17:32, Peter Levart wrote:
On 03/25/2015 05:55 PM, Peter Levart wrote:
On 03/25/2015 04:49 PM, Chris Hegarty wrote:
I have been thinking about this and I see several solutions:
1. provide protected final methods
ObjectInputStr
> On 25 Mar 2015, at 17:32, Peter Levart wrote:
>
> On 03/25/2015 05:55 PM, Peter Levart wrote:
>> On 03/25/2015 04:49 PM, Chris Hegarty wrote:
I have been thinking about this and I see several solutions:
1. provide protected final methods
ObjectInputStream.checkPersistentFi
Looks like only 32-bit is affected. Both Server (C2) and Client (C1) VMs.
64-bit VM pass all combinations: Tiered, C2 only (-TieredCompilation),
C1 only (-XX:+TieredCompilation -XX:TieredStopAtLevel=1) with and
without intrinsics.
32-bit Client VM (C1) fails with both, -XX:-UseUnalignedAccess
It looks fine...I hope you guys also have some tests over there to bring
in more confidence :-)
It might be "easier" to simply update the original haveZIP64() with the code
we have in zip_util.c in which we also try to read the end64 to verify if we
really have one. Your choice though.
-Sherman
On 03/25/2015 05:55 PM, Peter Levart wrote:
On 03/25/2015 04:49 PM, Chris Hegarty wrote:
I have been thinking about this and I see several solutions:
1. provide protected final methods
ObjectInputStream.checkPersistentFinalsNotSet() and
markPersistentFinalsSet() that just delegate to FieldSette
On 03/25/2015 04:49 PM, Chris Hegarty wrote:
I have been thinking about this and I see several solutions:
1. provide protected final methods
ObjectInputStream.checkPersistentFinalsNotSet() and
markPersistentFinalsSet() that just delegate to FieldSetterContext for
ObjectInputStream classes to cal
Yeah, this review is kinda scary. There's a lot of technical debt here,
and this change only addresses some of it.
A variant of this code is in use at Google.
On Mon, Mar 23, 2015 at 1:18 PM, Martin Buchholz
wrote:
> Hi Xueming and Alan,
>
> I'd like you to do a code review.
>
> https://bugs.o
Hi Peter,
I'll remove the synchronization ... I think your right there should
only be a single thread of control executing
in a particular instance . Based on your prompt I ran a concurrent
invocation test on the same remote reference and didn't
observe any conflict - separate IIOPOutputStr
On 03/25/2015 04:49 PM, Chris Hegarty wrote:
Peter,
On 25/03/15 12:24, Peter Levart wrote:
On 03/23/2015 04:45 PM, Chris Hegarty wrote:
Here is an updated version of the FieldSetter API, with all comments
to date incorporated.
http://cr.openjdk.java.net/~chegar/8071472/02/specdiff/overview-s
Hi Pavel,
Looks fine.
Roger
On 3/25/2015 11:53 AM, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8075959
http://cr.openjdk.java.net/~prappo/8075959/webrev.00/
-Pavel
On 24/03/15 19:25, Martin Buchholz wrote:
On Tue, Mar 24, 2015 at 7:42 AM, Chris Hegarty mailto:chris.hega...@oracle.com>> wrote:
3) "process reaper”, maybe
“Process-Reaper-“ + monotonically increasing ID ( similar to
ForkJoin worker threads, or other ). But I do accept
Hi everyone,
Could you please review my change for JDK-8075959
http://cr.openjdk.java.net/~prappo/8075959/webrev.00/
-Pavel
Peter,
On 25/03/15 12:24, Peter Levart wrote:
On 03/23/2015 04:45 PM, Chris Hegarty wrote:
Here is an updated version of the FieldSetter API, with all comments
to date incorporated.
http://cr.openjdk.java.net/~chegar/8071472/02/specdiff/overview-summary.html
Final spec comments welcome, aft
On 3/25/2015 2:51 AM, mikhail cherkasov wrote:
On 3/25/2015 1:48 AM, Kumar Srinivasan wrote:
Hi Mikhail,
Nit:
Utils.java:
-// reset timezone when all the packers have terminated
+// reset timezone when all the packer/unpacker instances have
terminated
fixed: http://cr
On Tuesday 10 March 2015 17:18:06 Stanislav Baiduzhyi wrote:
> Hi All,
>
> Please review the patch for LdapURL. Patch fixes the parsing of query part
> of LDAP URL, leaving empty optional fields as null instead of "".
>
> Webrev:
> http://goo.gl/OO0V38
>
> Bug:
> https://bugs.openjdk.java.net/br
No, I don't think there's any legitimate use case for allowing
readObject to skip reading fields or to read fields while or after
reading data (and the same goes for writeObject). However this doesn't
change the fact that the JDK contains several classes which do exactly
this, many third-party
Thank you Joe !
/Amy
On 3/25/15 12:13 PM, huizhe wang wrote:
Ok, I pushed your change.
Thanks,
Joe
On 3/24/2015 6:20 PM, Amy Lu wrote:
Hi, Joe
Without this fix, jaxp test run in JPRT will fail because it try to
use jtreg/win32/bin/jtreg
Thanks,
Amy
On 3/25/15 2:18 AM, huizhe wang wrote:
On 03/23/2015 04:45 PM, Chris Hegarty wrote:
Here is an updated version of the FieldSetter API, with all comments
to date incorporated.
http://cr.openjdk.java.net/~chegar/8071472/02/specdiff/overview-summary.html
Final spec comments welcome, after which I intend to submit a CCC
request.
On 24/03/2015 16:07, Chris Hegarty wrote:
Thanks for the feedback Alan.
:
Updated:
http://cr.openjdk.java.net/~chegar/8071472/03/specdiff/
-Chris.
I think this looks good now.
-Alan
On 25/03/15 00:05, Martin Buchholz wrote:
How about this, which resurrects the jdk7 doc strings for the legacy fields?
That is fine with me, and similar to what I had at one point. I just
wasn't sure if you wanted to stuff the descriptions back in. If they are
still valid, then it is the best
Thanks for the review Jason!
On 24/03/15 18:01, Jason Mehrens wrote:
Hi Daniel,
Looks good. The only other alternative would be to use
java.io.CharConversionException over IOException. We could even consider
dropping the cause because the subclass of I/O exception would convey the same
mea
On 3/25/2015 1:48 AM, Kumar Srinivasan wrote:
Hi Mikhail,
Nit:
Utils.java:
-// reset timezone when all the packers have terminated
+// reset timezone when all the packer/unpacker instances have
terminated
fixed: http://cr.openjdk.java.net/~mcherkas/8066985/webrev.03/
Hi, Joe and All
We are working on moving internal jaxp functional tests to open jdk repo.
This is the dom suite. Would you please review these test? Any comment will
be appreciated.
bug: https://bugs.openjdk.java.net/browse/JDK-8051559
webrev: http://cr.openjdk.java.net/~fyuan/8051559/we
Hi, Joe and All
We are working on moving internal jaxp functional tests to open jdk repo.
This is the astro suite. Would you please review these test? Any comment
will be appreciated.
bug: https://bugs.openjdk.java.net/browse/JDK-8051560
webrev: http://cr.openjdk.java.net/~fyuan/8051560/
On 24/03/15 23:40, Vladimir Kozlov wrote:
> The test failed when run it in JPRT with 32-bit fastdebug *Client* VM
> (-client) on linux-x86:
>
> java.lang.RuntimeException
> at MyByteBuffer.ck(HeapByteBufferTest.java:201)
> at MyByteBuffer.getLong(HeapByteBufferTest.java:211)
>
27 matches
Mail list logo
