2020 at 6:28 PM David Holmes > <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
> 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 affec
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 We
a a fix, please 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
&g
evaluated 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 zi
id
On Wed, 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:
of times may be omitted. (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.
>
>
> ---
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:
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] https://github.com/search?q=filename%3ABoth.ja
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 anym
//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 to decide... but
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
> that
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
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
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
> longstanding note on "Thread Primitive
> 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.
> Console is supposed to be a "char/String" based class, "encoding" really
> should have no business here in its api.
While I agree with your concerns about the functional side of the API,
I disagree about this method having no practical use. I can give you a
concrete example. The use case that we
+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 anymore [1]. But, we ne
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 +
+++ b/src/java.base/share/classes/java/util/re
e, Mar 15, 2016 at 1:56 PM, Rory O'Donnell
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 flying colors on a
ent 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 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 Environment (build
&
eman 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 foo
>> cd bar
>>
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 main(Str
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 "forbi
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:
> Hello,
>
> Please review
> 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 t
> - 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 ac
> 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
(trul
> 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
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, We
> 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,
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
wrote:
> On 11/17/2014 01:31 PM, Aleksey Shipilev wrote
Nov 17, 2014 at 11:28 AM, Aleksey Shipilev
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 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:
Authentic
3b8fed46b2a8
> Author: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.1
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 wrote:
> Fix on the way. This exposed another piece that was missing from the
> original change. But mea culpa for not doing
> default void forEach(BiConsumer 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 forEach(T sink)
funny as it looks, it allows the caller to create an anonymous class
> 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 tha
> 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 develope
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 work
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
> 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 ther
stemClass() got burned here and there
> in the past:-) So sometime you want to ask if it is worth the risk to
> change
> something work for a use scenario that is not "supported". That said, as
> I said above, something might be done to address this issue, but obviously
> not a prio
ation. 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...
bug ID 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
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 java.nio.file
; possible zero-width
> position of the target String, it does not imply anything regarding
> "character" or
> "characters" around it, so I would not interpret it as a zero-with character
> boundary,
> therefor a "position" in between a pair surrogates
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 a
48 matches
Mail list logo
