Re: Impossible (?) code path resulting in IllegalStateException on jdk14+

> <mailto:david.hol...@oracle.com>> wrote: > > > > Hi Dawid, > > > > This appears to be a bug in AbstractQueuedSynchronizer and FJP > > interaction, so cc'ing core-libs as this is not a hotspot issue. Also > >

Re: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

> The ZipFileSystem check is case sensitive: > Ah, that's not obvious at all... and even if this is an undocumented option I'd add a comment in the test or remove it to Map.of() for clarity. That bug entry in Jira doesn't have "affects" pointing at older releases - I think it should since it

Re: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

ot;zipinfo-time", "False"))) { Anyway, the problem is fixed. I think it'd be good to backport to LTS releases too. Dawid On Sat, Nov 28, 2020 at 4:32 PM Lance Andersen wrote: > Hi Dawid, > > Thank you for the follow up. > > On Nov 28, 2020, at 9:34 AM, Dawid Weiss

Re: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

se submit a patch along with a JTREG > test case. Ideally the test case would create zip file as part of the test. > > Best > Lance > > On Nov 27, 2020, at 7:37 AM, Dawid Weiss wrote: > > Just for the archives - I'm not sure if this ended up being filed to > the bug system -

Re: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

lazily after all extra data blocks are parsed to ensure the file offset is correctly updated based on block ID 0x0001, regardless of its ordering within other extra data blocks. On Fri, Oct 23, 2020 at 9:12 AM Dawid Weiss wrote: > > > This looks like a legitimate bug to me (the zip file

Re: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

, Oct 21, 2020 at 8:36 PM Dawid Weiss wrote: > Hi Lance, > > Yes, this is exactly the point where the problem is in JDK code. It's > directly > related to the zip entry beyond max int offset. The code tries to read data > from a local zip entry header at locoff, here: > > if (

Re: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

tted. (Creation time may be > present without access time, for example.) TSize should equal > (1 + 4*(number of set bits in Flags)), as the block is currently > defined. Other timestamps may be added in the future. > > > -- > >

"loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

Hello, We've encountered a seemingly valid ZIP file (zipinfo -v shows all its entries are intact) that causes a runtime exception when scanning its contents with ZipFileSystem. The exception indicates an invalid signature when parsing EXTID_EXTT. I don't quite understand this comment in the code:

Re: BiCollector

Not that it's an important factor but as a non-native English speaker I like the simplest form of "toBoth()" best. I also doubt there will ever be a "Both" class in the JDK to worry about, even if such examples can be found in the wild [1]. Dawid [1]

Inflater nowrap and padding byte requirement

Hello, The javadoc for Inflater states that: * Note: When using the 'nowrap' option it is also necessary to provide * an extra "dummy" byte as input. This is required by the ZLIB native * library in order to support certain optimizations. This doesn't seem to be a requirement

Re: AssertionError in WildcardTypeImpl.getUpperBoundASTs

openjdk.java.net/projects/jdk8u/releases/8u162.html > [2] https://bugs.openjdk.java.net/browse/JDK-8065172 > > > On 10/17/17 12:41, Dawid Weiss wrote: > > Hi Peter, > > Thanks for the pointer. Whether or not this fix should be backported > to 8u is probably not for me

Re: Random.nextLong(long bound)?

Hi Steven, > We were hoping to have a single sequence shared between the library that > takes Random and our > own code that hopes to generate bounded longs. We want such tight control > because we are writing > a repeatable tester and want to use the seed to be able to replay sequences >

Re: AssertionError in WildcardTypeImpl.getUpperBoundASTs

; JDK 9: > > https://bugs.openjdk.java.net/browse/JDK-8065172 > > ...but it seems this has not been backported to 8u (yet). The question is, > will there be any more 8u releases? Would you like this to be backported to > 8u? > > Regards, Peter > > > On 10/13/2017

AssertionError in WildcardTypeImpl.getUpperBoundASTs

Hi all, We are observing very infrequent assertion errors originating in getUpperBoundASTs, mostly during concurrent builds on our build machine, when it's under a heavy load. This has been happening from time to time with various Java versions; most recently with 1.8.0_131. I don't see anything

Re: RFR [9] 8178101: Migrate the thread deprecation technote to javadoc doc-files

While applying this patch, you could probably piggyback a fix to this typo as well: "Cleanup would have to [be] repeated" Dawid On Wed, Apr 5, 2017 at 11:08 AM, Chris Hegarty wrote: > As part of the ongoing doc cleanup effort, we should move the existing >

Re: RFC: System.console().encoding()

> out of curiosity... what will you do if you find the encoding lacking what > you need? Oh, display a warning. Helps to figure out where those "???" characters are coming from... Naive, I know. But it's the best one can do and it works (most of the time). D.

Re: RFC: System.console().encoding()

+1 for adding a public Console.encoding(). I remember needing it as well, the current hacks are very ugly. Dawid On Thu, Sep 15, 2016 at 8:42 AM, Aleksey Shipilev wrote: > Hi, > > Claes pointed out that our own reflective hacks to figure out console > encoding do not work

Typo in internal Javadoc of Pattern.Bound

Probably not worth a pull request -- somebody can piggyback on another change. diff -r ff7d1c47fef8 src/java.base/share/classes/java/util/regex/Pattern.java --- a/src/java.base/share/classes/java/util/regex/Pattern.java Thu Jul 07 19:00:10 2016 + +++

Re: toRealPath throws InternalError: Should not get here on Windows (paths with junctions)

2016 at 1:56 PM, Rory O'Donnell <rory.odonn...@oracle.com> wrote: > Hi Dawid, > > I will update bug. > > Rgds,Rory > > > On 15/03/2016 12:53, Dawid Weiss wrote: >> >> This must be more complicated than I thought because the same code >> passes with

Re: toRealPath throws InternalError: Should not get here on Windows (paths with junctions)

on the eventual Jira issue would be sensible (can't do it myself, no Jira access). Dawid On Tue, Mar 15, 2016 at 1:01 PM, Dawid Weiss <dawid.we...@gmail.com> wrote: > I filed an issue (Review ID: JI-9032181). In any case, I checked with > Java 7, 8 and the ea: > > Java(TM) SE Runtime Environ

Re: toRealPath throws InternalError: Should not get here on Windows (paths with junctions)

n Bateman <alan.bate...@oracle.com> wrote: > On 15/03/2016 11:19, Dawid Weiss wrote: >> >> I couldn't find an appropriate bug in bugzilla, but this fails >> reliably for me with Java 8 and 9 on Windows 10, 64-bit: >> >> mkdir foo >> mklink /J bar fo

toRealPath throws InternalError: Should not get here on Windows (paths with junctions)

I couldn't find an appropriate bug in bugzilla, but this fails reliably for me with Java 8 and 9 on Windows 10, 64-bit: mkdir foo mklink /J bar foo cd bar java -cp Test . where Test.java is as simple as: import java.io.*; import java.nio.file.*; public class Test { public static void

Re: Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application

A @Discouraged(String seeAlternative) annotation? This also applies to things like Vector or Hashtable (which arguably have a slightly different semantics from ArrayList or HashMap, but if somebody uses them it's very likely a mistake). This reminds me of the work Uwe Schindler did with his

Re: JDK 9 RFR of JDK-7130085 Port fdlibm hypot to Java

Not that I understand the math behind it, but out of curiosity I looked and spotted a typo in: > muti-precision (unless it's some kind of complex IEEE-approved jargon for something I have no idea about :). Dawid On Tue, Sep 22, 2015 at 3:22 AM, Joseph D. Darcy wrote: >

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

> there're already ways to bring down the JVM (e.g. JNI, existing Unsafe usage, > etc), If you can somehow pass switches to the JVM, this one wins my personal beauty contest (from globals.hpp): product(intx, SelfDestructTimer, 0, \ "Will cause VM

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

> - you track the number of mapped buffers (or mapped address space) that you > "know" is active in the application manually. The problem is you really can't do it on a global, JVM-scale, Peter. It's enough that the same JVM process starts two isolated class loaders with Lucene in each and such

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

> I think it would be best to leave to the application to decide and > implement the tracking and also triggering GC at times when it approaches > the limit. I disagree. The GC -- when and how it is triggered -- should be transparent to the application. We don't want to manage GC, we want to

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

> Because the reason users are working around this is Windows, where they > need the ability to do: > > buffer.unmap(); > file.delete(); This is exactly the case in Lucene, for example. Which currently resorts to ugly hacks (the entire documentation of this class is interesting -- concerns memory

Re: setOut() and redirectOutput() together

Your code makes the native app inherit native stdout/err process descriptors, you need to pipe the output from your native app to Java and then redirect the output to wherever you wish (byte array for example). In other words, Redirect.PIPE + pipe code. Dawid On Thu, May 28, 2015 at 12:43 PM,

Re: PriorityQueue

You may have trouble finding someone with the same enthusiasm for this constructor as yourself. This probably applies to many data structures that have specific (and rare) applications. A priority queue that takes a custom comparator seems like a pretty frequent (algorithmic) use case to me,

Inconsistent access/ synchronization on Authenticator.theAuthenticator

This is very minor, but java.net.Authenticator has the following static field for the default authenticator: private static Authenticator theAuthenticator; This field is set from a synchronized method setDefault(..), but accessed without proper sync from all other request* methods:

Re: Inconsistent access/ synchronization on Authenticator.theAuthenticator

at 11:28 AM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: On 11/17/2014 12:56 PM, Dawid Weiss wrote: This is very minor, but java.net.Authenticator has the following static field for the default authenticator: private static Authenticator theAuthenticator; This field is set from

Re: RFR (XS) 8065096: java.net.Authenticator.theAuthenticator should be properly synchronized

Hey, all of you guys... this must be the fastest turnaround ever! Thanks a lot, very much appreciated (even if it wasn't that crucial, only something I accidentally spotted in the code). Dawid On Mon, Nov 17, 2014 at 5:26 PM, Claes Redestad claes.redes...@oracle.com wrote: On 11/17/2014 01:31

Re: Simple RFR: 8203311 Clean up profile-includes.txt

David, Is the fix for this committed anywhere? I've just tried building from scratch and I'm getting the same error. Dawid On Wed, Aug 21, 2013 at 10:55 AM, David Holmes david.hol...@oracle.com wrote: Fix on the way. This exposed another piece that was missing from the original change. But

Re: Simple RFR: 8203311 Clean up profile-includes.txt

:dholmes Date: 2013-08-21 05:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b8fed46b2a8 8023460: OPENJDK build fails due to missing jfr.jar Reviewed-by: alanb ! makefiles/Profiles.gmk On 28.08.13 11:44, Dawid Weiss wrote: David, Is the fix for this committed anywhere

Re: forEach on HashMap and IdentityHashMap

default void forEach(BiConsumer? super K, ? super V sink) { It would be nice to specify it as in here: http://labs.carrotsearch.com/download/hppc/0.4.1/api/com/carrotsearch/hppc/ObjectObjectOpenHashMap.html#forEach(T) public T extends BiConsumer? super K,? super V T forEach(T sink) funny as

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

PS - It would be great if this were standard practice in these discussions - perhaps someone can sponsor a summer of code project to set it up. I've created an issue on MVNCENTRAL (https://issues.sonatype.org/browse/MVNCENTRAL-320) -- wondering if there's a (legal and clean) way to get all that

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

Hello everyone, To contribute to the discussion concerning Thread.stop(*) and its usefulness. I've implemented a JUnit test runner for Lucene/ Solr and we needed test suite isolation badly but at the same time wanted to reuse the same JVM (for performance reasons). The initial implementation

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

We have JEP 102 to update Process. Some of the low hanging fruit, like Process.destroyForcibly, went into jdk8 so they have been removed from the JEP. Thanks for the pointer, Alan. I fully agree with the rationale: Long-standing shortcoming in the platform [...] Long requested by developers.

Process.exec() hung on Windows, how to tell what happened from dmp file?

Hi everyone, Seems like the right list to ask, but redirect me if there's a better place, please. I have a Java process that forks a process and waits for it. When repeatedly running on: Windows (64 bit) java version 1.7.0_05 Java(TM) SE Runtime Environment (build 1.7.0_05-b05) Java HotSpot(TM)

Re: A bug in filesystem bootstrap (unix/ linux) prevents

. file.encoding is supposed to be a read-only informative system property. -Sherman On 7/4/2012 1:21 PM, Dawid Weiss wrote: There is a similar bug: Bug 6795536 - No system start for file.encoding=x-SJIS_0213 Yeah... I looked at the sources in that package and there is at least one more place

Re: A bug in filesystem bootstrap (unix/ linux) prevents

own, it might work, it might not work. On 7/4/2012 11:00 PM, Dawid Weiss wrote: Well, what's the right way to enforce an initial encoding for charset-less string-to-byte conversions and legacy streams? I still think that snippet of code is buggy, no matter if file.encoding is or isn't

Re: A bug in filesystem bootstrap (unix/ linux) prevents

export LC_ALL=en_US.UTF-8; java Foo Not really, the shell won't let you use a multibyte locale (because of issues with null-terminated strings). And multibyte (with BOM) is most fun when you're trying to find buggy code ;) I would assume there is no en_US.UTF-16 locale there :-) I wish there

A bug in filesystem bootstrap (unix/ linux) prevents

Hi folks. Run the following with -Dfile.encoding=UTF-16: public class TestBlah { public static void main(String []) throws Exception { TimeZone.getDefault(); } } This on linux (and any unixish system I think) will result in: java.lang.ExceptionInInitializerError at

Re: A bug in filesystem bootstrap (unix/ linux) prevents

for this is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181721 Dawid In this case on Windows. -Ulf Am 04.07.2012 14:43, schrieb Dawid Weiss: Hi folks. Run the following with -Dfile.encoding=UTF-16: public class TestBlah { public static void main(String []) throws Exception

Re: Empty regexp replaceall and surrogate pairs results in corrupted utf16.

it as a zero-with character boundary, therefor a position in between a pair surrogates is still a good found for replacing. -Sherman On 6/7/2012 1:07 PM, Dawid Weiss wrote: Hi, I'm a committer to the Apache Lucene project. We have randomized tests and one seed hit the following (simplified

Empty regexp replaceall and surrogate pairs results in corrupted utf16.

Hi, I'm a committer to the Apache Lucene project. We have randomized tests and one seed hit the following (simplified) scenario: String s1 = AB\uD840\uDC00C; String s2 = s1.replaceAll(, X); the input contains an extended unicode character (any surrogate pair will do). The pattern is an