Re: Proposal for new public class: java.io.CharSequenceReader

Markus Karg schrieb am 28.09.2024 18:15 (GMT +02:00): > Dear Sirs, > for performance reasons, hereby I like to propose the new public class > java.io.CharSequenceReader > I like the idea and missed it in the past. while we are at it, also support a char[] constructor (since this char[] does n

jpackage nits

Hello, I noticed some jpackage pecularities: 1 - if you use "-i ." (and no target) it will not ignore its target directory and recursively copy itself generating a massive deep directory tree hard to remove. Sample command: jpackage --type app-image -n MyApp --main-class myapp.Main --main-ja

Re: want to try out small idea; where is the implementing class for Stream interface?

t; the > implementing classes. > For instance, where is this implemented? > > T reduce(T identity, BinaryOperator accumulator); > > > > On Sun, Jul 21, 2024, 1:52 AM Bernd Eckenfels > wrote: > >> Anil wrote on 21. July 2024 04:44 (GMT +02:00): >> > How

Re: want to try out small idea; where is the implementing class for Stream interface?

Anil wrote on 21. July 2024 04:44 (GMT +02:00): > However, I am unable to find the implementing class of java.util.Stream. You find the package in Java.base module: https://github.com/openjdk/jdk/tree/master/src/java.base/share/classes/java/util/stream Gruß Bernd — https://bernd.eckenfels.net

Re: Status of ZIP64 InputStream bug JDK-8298530?

Hello Archie, Archie Cobbs wrote on 09.05.2024 20:09 (GMT +02:00): FWIW when I run the test case in that bug on the latest JDK 23 (jdk-23+21-110-g0a4eeeaa3c6), it does not report any exception. So this bug may have gotten fixed by recent changes and just needs to be closed... ? Interesting ob

Status of ZIP64 InputStream bug JDK-8298530?

Hello, I remember to have seen a few ZIP64 compatibility bug fixed in the past. But this one here is still open: * [JDK-8298530] ZipInputStream.readEnd fails for certain ZIP64 archives with small files - Java Bug System (openjdk.org) There seem to be unofficial patches. We seem to be bothered by th

Usage of iconv()

Du to a glibc security alert about a charset in iconv() I checked OpenJDK (since I was quite sure encoding is handled in JCL), however there are a few utilities (related to libinstrument and splash Screens) which use iconv. If I see it correctly it’s mostly used for utf8 so it should not expose

Re: InetAddress API extension proposal

Would be helpful to point to the posix standard/requirement which mandates this. Do you mean a single Unix api description or a posix command spec? I don’t think I know of any such things. Wikipedia claims A POSIX-conforming variant of inet_aton, the inet_pton() function, supports only the four

Re: reducing the size of multi-architecture applications

Alan Snyder wrote on 7. Mar 2024 22:39 (GMT +01:00): > That could be done, but it would require more work with no obvious > benefit. > > Only the Java launcher needs to be universal from the perspective of the > OS. it’s however not only the exetables. You have also the shared libraries, possib

Re: RFR: 8293197: Avoid double racy reads from non-volatile fields in SharedSecrets

BTW, after then ensures it looks like a good candidate for a system-assert for not-null for all of those fields, right? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Andrey Turbanov Gesendet: Thursday, September 1, 2022 8:24:58 AM

Re: Case Insensitive DateFormatSymbols for parsing

/DateTimeFormatterBuilder.html#parseCaseInsensitive() Regards, Roger On 7/15/22 8:17 AM, Bernd Eckenfels wrote: Hello, I noticed that it is surprisingly hard to make SimpleDateFormat accept all-uppercase month names while parsing. Even with a custom DateFormatSymbols that’s hard because you can

Case Insensitive DateFormatSymbols for parsing

Hello, I noticed that it is surprisingly hard to make SimpleDateFormat accept all-uppercase month names while parsing. Even with a custom DateFormatSymbols that’s hard because you can only specify a single symbol for a month name. For parsing it would be good if you can either specify a list of

XMLOutputFactory REUSE_INSTANCE property defaults to true

The XMLOutputFactoryImpl does not allow to share the writer instances: https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.xml/share/classes/com/sun/xml/internal/stream/XMLOutputFactoryImpl.java#L167 So this is initialized and set to false: https://github.com/op

Re: ArrayList grow method optimization and documentation improvement

I think it means for the zero case it should not use the else part if it has not the default sizing, since somebody might have created it with a specific size. Not sure if it matters much either way. -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag v

Re: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets

And also there is no reason why db drivers or host connectors should not ship their own charset support (Oracle JDBC for example had nls_charset addons. My employer also ship a custom EBCDIC encoding which includes some compatibility hacks, and that took some effort to adopt it to the missing ex

Re: Inconsistencies in the return value (type) of string functions toLower() and toUpper().

Since Sting instances are immutable Idendity should not matter and It is wrong in most cases to rely on string Idendity (==) and the APIs are intentionally not making any assertions about Idendity and/or interning of strings (also the most efficient implementation would not return a new instance