Re: Some possible enhancements for java.time.Duration?
On 6/15/21 10:15 AM, dfranken@gmail.com wrote: Dear readers, I think java.time.Duration is a pretty useful class and after having to work a lot with it, I recognized there might be some enhancements we could make (where 'enhancement' is a subjective term of course). For instance: Comparison -- boolean isGreaterThan(Duration duration) / isLongerThan(..) boolean isSmallerThan(Duration duration) / isShorterThan(..) English is not my primary language so I don't know which of these aliases would be better. Given that classes such as Instant and OffsetDateTime also have comparison methods (isAfter, isBefore), I think it would be useful if Duration had easy comparison methods. Of course we have compareTo(..) but I always get confused what it actually means when I get a positive or negative number. :) A small tip when using compareTo, don´t think about the numbers but the operation. Always compare to 0 object1.compareTo(object2) > 0 ==> object1 > object2 You only change the comparison operator, and it always means object1 object2 More comparison --- static Duration max(Duration d1, Duration d2) static Duration min(Duration d1, Duration d2) Returns the longest resp. shortest of the two durations, where negative durations are shorter than positive durations. Side note: I have not found an easy method to obtain the max resp. min values of elements which implement Comparable, I could only come up with something like: Stream.of(Duration.ZERO, Duration.ofSeconds(1L)) .max/min(Comparator.naturalOrder()) .orElse(null); It could be worthwile to add generic methods such as public static > T max(T... elements) public static > T min(T... elements) in the Comparator class. Disallowing negative value -- Okay, this one is a bit more farfetched, but a method which would be useful for my use case is to have an alternative of between() which is never negative and just truncates to zero if it happens to be negative. I'm measuring a duration between timestamps which come from different systems which should be in sync with their NTP servers (and each other), but there may still be some time dilation which could lead to weird results making it look like the effect happened before the cause. So I could see some use for a method like: Duration positiveOrZero() Kind regards, Dave Franken
Re: Java records used in enums
On 5/21/21 10:28 AM, Kasper Nielsen wrote: On Fri, 21 May 2021 at 14:51, Alberto Otero Rodríguez wrote: Hi, I think enums in Java should be immutable. When you let the programmer change values in an enum instance, an unexpected behaviour can happen when using multiple threads as enum instances are static (singleton). So, I was wondering why not make enums instances be defined as records instead of normal classes. Lots of reasons, for example: * It would be a breaking change for an almost non-existent problem. * All internal state of enums would now be public. * Enum's extend java.lang.Enum, records extend java.lang.Record. java.lang.Enum cannot extend java.lang.Record because it has instance fields. /Kasper I could add that making enum records would not solve the proposed "problem" because records are shallowly immutable. I am sure that theoretically, simple enum implementations could be treated by the JIT internally as simple indexes as an optimization, I don't know if it does something like that already. So I don't think records will bring any improvement to enums
DataInputStream readUTF related field initialization
Greetings. DataInputStream has some fields with the comment "working arrays initialized on demand by readUTF" but these fields are being initialized at object instantiation. On the other hand DataOutputStream has one field with a likewise comment initialized to null. I think DataInputStream could be optimized the same way as DataOutputStream and help in the memoty footprint of DataInputStream when used for other reads not related to readUTF. Sounds reasonable?
Re: java.util.regex.Matcher and StringBuilder/StringBuffer APIs
On 6/21/19 1:02 PM, Rob Spoor wrote: Maybe because Appendable comes with IOExceptions? Good catch. The alternative Appendable I was using don't declare throws IOException either, so I didn't noticed. Implementing the find/appendReplacement/appendTail for other kind of Appendable like objects on client code instead of the JDK is not hard, the only part missing is access to the appendExpandedReplacement() implementation as some kind of API, It parses the replacement pattern and generate the replacement. Another interesting thing is that appendReplacement() is using a temporary StringBuilder [1] instead of appending directly to the supplied builder. The only reason I see for that is that if the pattern is illegal, the intervening text isn't appended, so the client code can retry, or something like that, but I don't think it is common or recommended to be capturing IllegalArgumentException for something like this. I wonder if changing it to not use a temporary builder makes sense. [1] http://hg.openjdk.java.net/jdk/jdk/file/e764228f71dc/src/java.base/share/classes/java/util/regex/Matcher.java#l997 On 21/06/2019 17:06, Robert Marcano wrote: Greetings. Is there a reason the newest APIs added to Matcher (performance maybe?) with StringBuilder arguments weren't added as Appendable instead? For example: public StringBuilder appendTail(StringBuilder sb) public Matcher appendReplacement(StringBuilder sb, String replacement) Could have been: public T appendTail(T ap) public Matcher appendReplacement(Appendable ap, String replacement) Both appendReplacement(...) implementations are copies, that could be reduced to a simple one if Appendable was the argument, and the present ones calling to that. If this sounds reasonable, I could write a patch for testing. Note: I was hit with this when trying to use another kind of Appendable optimized for my use case.
java.util.regex.Matcher and StringBuilder/StringBuffer APIs
Greetings. Is there a reason the newest APIs added to Matcher (performance maybe?) with StringBuilder arguments weren't added as Appendable instead? For example: public StringBuilder appendTail(StringBuilder sb) public Matcher appendReplacement(StringBuilder sb, String replacement) Could have been: public T appendTail(T ap) public Matcher appendReplacement(Appendable ap, String replacement) Both appendReplacement(...) implementations are copies, that could be reduced to a simple one if Appendable was the argument, and the present ones calling to that. If this sounds reasonable, I could write a patch for testing. Note: I was hit with this when trying to use another kind of Appendable optimized for my use case.
Re: High memory usage / leaks was: Best mailing list for JVM embedding
On 1/24/19 11:05 AM, Sean Mullan wrote: On 1/24/19 8:25 AM, Robert Marcano wrote: On 1/23/19 8:59 AM, Sean Mullan wrote: On 1/22/19 8:50 PM, Bernd Eckenfels wrote: I don’t think the launcher is doing this, it is the class loader, that’s nothing new. You can turn on verbose security debug to see it in all versions. Yes, and it only verifies the signature(s) on the JAR. It doesn't validate the certificate chain. --Sean I noticed that trying to identify the higher memory usage after what looks like a big application is loaded. I am doing memory profiling and notice JarFile taking more memory that on Java 8. Still need to detect the real cause for an independent test case. We probably didn't notice this slowdown before because Oracle's JNLP implementation was slow enough at startup. IMHO the class library should not do doing signature checks without certificate validation, because it doesn't give any protection if the signature is not verified, the only thing it could do now is to detect some random bit flips, that maybe the Zip format CRC detect before that. With no certificate verification the signature could be replaced by anybody with bad intentions. It's a fair point, although since URLClassLoader is a subclass of SecureClassLoader the certificate chain does get populated into the CodeSource of the classes loaded, so one could potentially write a custom ClassLoader or additional code to additionally validate the certificate chain. Also, keep in mind that validating a certificate chain for signed code is not usually sufficient to determine if you actually trust who signed the code; some additional policy configuration (or UI prompts) are usually required. Also, if you run the application with a SecurityManager you can grant the signed JARs additional permissions based on who signed the code in an associated policy file, see [1] for more info. Thanks for the info, but this is for corporate intranet application distribution of an ISV (us) application, no untrusted code installation. We are signing our code with a certificate from a private CA and the CA is embedded on the native updater/launcher as the exclusive CA used for dowloaded updates validation. It is more like the Firefox/Chrome updater. Maybe adding a constructor flag to URLClassloader to pass to JarFile to skip verification and a system property to tell the Java startup code to skip verification of java.class.path (just for compatibility with old code that expect it to be done). There is precedent of other runtimes that added options to disable this, like CLR [1] (Ii not only verified signatures, It do CRL/OSCP checks too) It's easy enough to strip signatures from JAR files (which you mention below). So if this is really an issue, I would be more inclined to just do that if it is an option. Yea, I added an option to remove the signatures from the downloaded updates (after signature validation) so they are not validated anymore at launch time. Our new launcher replacing JNLP now do signature verification in native code, at download time, and install on a system area (not user home directory), so signature verification at application launch is a slowdown we want to avoid, but think on another kind of users, those deploying to OS Stores (for example Windows Store), why add the slowdown of verification when the application is verified by the store client at install time?, this could help these situations too. Note: This can be avoided removing the signatures of all JARs if you distribute to an OS store, there are a few libraries that distribute their JARs signed (The old Java Help framework comes to my mind right now) [1] https://blogs.msdn.microsoft.com/shawnfa/2007/05/07/bypassing-the-authenticode-signature-check-on-startup/ --Sean [1] https://docs.oracle.com/en/java/javase/11/security/permissions-jdk1.html#GUID-7450CEFD-8EDC-495E-A7A3-6C2561FA4999
Re: High memory usage / leaks was: Best mailing list for JVM embedding
On 1/23/19 8:59 AM, Sean Mullan wrote: On 1/22/19 8:50 PM, Bernd Eckenfels wrote: I don’t think the launcher is doing this, it is the class loader, that’s nothing new. You can turn on verbose security debug to see it in all versions. Yes, and it only verifies the signature(s) on the JAR. It doesn't validate the certificate chain. --Sean I noticed that trying to identify the higher memory usage after what looks like a big application is loaded. I am doing memory profiling and notice JarFile taking more memory that on Java 8. Still need to detect the real cause for an independent test case. We probably didn't notice this slowdown before because Oracle's JNLP implementation was slow enough at startup. IMHO the class library should not do doing signature checks without certificate validation, because it doesn't give any protection if the signature is not verified, the only thing it could do now is to detect some random bit flips, that maybe the Zip format CRC detect before that. With no certificate verification the signature could be replaced by anybody with bad intentions. Maybe adding a constructor flag to URLClassloader to pass to JarFile to skip verification and a system property to tell the Java startup code to skip verification of java.class.path (just for compatibility with old code that expect it to be done). There is precedent of other runtimes that added options to disable this, like CLR [1] (Ii not only verified signatures, It do CRL/OSCP checks too) Our new launcher replacing JNLP now do signature verification in native code, at download time, and install on a system area (not user home directory), so signature verification at application launch is a slowdown we want to avoid, but think on another kind of users, those deploying to OS Stores (for example Windows Store), why add the slowdown of verification when the application is verified by the store client at install time?, this could help these situations too. Note: This can be avoided removing the signatures of all JARs if you distribute to an OS store, there are a few libraries that distribute their JARs signed (The old Java Help framework comes to my mind right now) [1] https://blogs.msdn.microsoft.com/shawnfa/2007/05/07/bypassing-the-authenticode-signature-check-on-startup/ -- https://Bernd.eckenfels.net Von: core-libs-dev im Auftrag von Robert Marcano Gesendet: Mittwoch, Januar 23, 2019 2:18 AM An: Alan Bateman Cc: OpenJDK Dev list; core-libs-dev Libs Betreff: Re: High memory usage / leaks was: Best mailing list for JVM embedding On Tue, Jan 22, 2019, 5:53 AM Alan Bateman wrote: On 22/01/2019 4:48 am, Robert Marcano wrote: : So the question now is, why signed jars could affect the memory usage of an application (we aren't doing JAR verification on our custom launcher, yet), just by being on the java.class.path? IIRC the initial application classpath JARs were never verified previously (by the java launcher alone, without JNLP around). Note: Tested with JARs signed with a self signed certificate and with one signed with a private CA. At most, signing the JARs could slow down the start up if it is now expected to these being verified by the java launcher (is it true?) but not higher memory usage and no reductions after a GC cycle but constants heap size increases. Signed JARs can be expensive to verify, esp. on first usage as the verification is likely to result in early loading of a lot of security classes and infrastructure. If you can narrow down the apparently memory leak to a small test case with analysis to suggest it's a JDK bug then it would be good to get a bug submitted. -Alan Greeting. Sure, I will work on a distributable reproduction of the problem today but it is new to me that the java launcher do JARs verification now. If it is doing it I doesn't make sense to me, because a self signed or unrecognized CA doesn't trigger a validation error.
Re: High memory usage / leaks was: Best mailing list for JVM embedding
On Tue, Jan 22, 2019, 5:53 AM Alan Bateman On 22/01/2019 4:48 am, Robert Marcano wrote: > >> : > >> > >> So the question now is, why signed jars could affect the memory usage > >> of an application (we aren't doing JAR verification on our custom > >> launcher, yet), just by being on the java.class.path? IIRC the > >> initial application classpath JARs were never verified previously (by > >> the java launcher alone, without JNLP around). > >> > >> Note: Tested with JARs signed with a self signed certificate and with > >> one signed with a private CA. At most, signing the JARs could slow > >> down the start up if it is now expected to these being verified by > >> the java launcher (is it true?) but not higher memory usage and no > >> reductions after a GC cycle but constants heap size increases. > Signed JARs can be expensive to verify, esp. on first usage as the > verification is likely to result in early loading of a lot of security > classes and infrastructure. If you can narrow down the apparently memory > leak to a small test case with analysis to suggest it's a JDK bug then > it would be good to get a bug submitted. > > -Alan Greeting. Sure, I will work on a distributable reproduction of the problem today but it is new to me that the java launcher do JARs verification now. If it is doing it I doesn't make sense to me, because a self signed or unrecognized CA doesn't trigger a validation error. >
