gmane.comp.java.openjdk.core-libs.devel

Re: RFR 8009581: Xpathexception does not honor initcause()

Alan Bateman — 2013-05-25T15:41:50

I think this looks better. I assume that since the super.getCause() is 
null that there is no need to handle IllegalStateException now.

I think the test could be beefed up to cover the 
serialization/de-serialization too (since this is new code and doesn't 
appear to be exercised by other tests).

-Alan

Re: RFR 6303183: Support NTFS and Unix-style timestamps for entriesin Zip files

Alan Bateman — 2013-05-25T15:22:39

I agree, it's good to add this.

The package-info already has a link to APPNOTE.TXT and also the Info-ZIP 
format. However it might be good to at least have ZipEntry.getTime's 
javadoc mention that the time may be coming from extra block. This would 
provide coverage for cases where they don't match.

-Alan.

Re: Time to put a stop to Thread.stop?

Alan Bateman — 2013-05-25T11:35:04

For these the tests then it shouldn't really matter but if you or Doug 
would prefer if they are changed to use sneakyThrow then we can do that.

-Alan.

Re: RFR: 7038105 - File.isHidden() should return true for pagefile.sysand hiberfil.sys

Alan Bateman — 2013-05-25T11:23:49

Sure, that's fine, we've done enough rounds on this.

-Alan

Re: RFR 8009581: Xpathexception does not honor initcause()

Aleksej Efimov — 2013-05-25T08:37:35

David, Jason,
Thank you for your comments and suggestions. They all were taken in 
account and as a result - the new webrev: 
http://cr.openjdk.java.net/~dmeetry/8009581/webrev.2/

On 05/24/2013 08:26 AM, David Holmes wrote:
Agree with that, we want to call the specific 'initCause', not the 
subclass specialization.
Also agree, the ' super.getCause() == null' check added to readObject.

Aleksej

Re: RFR: 8014855: TEST_BUG: java/nio/file/Files/StreamTest.java failswhen sym links not supported

Henry Jen — 2013-05-25T03:44:34


If I didn't misunderstand you, that's implemented in earlier test for walk in this same file. This fix is for SecurityException cases.

Cheers,
Henry

Re: Resync j.u.c and Update ConcurrentHashMap to v8 - JEP 155

Mike Duigou — 2013-05-25T03:17:46

Hi Chris;

There's an awful lot here!

- I found it hard to read the javadoc changes with all of the <tt> -> {< at >code} changes. I made webrev with only the non-<tt> changes:

 http://cr.openjdk.java.net/~mduigou/concurrent.after.tt.code/0/webrev/

- Martin had  pushed the changes for "7178639: Deque.push specifies that it returns a value but the method is void" to Doug's repo. Can we include it?

- It was surprising (and somewhat disappointing) to see changes like the following in various places. Is iterator creation that expensive? I'd hate to have to go back to using old style for loops everywhere.

-        List<Future<T>> futures = new ArrayList<Future<T>>(tasks.size());
+        ArrayList<Future<T>> futures = new ArrayList<Future<T>>(tasks.size());

Why not 'List<Future<T>> futures = new ArrayList<>(tasks.size());' ?

and

-                for (Future<T> f : futures)
-                    f.cancel(true);
+                for (int i = 0, size = futures.size(); i < size; i++)
+                    futures.get

Re: RFR: 8007333: [launcher] removes multiple back slashes / trivialfix

Akhil Arora — 2013-05-25T00:50:10

looks good

On 05/24/2013 04:01 PM, Kumar Srinivasan wrote:

Re: RFR 6303183: Support NTFS and Unix-style timestamps for entriesin Zip files

Xueming Shen — 2013-05-25T00:03:01

This change actually also "partially" fixeds that ZipEntry dos 1980 
epoch bug as well since the
ZipEntry.set/getEntry() no longer do the java<->dos conversion. While 
the time stamp in the
loc/cen time field still stores the dos formatted time stamp (therefor 
still has the 1980 issue),
with the additional Info-ZIP's extra time stamp the ZipEntry from those 
zip file should now have
the time stamp of the "normal" 1970 epoch.

-Sherman

Re: RFR: 8007333: [launcher] removes multiple back slashes / trivialfix

Kumar Srinivasan — 2013-05-24T23:01:01

After some hallway conversation with Akhil, I added some more tests
with progressive number of \ handling, just to make sure, besides that there
are no other changes.

full webrev:
http://cr.openjdk.java.net/~ksrini/8007333/webrev.1/

delta webrev
http://cr.openjdk.java.net/~ksrini/8007333/webrev.1/webrev.delta/index.html

If there are no more comments I will push this by Tuesday.

Thanks
Kumar

Re: RFR JDK-8001750: CharsetDecoder.replacement should not bechangeable except via replaceWith method

Martin Buchholz — 2013-05-24T22:57:55

Looks good.


On Fri, May 24, 2013 at 11:53 AM, Xueming Shen <xueming.shen-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org>wrote:

Re: RFR 6303183: Support NTFS and Unix-style timestamps for entriesin Zip files

Martin Buchholz — 2013-05-24T22:53:39

Thanks very much for adding this support.  Users will be happy.

You could make it clearer in the javadoc that you are storing and returning
times in seconds since the epoch, and that the epoch is Jan 1, 1980.

Note that we now have both kinds of epochs: 1970 and 1980, for extra
confusion.
Also, I guess the zip world doesn't have any kind of year 2038 strategy?
 Probably roll over as we get close to 2038 and pray?

Probably include links to both appnotes, the pkware one and info-zip's
modified version.



On Fri, May 24, 2013 at 12:22 PM, Xueming Shen <xueming.shen-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org>wrote:

RFR 8015402 -- lambda metafactory simplifications

Brian Goetz — 2013-05-24T20:29:14

The following webrev describes changes to the lambda metafactory enabled 
by the compiler generating bridge methods in interfaces, and therefore 
the metafactory need not try and guess which other methods should be 
bridged to the main SAM method.  The compiler can optionally generate a 
specific list of alternate signatures to be bridged.

   http://cr.openjdk.java.net/~briangoetz/JDK-8015402

Re: RFR: 7038105 - File.isHidden() should return true for pagefile.sysand hiberfil.sys

Rob McKenna — 2013-05-24T20:24:04

Will do Alan, thanks. If its ok I'll just do this with the push as 
opposed to posting another review.

     -Rob

On 24/05/13 18:06, Alan Bateman wrote:

RFR 6303183: Support NTFS and Unix-style timestamps for entries inZip files

Xueming Shen — 2013-05-24T19:22:04

I'm trying to address the following two issues

6303183: Support NTFS and Unix-style timestamps for entries in Zip files
7012868: (zipfs) file times of entry in zipfs should always be the same regardless of TimeZone.

which mainly is about the "mtime" field in both loc and cen tables are dos format,
(it means the default time stamp of a zip entry is 2-second granularity time stamp
and timezone sensitive (the time is interpreted  as the "local time" of the timezone
the system is running on, it does not count the time zone difference)

The proposed change here is to

(1) add a Info-ZIP timestamp in entry's extra data (like zip/unzip does), which uses
typical "unix style" second granularity time stamp and is in UTC/GMT timezone

(2) change the ZipEntry.time (renamed to mtime) to be the new unix-style-second
granularity/UTC time, instead of the current "dos style-2-second granularity and
local-time" time stamp, so the set/getTime() can just do the set/get directly without
conversion, however the ZipIn/OutputStr

Re: Time to put a stop to Thread.stop?

Doug Lea — 2013-05-24T18:58:28


This was initially done when the unchecked-throw was via
Unsafe.throwException, needed only in those cases.
But then we switched to using sneaky-throw, relying on
the same javac type-check limitation everyone else relies on
these days. Which makes it more portable across JVMs, but could in
theory stop working someday. But until then,
those checks aren't needed and can/should go away.

-Doug

RFR JDK-8001750: CharsetDecoder.replacement should not be changeableexcept via replaceWith method

Xueming Shen — 2013-05-24T18:53:15

Hi,

Please help review the change for

JDK-8001750: CharsetDecoder.replacement should not be changeable except via replaceWith method

http://cr.openjdk.java.net/~sherman/8001750/webrev/

The bug description is actually not accurate, the replacement field
of CharsetDecoder class is String, not a byte[], so CharsetDecoder
does not have the "defensive copy" issue described. CharsetEncoder
class however appears to have this issue (replacementWith() and
replacement() don't make defensive copy when set/get its internal
data field), which has the byte[] type replacement.

The change is to
(1) return a copy of the replacement when replacement() is invoked
(2) save a defensive copy of the new replacement when set via
     replacementWith()

To return a defensive copy of replacement from replacement() may
trigger minor  performance "regression" when internal interface
ArrayEncoder.encode() is invoked (from StringCoding and ZipCoder),
so some corresponding updates in UTF8, DoubleByte and HKSCS clases
to save copy of

hg: jdk8/tl/langtools: 8014836: Have GenericDeclaration extendAnnotatedElement

2013-05-24T18:26:28

Changeset: 0f8e9a0e5d9a
Author:    darcy
Date:      2013-05-24 11:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0f8e9a0e5d9a

8014836: Have GenericDeclaration extend AnnotatedElement
Reviewed-by: jfranck

! src/share/sample/language/model/CoreReflectionFactory.java

Re: Time to put a stop to Thread.stop?

Martin Buchholz — 2013-05-24T18:14:43


Alan, you're telling everyone there's no need for Thread.stop, but you are
replacing usages in tests with calls to Unsafe, which is not available to
normal code.  So you have a kind of moral obligation here to replace usages
with "ordinary" java code.  There are other ways to do sneakyThrow, and
perhaps a sneakyRethrow method should be added to the jdk test library.

Ordinary java code should be able to simply catch and rethrow a Throwable
if type analysis can "prove" that the exception is not an Exception.

As a data point, Doug uses this:

(Doug, it's not obvious to me why you handle Error and RuntimeException
specially)

    /**
     * A version of "sneaky throw" to relay exceptions
     */
    static void rethrow(final Throwable ex) {
        if (ex != null) {
            if (ex instanceof Error)
                throw (Error)ex;
            if (ex instanceof RuntimeException)
                throw (RuntimeException)ex;
            ForkJoinTask.<RuntimeException>uncheckedThrow(ex);
        }
    }

Re: Time to put a stop to Thread.stop?

Mike Duigou — 2013-05-24T17:46:32

I wonder if perhaps the the NPE check on the passed exception and the security permission check should be retained.

I am otherwise fine with Thread.stop(Throwable) unconditionally throwing UOE.

Mike

On May 24 2013, at 06:18 , Alan Bateman wrote:

Re: Time to put a stop to Thread.stop?

Joe Darcy — 2013-05-24T17:31:43

Looks good Alan and good riddance to Thread.stop(Throwable)!

-Joe

On 05/24/2013 06:18 AM, Alan Bateman wrote: