Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v3]
The change does not seem to be related to your description, and the description does not match the shown exception. In fact the example stacktrace contains the authority value twice and your change adds a diagnostic which is not really helpful for the case of the underscore? I would not be too specific for such general parsing rules. -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Matthias Baesken Gesendet: Tuesday, June 14, 2022 1:36:36 PM An: core-libs-dev@openjdk.java.net ; security-...@openjdk.java.net Betreff: Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v3] > When trying to construct an LdapURL object with a bad input string (in this > example the _ in ad_jbs is causing issues), and not using > the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run > into the exception below : > > import com.sun.jndi.ldap.LdapURL; > > String url = "ldap://ad_jbs.ttt.net:389/xyz";; // bad input string containing _ > LdapURL ldapUrl = new LdapURL(url); > > > java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest > Exception in thread "main" javax.naming.NamingException: Cannot parse url: > ldap://ad_jbs.ttt.net:389/xyz [Root exception is > java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389] > at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115) > at LdapParseUrlTest.main(LdapParseUrlTest.java:9) > Caused by: java.net.MalformedURLException: unsupported authority: > ad_jbs.ttt.net:389 > at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367) > at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230) > at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174) > at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105) > > I would like to add the host and port info to the exception (in the example > it is host:port of URI:null:-1] ) so that it is directly visible that the > input caused the construction of a URI > with "special"/problematic host and port values. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: fix copy paste error - Changes: - all: https://git.openjdk.org/jdk/pull/9126/files - new: https://git.openjdk.org/jdk/pull/9126/files/1050c724..bdbe2204 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9126&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9126/head:pull/9126 PR: https://git.openjdk.org/jdk/pull/9126
Re: Regression after April Java 17 Update (mime types)
Hello Christoph, The actual release notes I initially looked up are the April Release notes from Azul (17.34) for 17.0.3. I already opened a case there. However I then also checked the Oracle Release Notes (I thought they would contain the same 17.0.3 changes). The incompatibility in VFS was actually a shortcoming in VFS: if you want to determine who can handle a file type it would check the mime type or the extension. But it was coded in a way that if it has a mime type but no handler for that type it won’t check for the file extension. This way it could no longer browser URLs ending in .jar or uncompres .go files (or generally all files where there was previously only a file extension handler registered). I would asume this negative consequences is hard to predict, especially since VFS could in this case prevemt it. However for an application it is unfortunate that this breaks (especially when hoping to ship a quarterly security update quickly). Bit generally it’s a noteworthy new feature. Thanks for the reminder of the Shipilev release notes, I did actually not check them after looking at two vendors (and not finding a Release announcement mail like there was one for 17.0.2. Can I asume those are no longer sent after X.0.2 is published? I guess my comment to „not including it in the release notes“ was not valid for the OpenJDK Updates project and I will take it up with Azul to check the source they are using. If you want to look deeper into this: The VFS logic might be a bit hard to follow, it basically works on URLs and it has a filesystem layering mode which checks on mime type and/or extension: https://issues.apache.org/jira/browse/VFS-770 This is the actual fix commit for it: https://github.com/apache/commons-vfs/commit/f3b7a06f28aab2db829806e0e857c05b71a14305 It is retrieving the contentType for a URL here https://github.com/apache/commons-vfs/blob/64da24778ea075ffc5de8588a29a0f50c6c8d94e/commons-vfs2/src/main/java/org/apache/commons/vfs2/impl/FileContentInfoFilenameFactory.java#L41 Gruss Bernd -- http://bernd.eckenfels.net Von: Langer, Christoph Gesendet: Tuesday, April 26, 2022 5:18:38 PM An: Bernd Eckenfels ; jdk-updates-...@openjdk.java.net Cc: core-libs-dev Betreff: RE: Regression after April Java 17 Update (mime types) Hi Bernd, I just noticed your report regarding the regression after JDK-8273655. I'm directing this communication to jdk-updates-dev now as it seems more appropriate. I assume with release notes you're referring to the Oracle 17.0.3 release notes? This change, if you look closely at the backports, was only brought to OpenJDK 17.0.3 and it will hit the OpenJDK 11u update 11.0.16 in July. So, it would not be reflected in Oracle release notes. The best you can get for OpenJDK 17.0.3 release notes is [0], to my knowledge. Do you have some more information regarding the incompatibility? What I'm understanding is that this backport unveils a problem with Apache VFS? Do you have a bug link for that one? If it's just uncovering a bug in another 3rd party software, I assume it doesn't merit a backout, though. Best regards Christoph [0] https://builds.shipilev.net/backports-monitor/release-notes-17.0.3.html > -Original Message- > From: core-libs-dev On Behalf Of Bernd > Eckenfels > Sent: Montag, 25. April 2022 19:39 > To: core-libs-dev > Subject: Regression after April Java 17 Update (mime types) > > Hello, > > We just tried to push out the Java 17 April Update but it failed with some > incompatible behavior. We found out it is caused due to a new mime-type (and > a bug in Apache VFS) that JAR files could no longer be opened in an overlay > (technically a JAR URL suddenly had a mime-type and therefore VFS no longer > looked at the file extension). > > Just wanted to give a heads up in case anybody else has that problem. The > change 8273655 (a backport 828109) was not mentioned in the 17.0.3 release > notes (it is also in 11.0.16) from Oracle and Azul - will it show up in the > OpenJDK announcement? > > This specific case is a changed behavior (even when it has rather unexpected > negative consequences), it would be therefore good to be called out > specifically. > > Gruss > Bernd > > > -- > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbernd.eck > enfels.net%2F&data=05%7C01%7Cchristoph.langer%40sap.com%7C9ca8f > 2471e24471c3d8308da26e286b1%7C42f7676cf455423c82f6dc2d99791af7%7 > C0%7C0%7C637865052069446373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 > %7C%7C%7C&sdata=J3kfVCvkDUH9UxiRqkoS9g9o85nB46ksbpUF5HihRP8 > %3D&reserved=0
Regression after April Java 17 Update (mime types)
Hello, We just tried to push out the Java 17 April Update but it failed with some incompatible behavior. We found out it is caused due to a new mime-type (and a bug in Apache VFS) that JAR files could no longer be opened in an overlay (technically a JAR URL suddenly had a mime-type and therefore VFS no longer looked at the file extension). Just wanted to give a heads up in case anybody else has that problem. The change 8273655 (a backport 828109) was not mentioned in the 17.0.3 release notes (it is also in 11.0.16) from Oracle and Azul - will it show up in the OpenJDK announcement? This specific case is a changed behavior (even when it has rather unexpected negative consequences), it would be therefore good to be called out specifically. Gruss Bernd -- http://bernd.eckenfels.net
Re: RFR: 8285445: cannot open file "NUL:"
Is that really a needed fix? enabling ADS and less strict parsing might introduce vulnerability but on the other hand NUL: should be allowed for it is a drive style not a ADS. I would also think the number of users who want use NUL: is smaller than the number of users who benefit from ADS being forbidden. Especially since \\.\NUL or NUL should already work. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Brian Burkhalter Gesendet: Saturday, April 23, 2022 3:20:02 AM An: core-libs-dev@openjdk.java.net Betreff: RFR: 8285445: cannot open file "NUL:" Change the default value of the `jdk.io.File.enableADS` property to `true`. - Commit messages: - 8285445: cannot open file "NUL:" Changes: https://git.openjdk.java.net/jdk/pull/8373/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8373&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285445 Stats: 57 lines in 2 files changed: 52 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8373.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8373/head:pull/8373 PR: https://git.openjdk.java.net/jdk/pull/8373
Zlib update
Since the new upstream version for zlib 1.2.12 is available since 4 weeks and I don’t see them in GitHub (not even after April cpu merges) I wonder when is an update planned? (I also noticed at least one vendor claims to have a zlib fix, I am not yet sure if this is a vendor specific thing) If the system zlib on Linux is used, can OS updates to zlib be applied, is this compatible? Gruss Bernd -- http://bernd.eckenfels.net
Re: RFR: 8284932: [Vector API] Incorrect implementation of LSHR operator for negative byte/short elements
Hello, Maybe offer operations which can do all variants (shift, roll, signed/unsigned) - maybe even with support for byte/int conversion? Any of those bit fiddling activities in a pipeline can benefit from vectoring. And also, the Javadoc can list the equivalent operator based code and maybe bit pattern examples for all overflow cases. And also.. the unit tests can double as snipped code. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Jie Fu Gesendet: Monday, April 18, 2022 3:51:40 AM An: core-libs-dev@openjdk.java.net ; hotspot-compiler-...@openjdk.java.net Betreff: Re: RFR: 8284932: [Vector API] Incorrect implementation of LSHR operator for negative byte/short elements On Sun, 17 Apr 2022 23:53:49 GMT, Quan Anh Mai wrote: > According to JLS section 5.8, any operand in a numeric arithmetic context > undergoes a promotion to int, long, float or double and the operation is only > defined for values of the promoted types. This means that `>>>` is not > defined for byte/short values and the real behaviour here is that `src[i]` > get promoted to int by a signed cast before entering the unsigned shift > operation. This is different from `VectorOperators.LSHR` which is defined for > byte/short element types. The scalar code does not do a byte unsigned shift > but an int unsigned shift between a promotion and a narrowing cast, the > explicit cast `(byte)` notifies the user of this behaviour. I can't understand why people can't use `>>>` for negative bytes/shorts. - Does the spec forbidden this usage? - Is there any compile error? - Is there any runtime error? - Is the behavior to be undefined? The JLS you mentioned actually defines how to compute `>>>` for bytes/shorts in Java, which applies to both positive and negative bytes/shorts. - First, it gets promoted. - Then, do something else. So I disagree with you if the JLS spec doesn't say people are not allowed to use `>>>` for negative bytes/shorts. > > Secondly, consistency is the key, having a byte unsigned shift promoting > elements to ints is not consistent, I can argue why aren't int elements being > promoted to longs, or longs being promoted to the 128-bit integral type, too. > Well, this kind of behavior was specified by the Java spec rules many years ago. We have to just follow these rules if you can't change the specs. > Finally, as I have mentioned in #7979, this usage of unsigned shift seems > more likely to be a bug than an intended behaviour, so we should not bother > to optimise this pattern. Since the behavior of shift operations is clearly defined by the Java specs and supported by the language, how do you know there is no one to use it intendedly? - PR: https://git.openjdk.java.net/jdk/pull/8276
Re: RFR: 8284638: store skip buffers in InputStream Object [v2]
If you consider doing benchmarks in detail maybe consider a static buffer, too? (Especially if it can be used in multiple implementations?) Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von XenoAmess Gesendet: Wednesday, April 13, 2022 11:58:06 PM An: core-libs-dev@openjdk.java.net Betreff: Re: RFR: 8284638: store skip buffers in InputStream Object [v2] On Wed, 13 Apr 2022 16:02:10 GMT, Alan Bateman wrote: >>> @AlanBateman You are correct about this. But I wonder if this be a problem, >>> why Reader class can afford store a skip buffer for each Reader. >>> >>> Is there anything different in the situations about skipBuffer in Reader >>> and InputStream? >> >> Maybe the skip buffer in Reader should be looked at too, esp. as it >> couldpotentially grow to 16k bytes. The concern with changing >> InputStream.skip is that there may be a lot more input streams than readers >> in use, esp. if there is an input stream for every socket connection. > >> @AlanBateman Is the concern about holding more memory sufficient to retain >> the buffer using a SoftReference so it can be freed eagerly? >> These buffers are never read from, so are quite a waste, but at least they >> are only used when >> the underlying stream overrides skip. > > Maybe but I think it needs some benchmarks to know if caching a byte[] will > help or just bloat memory. If the InputStream is to a file or socket then > maybe skip is dominated by the I/O rather than the array allocation and > zero'ing. @AlanBateman jmh test added - PR: https://git.openjdk.java.net/jdk/pull/5872
Re: fast way to infer caller
Some loggers do need to find the location of the log statement (class and line where the logger is used not where it is instantiated). for those (it makes loggers more useful) getting the call site is time critical even if they are not in tight performance critical loops. But it actually does matter if/how the JVM optimizes such introspection.. if the JVM can inline (and maybe even constant intrinsic) the stalkwalker it would benefit such use cases just as well. -- https://bernd.eckenfels.net From: core-libs-dev on behalf of Michael Kuhlmann Sent: Thursday, April 7, 2022 7:55:16 PM To: core-libs-dev@openjdk.java.net Subject: Re: fast way to infer caller On 4/7/22 19:27, Kasper Nielsen wrote: >> >> nope, see my previous mail to Ceki, the VM is cheating here if it can >> inline the call to MethodHandles.lookup() >> > > Does how the VM cheats really matter? The fact is that the code in the JDK > can > get the calling class and implement something like MethodHandles.lookup() so > it takes ~3 ns. If you implemented something like a lookup class as a normal > user your best bet would be StackWalker.GetCallingClass() and you would end > up with something that is at least 2 magnitudes slower. That is probably not > an issue for most use cases. But for some, it might be a bit of a steep > cost. > > /Kasper Hi Kasper, sorry to jump in here as an uninvolved onlooker, but I can't resist. I really don't see why this should matter. Getting the caller class is a rare edge case that you just do in exceptional situations; most often it's more for debugging or something. What users really are interested in is high performance for standard cases. Implementing a specific optimization into Hotspot to gain few milliseconds is the least thing I expect from the JVM developers. I also don't understand why someone should instantiate a logger during performance critical procedures. In more than 20 years of Java development, I've never seen the need to create a logger on the fly. They are *always* assigned to final static variables, or at least to predefined pools. Everything else would be just wrong: To instantiate a logger, you have to fetch at least the log level definition from some configuration source, and this can never be fast. At least not that we're talking about nanoseconds here. All logging implementations I know of (and all that make sense) are highly optimized on log throughput; this can only be achieved by preprocessing during initialization, why this is slow. But that doesn't matter, because, as said, you should anyway create logger instances beforehand. Sorry for the rant, but I really don't see the use case here.
Re: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes
I wonder should the CSR not describe what’s the advantage of this change is and what the compatibility problems are and why they don’t apply here? Especially given the fact that the specific sub exceptions are not sealed I wonder if the risk of breaking existing code is worth it? (But I do see the beauty of such a construct for new code!) Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Jaikiran Pai Gesendet: Friday, March 25, 2022 10:27:40 AM An: core-libs-dev@openjdk.java.net Betreff: Re: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy wrote: > Working down the list of candidates to be sealed, this time > IllegalFormatException. > > Please also review the companion CSR: > https://bugs.openjdk.java.net/browse/JDK-8283669 Marked as reviewed by jpai (Committer). - PR: https://git.openjdk.java.net/jdk/pull/7950
Re: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes
Hello, Not sure how often skip is actually used so it might not matter, but this change would increase allocations if skip is called regularly. Not sure if EA can prevent that if it is only medium hot and therefore the callsite is not compiled or inlined? An alternative would be to make this static and/or allocate lazy (or even share it with more places which need a write-only array?) Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Lance Andersen Gesendet: Sunday, March 20, 2022 11:51:23 AM An: core-libs-dev@openjdk.java.net Betreff: Re: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes On Sun, 20 Mar 2022 04:24:07 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which handles > https://bugs.openjdk.java.net/browse/JDK-8283411? > > The commit here moves the temporary byte array from being a member of the > class to a local variable within the `skip` method which is the only place > where it is used as a temporary buffer. > > tier1, tier2, tier3 tests have been run successfully with this change. Hi Jaikiran, This looks fine. Please add the label noreg-trivial to the bug otherwise you will get a ping as there is no test associated with the PR - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7875
Re: Discussion about Java Floating Point?
Please stop sending mails marked as urgent to a mailing list, you just make a
fool of yourself.
The need to round floating point numbers for commercial math (and the risk
involved in doing so) is nothing new, it predates the IEEE standard and should
be subject for even basic comp sci curriculums all over the world.
(Having said that, automatic precision/rounding for number formats in C++ looks
neat)
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von A Z
Gesendet: Dienstag, März 15, 2022 5:24 AM
An: core-libs-dev@openjdk.java.net
Betreff: Discussion about Java Floating Point?
To core-libs-dev@openjdk.java.net,
In terms of floating point, it seems there are thus
three (3) phenomena that are relevant.
1) Arithmetic on float and double, via operators.
2) Elementary function calls, namely
those made from java.lang.StrictMath, as it is,
on double values.
3) Comparison operators. ==, !=, >, <, >=,<=.
Java floating point successfully has 3) the way required,
even though other languages, particularly C++ , do not
compare their floats and doubles through those comparison
operators. The point at issue is Java although, so Java is
satisfactory at point 3).
My point of contention is that Java does not have 1) and 2)
operating as they should, even though C++ and other
languages do, in those two areas, namely C++:
Martin has submitted the following:
?The following statement is not entirely true when using finite floating
point precision:
> (?snip?) It is a mathematical fact that, for
> consistent, necessary and even fast term, 10% of 10% must
> always precisely be 1%, and by no means anything else."
/*
#include
using namespace std;
int main()
{
cout << "Program has started..." << endl;
double a = 0.1D;
double b = 0.1D;
double c = a*b;
cout << endl << c << endl << endl;
float d = 0.1F;
float e = 0.1F;
float f = d*e;
cout << f << endl << endl;
cout << "Program has Finished.";
return 0;
}
*/
/*
Program has started...
0.01
0.01
Program has Finished.
*/
This is actually not fully or finally true, including SSE, SSE algorithm logic
and further.
The included C++ example of mine above here disproves this. Even though I do
contextually admit these answers can only work within the range of the
involved types, it is still actually the case that 10% of 10% can and always
precisely be 1%, within the range of the type used, and by no means
anything else. Because of the laws of decimal arithmetic.
See https://en.wikipedia.org/wiki/Floating-point_arithmetic
and the starting sentence:
'In computing, floating-point arithmetic (FP) is arithmetic using formulaic
representation of real numbers as an approximation to support a
trade-off betwee range and precision.'
However, it simply isn't the case that reduced precision has to exist inside
the range, certainly not any more. Rationally, one would have to think,
with the present SSE support in ubiquity, and the preimplementation
that is possible and already around elsewhere, that this kind of tradeoff
in floating point isn't any kind of use or advantage any more.
This is part of the issue with Java and the OpenJDK at this time, and I am
trying
to contend that this should be changed, either at default or in
some mutual compatibility mode. The other part is java.lang.StrictMath,
since it generates denormal and pronormal values on its own, also.
Raffaello has stated:
To summarize, Java uses IEEE 754 binary arithmetic as by specification,
as do most other languages, including C/C++. It is however fundamentally
wrong to use binary floating-point arithmetic to emulate decimal
behavior. Also, pay attention to the output routines that convert float
and double values to a decimal representation. Usually, C and C++ will
have information loss by default, as in your case.
What we and others are beginning to need to happen, in detailed Java 2D
and 3D (JMonkeyEngine 3.5) projects, and more widely again, is that Java
floating point arithmetic and function behaviour, on float and double,
within their ranges, do need to perfectly match decimal behaviour.
C++ arithmetic, at least, has had no problem using floating point arithmetic,
at least, to emulate decimal behaviour. I am trying to prove the opposite to
Raffaello's statements, that floating point can and indeed must represent
decimal behaviour.
Output functions in any language that alter the appearance of the float or
double
value become irrelevant, because the only relevant factor is the operator
behaviour
and the innate, representation viewpoint of those float or double values.
In contrast to Raffaelo, we assert that Java SE and OpenJDK floating point must
be changed
so that it upholds base ten (10) arithmetic, algebra,and elementary functions
on real value
arguments withi
Re: RFR: 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure
Should probably explain why it removes the private modifier? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Сергей Цыпанов Gesendet: Saturday, March 5, 2022 2:14:20 PM An: core-libs-dev@openjdk.java.net Betreff: RFR: 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from. - Commit messages: - 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure Changes: https://git.openjdk.java.net/jdk/pull/7714/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7714&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282701 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7714.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7714/head:pull/7714 PR: https://git.openjdk.java.net/jdk/pull/7714
Re: Should System.exit be controlled by a Scope Local?
Alternatively you can make this “first setter wins” (either globally or per
thread), then you don’t have to care or check from where the call is coming.
Could be even integrated with a system property similar to the
securitymanager=allow.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von Kasper
Nielsen
Gesendet: Monday, February 28, 2022 9:23:11 PM
An: Ethan McCue
Cc: core-libs-dev
Betreff: Re: Should System.exit be controlled by a Scope Local?
Is there really a need to make this so complicated?
In all the examples I've seen so far it would be fine to set
system-exit restrictions up from the program's main class.
So why not just restrict it to the main class by default?
I assume this class is under the control of the user or
an IDE/Application Server.
Add this method to java.lang.Runtime
void restrictExit(MethodHandles.Lookup lookup, IntConsumer interceptor) {
if (lookup.lookupClass() != "JAVA_MAIN_CLASS" ||
!lookup.hasFullPrivilegeAccess())
{
throw new IllegalArgumentException("Invalid Lookup class");
}
...
Register interceptor to be called before System.exit
...
}
People could then call it, for example, from a static initializer block in
the
Main class. And use scope locals or whatever they want.
static {
Runtime.restrictExit(MethodHandles.lookup(), ...)
}
Ideally, everyone would be using the module system, And we would have some
kind
of "application module" concept, which would be the module containing the
program's entry point. And which could have these special permissions by
default.
It might even be possible to delegate permissions to other modules if
needed.
/Kasper
On Sat, 26 Feb 2022 at 22:27, Ethan McCue wrote:
> I have a feeling this has been considered and I might just be articulating
> the obvious - but:
>
> As called out in JEP 411, one of the remaining legitimate uses of the
> Security Manager is to intercept calls to System.exit. This seems like a
> decent use case for the Scope Local mechanism.
>
>
>
Re: a quick question about String
new String() always creates a new instance. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Alan Snyder Gesendet: Thursday, December 23, 2021 6:59:18 PM An: core-libs-dev Betreff: a quick question about String Do the public constructors of String actually do what their documentation says (allocate a new instance), or is there some kind of compiler magic that might avoid allocation?
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3]
Yes but that does not help with the decision if parallel should be used or not. But yes, if it is generally not wanted to make the pool explicite a simple parallel signature without argument would also work to make the decision explicite (I.e. new api). That won’t automatically tune the performance but it does allow users to use it - majority would be crypto anyway where it can be used by the JCE and JSSE (maybe?). Gruss Bernd -- http://bernd.eckenfels.net Von: Remi Forax Gesendet: Thursday, November 18, 2021 12:16:31 PM An: Bernd Eckenfels Cc: core-libs-dev Betreff: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3] - Original Message - > From: "Bernd Eckenfels" > To: "core-libs-dev" > Sent: Jeudi 18 Novembre 2021 12:07:19 > Subject: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger > [v3] > What about a new API multiply method which takes an forkjoinpool, and only if > that is used/specified it will use the parallel mode (and only if Notsitzes > threshold applies?). Most of the pool tuning can then done with this argument. > It also avoids surprise threads. You don't need it, here is the usual trick if you want to specify a specific fork join pool https://stackoverflow.com/questions/21163108/custom-thread-pool-in-java-8-parallel-stream > > Gruss > Bernd regards, Rémi > -- > http://bernd.eckenfels.net > > Von: core-libs-dev im Auftrag von kabutz > > Gesendet: Thursday, November 18, 2021 11:41:40 AM > An: core-libs-dev@openjdk.java.net > Betreff: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger > [v3] > > On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes wrote: > >> To add my 2c IMO a parallel version of this type absolutely **must** be >> opt-in. >> There are simply far too many side-effects of using the FJP and multiple >> threads to perform the calculation in parallel as if it is just a minor >> implementation detail. A clear API is 1000x better than a "kill switch". >> >> And yes you may still need to expose some kind of tuning knob. >> >> David > > Yes, it **must** be opt-in. However I'm not sure that a tuning knob will be > necessary. BigInteger has thresholds for using different multiply algorithms > and these are also not configurable. > > - > > PR: https://git.openjdk.java.net/jdk/pull/6409
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3]
What about a new API multiply method which takes an forkjoinpool, and only if that is used/specified it will use the parallel mode (and only if Notsitzes threshold applies?). Most of the pool tuning can then done with this argument. It also avoids surprise threads. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von kabutz Gesendet: Thursday, November 18, 2021 11:41:40 AM An: core-libs-dev@openjdk.java.net Betreff: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3] On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes wrote: > To add my 2c IMO a parallel version of this type absolutely **must** be > opt-in. There are simply far too many side-effects of using the FJP and > multiple threads to perform the calculation in parallel as if it is just a > minor implementation detail. A clear API is 1000x better than a "kill switch". > > And yes you may still need to expose some kind of tuning knob. > > David Yes, it **must** be opt-in. However I'm not sure that a tuning knob will be necessary. BigInteger has thresholds for using different multiply algorithms and these are also not configurable. - PR: https://git.openjdk.java.net/jdk/pull/6409
OutputStreamWriter (not) flushing stateful Charsetencoder
(I thought this was discussed a while back on a OpenJDK mailing list, but I
can’t find it. So apologies if this is a duplicate, but I might have seen it on
Apache Commons-io instead - which fixed a similar issue on reader side)
The problem: I have code using a OutputStreamWriter with a customer defined
charset name. this writer is flushed, and the code expects all pending bytes to
be written. However when a stateful charset like cp930 is used, this is not the
case. The final unshift byte for example is only written when the writer is
closed. This is probably because it does not call end of data encode on the
encoder in the flush().
The class does not clearly say or not say what is the correct behavior, however
the flush() is formulated in a way that one could expect it should produce a
complete stream.
So, is this a Bug in the implementation, if not should it be added to the
documentation?
Here is a small JShell reproducer, you see the extra unshift byte (dec 15) only
after the close:
var b = new byte[] { 0x31, (byte)0xef, (byte)0xbc, (byte)0x91 };
var s = new String(b, "UTF-8"); // „1２“ (1 is ascii, 2 is fw)
var bos = new ByteArrayOutputStream();
var w = new OutputStreamWriter(bos, "cp930"); // stateful ebcdic with Shift
chars
w.write(s);
w.flush();
bos.toByteArray()
$8 ==> byte[4] { -15, 14, 66, -15 }
w.close();
bos.toByteArray()
$10 ==> byte[5] { -15, 14, 66, -15, 15 }
--
http://bernd.eckenfels.net
Re: (ch) InnocuousThread names
Looking at the code some more I wonder: *if defaultThreadFactoty should use a Thread group for the pool or at least for NIO? * If it can skip the security manager check and use InnocousThread in all cases (to avoid ThreadLocals - not sure if some encode cache is hurt by it?) * If it can skip the priveledged call as IThread does that itself. https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L76 -- http://bernd.eckenfels.net Von: Bernd Eckenfels Gesendet: Sunday, October 17, 2021 4:56:17 AM An: OpenJDK Dev list ; nio-...@openjdk.java.net Betreff: InnocuousThread names (was: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride) Apropos InnocousThread backporting - I Wonder if we should remove the auto threadname infrastructure and only create properly named threads. The generic name seems to be rather confusing and it seems it is only used in an NIO Pool, where a thread-name should be set, anyway? https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L86 Gruss Bernd -- http://bernd.eckenfels.net Von: jdk8u-dev im Auftrag von Zhengyu Gu Gesendet: Sunday, October 17, 2021 1:39:12 AM An: Hohensee, Paul ; jdk8u-dev Betreff: Re: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride Thanks, Paul -Zhengyu On 10/15/21 17:30, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > -Original Message- > From: jdk8u-dev on behalf of Zhengyu Gu > > Date: Tuesday, October 5, 2021 at 8:12 AM > To: jdk8u-dev > Subject: [8u] RFR 8190482: InnocuousThread creation should not require the > caller to possess enableContextClassLoaderOverride > > This backport is for parity with Oracle 8u321. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190482 > Webrev: http://hg.openjdk.java.net/jdk/jdk/rev/5e7cf99b1303 > > The original patch does not apply cleanly. There is not newThread(String > name, Runnable target) method in 8u, so discard this part of change. > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8190482-8u/webrev.00/ > > > Thanks, > > -Zhengyu > >
InnocuousThread names (was: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride)
Apropos InnocousThread backporting - I Wonder if we should remove the auto threadname infrastructure and only create properly named threads. The generic name seems to be rather confusing and it seems it is only used in an NIO Pool, where a thread-name should be set, anyway? https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/nio/ch/ThreadPool.java#L86 Gruss Bernd -- http://bernd.eckenfels.net Von: jdk8u-dev im Auftrag von Zhengyu Gu Gesendet: Sunday, October 17, 2021 1:39:12 AM An: Hohensee, Paul ; jdk8u-dev Betreff: Re: [8u] RFR 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride Thanks, Paul -Zhengyu On 10/15/21 17:30, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > -Original Message- > From: jdk8u-dev on behalf of Zhengyu Gu > > Date: Tuesday, October 5, 2021 at 8:12 AM > To: jdk8u-dev > Subject: [8u] RFR 8190482: InnocuousThread creation should not require the > caller to possess enableContextClassLoaderOverride > > This backport is for parity with Oracle 8u321. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190482 > Webrev: http://hg.openjdk.java.net/jdk/jdk/rev/5e7cf99b1303 > > The original patch does not apply cleanly. There is not newThread(String > name, Runnable target) method in 8u, so discard this part of change. > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8190482-8u/webrev.00/ > > > Thanks, > > -Zhengyu > >
Re: Implementing JEP 400 on Windows 10 and Windows 11
I think the last sentence was missing a „not“ and referring to the same manifest? However the results are a bit of a mess, but utf-8 handling for argv would be great plus (if converted correctly), right? -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Magnus Ihse Bursie Gesendet: Tuesday, October 5, 2021 10:34:26 AM An: John Platts ; core-libs-dev Betreff: Re: Implementing JEP 400 on Windows 10 and Windows 11 On 2021-10-05 03:22, John Platts wrote: > I wrote a test program (in C++) to detect the codepages that would be > returned by the GetACP(), GetOEMCP(), and GetConsoleCP() functions when the > UTF-8 setting is added to the > manifest. > > The manifest element (supported on Windows 10 Version > 1903 or later) is in the > http://schemas.microsoft.com/SMI/2019/WindowsSettings namespace and is added > to the asmv3:WindowsSettings element as shown below: > xmlns:dpi1="http://schemas.microsoft.com/SMI/2005/WindowsSettings"; > > xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings"; > > xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings";> > true/PM > PerMonitorV2, PerMonitor, system > UTF-8 > > > Here is the output of the test program without the > UTF-8 setting present in the > executable manifest: > GetACP() result: 1252 > GetOEMCP() result: 437 > GetConsoleCP() result: 437 > System default LCID: 1033 > User default LCID: 1033 > User default UI LCID: 1033 > Codepage from system default LCID: 1252 > Codepage from user default LCID:1252 > Codepage from user default UI LCID: 1252 > > Here is the output of the same test program with an executable manifest that > includes the UTF-8 setting: > GetACP() result: 65001 > GetOEMCP() result: 65001 > GetConsoleCP() result: 437 > System default LCID: 1033 > User default LCID: 1033 > User default UI LCID: 1033 > Codepage from system default LCID: 1252 > Codepage from user default LCID:1252 > Codepage from user default UI LCID: 1252 > > Note that the UTF-8 setting in the > application manifest changes the results of the GetACP() and GetOEMCP() calls > but not the GetConsoleCP() call. This is really confusing. I'm glad you are gathering empirical evidence of how it works. :-) > I wrote another test program, and the argument strings passed into the > main(int argc, char** argv) function are converted to UTF-8 if the > UTF-8 setting is there in the > application manifest whereas the argument strings passed into the main (int > argc, char** argv) function are converted to the ANSI codepage (which is > usually code page 1252 on US English systems) if the > UTF-8 setting is there in the > UTF-8 manifest. I'm not sure I understand this. What is the difference between "the application manifest" and "the UTF-8 manifest"? /Magnus
Re: Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as the default codepage through an executable manifest option
John do you know if this also switches a console window into utf8 for such a launcher? (And if so, also for a already open console?) The problem will be similar to initial jep400 that some still might need to know the legacy ansi codepage for the OS, and I guess the new method won’t give us that if the manifest is changed? -- https://Bernd.eckenfels.net From: core-libs-dev on behalf of Naoto Sato Sent: Monday, October 4, 2021 10:23:47 PM To: core-libs-dev@openjdk.java.net Subject: Re: Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as the default codepage through an executable manifest option Hi John, Please see the JEP 400, which changes the default charset to UTF-8 across platforms: https://openjdk.java.net/jeps/400 HTH, Naoto On 10/4/21 8:47 AM, John Platts wrote: > Windows 10 (since Windows 10 version 1903) and Windows 11 support UTF-8 as > the default codepage by setting an option in the application manifest. > > To enable UTF-8 as the default codepage for JDK executables on Windows 10 > (starting with the May 2019 update) and Windows 11, the following > modifications can be made to the > src/java.base/windows/native/launcher/java.manifest file (or the > jdk/src/windows/resource/java.manifest in JDK 8): >... > > > xmlns:dpi1="http://schemas.microsoft.com/SMI/2005/WindowsSettings"; > > xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings"; > > xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings";> >true/PM >PerMonitorV2, PerMonitor, system >UTF-8 > > >... > > The GetACP() and GetOEMCP() API's will both return 65001 on Windows 10 > Version 1903 or later if UTF-8 > element is added to the executable manifest. > > GetLocaleInfo(lcid, LOCALE_IDEFAULTANSICODEPAGE, ret+2, 14) will return > different results from GetACP() if > UTF-8 is present in the executable > manifest, and java.nio.charset.Charset.defaultCharset() should return > StandardCharsets.UTF_8 on Windows platforms if GetACP() returns 65001. >
Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v7]
Just a nit, but how about: * For all interfaces use “-b 0.0.0.0“ (IPv4) or “-b ::“ (IPv6) Instead of: * For 0.0.0.0 (all interfaces) use -b 0.0.0.0 or -b ::0 In the usage? (I think „::“ is canon?) Gruss Bernd -- http://bernd.eckenfels.net Von: net-dev im Auftrag von Daniel Fuchs Gesendet: Tuesday, September 28, 2021 12:20:11 PM An: build-...@openjdk.java.net ; core-libs-dev@openjdk.java.net ; net-...@openjdk.java.net Betreff: Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v7] On Tue, 28 Sep 2021 10:08:29 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main method is run when the above >> command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given >> directory, similar to existing alternatives on other platforms and >> convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and >> customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge > or a rebase. The pull request now contains 20 commits: > > - use ipv4/ipv6 specific loopback address and add add how-to output for all > interfaces > - Merge branch 'master' into simpleserver > - change default bind address from anylocal to loopback > - address PR comments > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - Merge branch 'master' into simpleserver > - refactor isHidden,isReadable,isSymlink checks and cleanup tests > - Merge branch 'master' into simpleserver > - check isHidden, isSymlink, isReadable for all path segments > - ... and 10 more: > https://git.openjdk.java.net/jdk/compare/87998565...7f994476 Thanks Julia, the new changes look good to me. - Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5505
Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3]
I also wonder if it makes sense to either only serve files with public permissions, or at least Filter some critical files like .ssh/* and *.jks. Those command-line servers are often started „accidentially“ in the home directory. -- http://bernd.eckenfels.net Von: net-dev im Auftrag von Jaikiran Pai Gesendet: Thursday, September 16, 2021 4:08:46 PM An: build-...@openjdk.java.net ; core-libs-dev@openjdk.java.net ; net-...@openjdk.java.net Betreff: Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3] On Thu, 16 Sep 2021 10:14:47 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main method is run when the above >> command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given >> directory, similar to existing alternatives on other platforms and >> convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and >> customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request incrementally with one additional > commit since the last revision: > > correct path handling src/jdk.httpserver/share/classes/module-info.java line 55: > 53: * [-o none|info|verbose] [-h to show > options] > 54: *Options: > 55: *-b, --bind-address- Address to bind to. Default: 0.0.0.0 (all > interfaces). I understand that the purpose of this simple server is for development and testing only. But even then, for security considerations, would it be more appropriate to default the bind address to a loopback address instead of making it accessible potentially to entire public? In the past, application servers which used to bind to all interfaces by default have now moved to using the loopback address as a default to avoid such accidental exposing of the server. - PR: https://git.openjdk.java.net/jdk/pull/5505
Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v5]
I like it, but I think you don’t Need the %n linebreak (at least the other fail message has none) -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Roger Riggs Gesendet: Donnerstag, September 16, 2021 6:13 PM An: core-libs-dev@openjdk.java.net Betreff: Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v5] > The intermittent test in java/lang/ProcessBuilder/Basic.java has identified > unexpected messages from a child Java VM > as the cause of the test failure. Attempts to control the output of the > child VM have failed, the VM is unrepentant . > > There is no functionality in the child except to wait long enough for the > test to finish and the child is destroyed. > The fix is to switch from using a Java child to using a native child; a new > executable `sleepmillis`. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Improve diagnostic message to add the exit value of the process. The test will fail if the process has terminated early. (It would have failed anyway due to too short wait). - Changes: - all: https://git.openjdk.java.net/jdk/pull/5239/files - new: https://git.openjdk.java.net/jdk/pull/5239/files/2a9c33fb..43a54802 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5239&range=03-04 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5239/head:pull/5239 PR: https://git.openjdk.java.net/jdk/pull/5239
Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4]
The message should probably more along the line of be „external sleep process
terminated unexpected early“. But maybe it is better to actually fail the test
when true is returned as it should not happen instead of diag output? (And for
diag output the exit code would be more helpful than the time)
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von David
Holmes
Gesendet: Donnerstag, September 16, 2021 1:01 AM
An: core-libs-dev@openjdk.java.net
Betreff: Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v4]
On Wed, 15 Sep 2021 22:36:14 GMT, Roger Riggs wrote:
>> test/jdk/java/lang/ProcessBuilder/Basic.java line 2452:
>>
>>> 2450:
>>> 2451: if (p.waitFor(10, TimeUnit.MILLISECONDS)) {
>>> 2452: System.out.println("WaitFor didn't wait long enough:
>>> " + (System.nanoTime() - start));
>>
>> Either the condition or the message seems wrong here. If waitFor returns
>> true then the process has exited and we obviously did wait long enough.
>
> This code is diagnostic.
> After switching to native sleep, I had intermittent failures claiming it did
> not sleep long enough.
> I was unable to find a specific cause for those failures.
> Many of the tests fail to check if the sleep processes terminate prematurely
> and if the executable is not found, it never launched.
Okay but my comment still stands.
-
PR: https://git.openjdk.java.net/jdk/pull/5239
Re: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time
Is there support for repeatable builds planned? Using the source file might be acceptable, but the class file timestamp could be changing more likely for repeated builds? -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Jaikiran Pai Gesendet: Monday, September 13, 2021 7:44:22 AM An: compiler-...@openjdk.java.net ; core-libs-dev@openjdk.java.net Betreff: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117. The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor. This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here: 1. When creating a jar (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases. If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry. - Commit messages: - 8258117: jar tool sets the time stamp of module-info.class entries to the current time Changes: https://git.openjdk.java.net/jdk/pull/5486/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258117 Stats: 317 lines in 2 files changed: 298 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5486.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486 PR: https://git.openjdk.java.net/jdk/pull/5486
Re: Proposal: JDK-8231640 - (prop) Canonical property storage
BTW it is probably not a good idea to overwrite Properties (for example to get a defined store order). Especially since changes in the past already broke this. However the attached discussion shows that people do need insert-order and/or alphabetical ordered properties — maybe a more general solution would help (and also make sure that existing implementations which subtype Properties and overwrite entrySet() would continue to work? After all properties is/was not final. https://stackoverflow.com/questions/17011108/how-can-i-write-java-properties-in-a-defined-order On a somewhat related note, I think if the Properties class is not deterministic, preserves order and comments, it’s maybe not a good file,creation APi for Maven anyway. What Plug-ins are affected for which operation? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Roger Riggs Gesendet: Monday, August 30, 2021 5:00:14 PM An: Jaikiran Pai ; core-libs-dev@openjdk.java.net Betreff: Re: Proposal: JDK-8231640 - (prop) Canonical property storage Hi Jaikiran, System properties, especially new ones, should be only settable on the command line and read once. It makes them visible to developers and avoids state-full dependencies and concurrency issues. Retiring system properties is quite difficult because there's no way to know if they are still being used or by whom. The technique using system properties to revert to previous behavior has been used when API changes are unavoidable and the impact on existing applications is not known. It isn't a good solution but does provide a workaround when an issue is discovered. Better to not introduce them in the first place. The use of SOURCE_DATE_EPOCH as proposed seems better than most, as its definition has a wider scope and longer expected life than most properties. Since SOURCE_DATE_EPOCH is an environment variable, not a system property, it will be less visible to developers, but is already read-once at first use of any environment variable as per System.getenv(). $.02, Roger On 8/28/21 12:45 AM, Jaikiran Pai wrote: > Hello Roger, > > On 28/08/21 12:16 am, Roger Riggs wrote: >> Hi, >> >> I'm finding the idea of removing the hardcoded timestamp and adding a >> property to restore compatibility >> strangely attractive. I don't think we've yet found a case where the >> timestamp was needed (but need to keep looking). >> (Adding a timestamp to the comment by the caller of store() is >> already possible) >> >> It will reveal where the timestamp is needed (via some kind of >> failure, though perhaps not a timely one) >> and includes a fallback mechanism when needed. >> >> It will generally cleanup up the behavior of an old API. >> The other approaches make new work for developers based on unclear >> requirements. > > So this is essentially the proposal 1d that I listed in one of my > mails, with the added advantage of allowing users to switch back to > the old behaviour with a system property setting. I hadn't considered > the system property approach to switch to old behaviour in my > proposals, so this is a very good input and I personally think the > most logical proposals so far. One question that however remains is, > how long (how many releases) do we support this new system property? > The --illegal-access option (although not a system property) seems to > be one such example where after a few releases, that option will no > longer be supported and won't play any role. Perhaps this system > property too will follow a similar lifetime? > > One other thing - I believe this new system property must be "set once > at launch time" kind of property, whose value can be set at launch > time and cannot be changed dynamically in the runtime. That would > provide consistency in how the Properties class behaves globally > within that runtime, instead of potentially behaving differently in > different parts of the code, depending on how the callers set/reset > the system property value before calling the "store(...)" APIs. > > -Jaikiran > >
Re: what does the spec say about file paths that are too long?
I think what constitutes a „too long path“ is highly environment and data dependent. For some OS it depends on configuration, version, filesystem type, mount structure, encoding, canonicalisation and API used. Java would have a really hard time to codify this all. So the current solution „try the native API and report errors“ sounds like the only really useable option - not to mention it is also safe (you get an error no crash). There are some unfortunate problems like OS where the gui limits more like the OS (Explorer) or where one path type (UNC or DOS-Short or relative) can create longer path than later readable, but basically for them it’s also hard for Java to predict and forbid them (especially if used intentionally). What could be done is to document this, document which functions actually use OS APIs and possibly and which Path And Filesystem API does or does not. And hopefully the IOException and native error Handling can be Unified and improved (for example Expose Errno/HERR return codes in IOException attribute which avoids to parse (localized error messages). It’s a bit annoying but even if you want to handle it better: there is not much you can do if you have such a Path constructed. Limit inputs and install dirs and not use user provided names if your systems should be reliable. -- https://Bernd.eckenfels.net From: core-libs-dev on behalf of Alan Snyder Sent: Thursday, August 26, 2021 12:12:33 AM To: core-libs-dev Subject: Re: what does the spec say about file paths that are too long? Lacking any new data, I guess it is fair to assume that there is no specification for the behavior of methods that use file paths that are too long, and presumably no tests, either. So the next question is whether there should be such a specification. I think there should be a specification because I would like to be able to use file paths without having to defend against possible unwanted bad effects when the paths are too long. By analogy, more like array indexing than integer overflow. If there is to be a specification, should it be at the method level? That would be best, I think. For example, the Path.toAbsolutePath() method in principle could return a path that is “too long” even if the original path is fine. Should an exception be raised at that point or only when the absolute path is used? This distinction was not possible with File, but it may be possible with Path, given the association with file providers. (Regarding the comment from Alan B., is it the case that file paths are necessarily resolved before use? That would surprise me.) Also, there is the possibility of creating a more specific exception to be thrown when paths that are too long are used. A case can be made for distinguishing this error from general IOExceptions because it is repeatable and explainable, unlike the general IOException. Thoughts? Alan > On Aug 20, 2021, at 7:05 AM, Alan Snyder wrote: > > Where did I say that I was seeing silent truncation? > > My question is about the specification. > > I want to know if I should write code that defends against silent truncation. > I should be writing code based on the specification, not what I observe in a > test program on a particular platform. > > I’m pleased that you believe an exception should be thrown, but is that > behavior mandated in the specification and tested by the JCK? > > Alan > > >> On Aug 20, 2021, at 2:58 AM, Alan Bateman wrote: >> >> Where are you seeing "silent truncation"? You should see an I/O exception if >> you attempt to access a file and the resolved file path is too long. >> >> -Alan >> >
Re: RFR: 8266936: Add a finalization JFR event [v4]
Hello, I know I am a bit late, but just wanted to mention, that since finding finalizers with Bytecode analysis is doable (and probably easier to deal with such scan reports), I don’t see much value in a JFR event, especially considering it even has native code executed. (Not so sure about dynamically loaded classes, would the event content help to identify sources?) Having said that, this event would be more useful from a runtime perspective if It would actually record execution counts and time per class. Then one can concentrate on the worst offenders, first and even use it for runtime monitoring. Is there already a finalizer profiler? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Markus Grönlund Gesendet: Tuesday, July 27, 2021 5:14:29 PM An: core-libs-dev@openjdk.java.net ; hotspot-jfr-...@openjdk.java.net Betreff: Re: RFR: 8266936: Add a finalization JFR event [v4] > Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to > replace and mitigate Object.finalize() uses in the JDK libraries; please see > https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mitigating uses in non-JDK code. > > Hence, this changeset adds a periodic JFR event to help identify which > classes are overriding Object.finalize(). > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision: remove build directive - Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/58fc3f0a..44988036 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731 PR: https://git.openjdk.java.net/jdk/pull/4731
Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v8]
Hello,
> So although you can transfer the contents to the file without requiring the
> access
> to the byte array, you end up creating a new copy of that array (through the
> use
> of `baos.toByteArray()`)
You can avoid the copy and the additional buffer with baos.writeTo() I think.
try (OutputStream os = Files.newOutputStream(entry.file)) { // maybe append?
baos.writeTo(os);
}
// release the underlying byte array
baos = null;
// append any further data to the file with buffering enabled
tmpFileOS = new BufferedOutputStream(Files.newOutputStream(entry.file, APPEND));
--
http://bernd.eckenfels.net
Von: nio-dev im Auftrag von Jaikiran Pai
Gesendet: Thursday, July 22, 2021 2:55:46 PM
An: core-libs-dev@openjdk.java.net ;
nio-...@openjdk.java.net
Betreff: Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
leads to a negative initial size for ByteArrayOutputStream [v8]
On Wed, 21 Jul 2021 04:09:23 GMT, Jaikiran Pai wrote:
> > > For some context - the new `FileRolloverOutputStream` extends
> > > `ByteArrayOutputStream` and hence cannot have a `throws IOException` in
> > > its overridden `write` methods.
> >
> >
> > Have you tried wrapping a BAOS rather than extending, that might allow the
> > exception wrapping/unwapping to go away.
>
> Hello Alan,
>
> I did experiment with it earlier, before going with the current approach in
> this PR. The disadvantage, as I see it, with wrapping a
> `ByteArrayOutputStream` instead of extending it is that when trying to
> rollover the contents to a file, you don't have access to the (inner
> protected) byte array of the ByteArrayOutputStream.
>
> The rollover code would then look something like:
>
> ```
> private void transferToFile() throws IOException {
> // create a tempfile
> entry.file = getTempPathForEntry(null);
> // transfer the already written data from the byte array buffer into this
> tempfile
> try (OutputStream os = new
> BufferedOutputStream(Files.newOutputStream(entry.file))) {
> new ByteArrayInputStream(baos.toByteArray(), 0,
> baos.size()).transferTo(os);
> }
> // release the underlying byte array
> baos = null;
> // append any further data to the file with buffering enabled
> tmpFileOS = new BufferedOutputStream(Files.newOutputStream(entry.file,
> APPEND));
> }
> ```
>
> So although you can transfer the contents to the file without requiring the
> access to the byte array, you end up creating a new copy of that array
> (through the use of `baos.toByteArray()`), which can be at most 10MB in size.
> I thought avoiding a new copy of that (potentially 10MB) array during this
> transfer would be a good save and hence decided to settle on extending
> `ByteArrayOutputStream` instead of wrapping it.
>
> The use of `extends` of course now means dealing with the
> `UncheckedIOException` as done in this PR. But if you think that the array
> copy isn't a concern and wrapping the `ByteArrayOutputStream` is a better
> way, then I'll go ahead and update this PR accordingly.
Now that the mailing lists integration seems to be back to normal, just adding
this dummy comment to bring to attention the latest comments in this PR.
-
PR: https://git.openjdk.java.net/jdk/pull/4607
Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller
Hello, sorry for being unpopular, but I just hate it to waste developer resources, I realy think this deprecation message should be re-considered, it broke a lot of things, the amount of work to implement a caching solution feels like a waste of time and on top of it, there is no clear replacement strategy published yet. I would restrict deprication (for removal if you really insist) to javadoc and not poison stdout/stderr. I think we stirred up enough PR that a message was received by maintainers, no need to further damage java reputation by breaking perfectly working inter process interfaces. (This is btw true for all such warnings). And I also think top priority should be to publish a go-forward route which should not depend solely on MR-Jars, Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Daniel Fuchs Gesendet: Tuesday, June 29, 2021 8:50:08 PM An: core-libs-dev@openjdk.java.net ; security-...@openjdk.java.net Betreff: Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang wrote: > Add a cache to record which sources have called `System::setSecurityManager` > and only print out warning lines once for each. src/java.base/share/classes/java/lang/System.java line 337: > 335: = Collections.synchronizedMap(new WeakHashMap<>()); > 336: } > 337: I wonder about the use of a WeakHashMap here. That may work well when the source is an interned string (a class name) which will be strongly referenced elsewhere and may be garbage collected if the class is unloaded, but in the case where it contains the name of the source jar then that string will only be referenced by the weak hashmap, and therefore it could be garbage collected any time - which would cause the mapping to be removed. In that case you cannot guarantee that the warning will be emitted only once. - PR: https://git.openjdk.java.net/jdk17/pull/166
Re: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams
Hello,
Hm, how is that list used? - StandardCharaet.ISO_8859_1 is a guaranteed Charset
for JVM, and since the encoding is done in Java it should be fine. Added
benefit is, it’s 8bit transparent.
As for OS there is not a single standard charset (ebcdic vs latin families) but
ASCII is probably the widest available (with latin1 variants to follow)
--
https://Bernd.eckenfels.net
From: core-libs-dev on behalf of Roger
Riggs
Sent: Thursday, May 20, 2021 10:52 PM
To: core-libs-dev@openjdk.java.net
Subject: Re: RFR: 8191441: (Process) add Readers and Writer access to
java.lang.Process streams
On Thu, 20 May 2021 20:42:35 GMT, Naoto Sato wrote:
>> Methods are added to java.lang.Process to read and write characters and
>> lines from and to a spawned Process.
>> The Charset used to encode and decode characters to bytes can be specified
>> or use the
>> operating system native encoding as is available from the "native.encoding"
>> system property.
>
> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 64:
>
>> 62: return new Object[][] {
>> 63: {"UTF-8"},
>> 64: {"ISO8859-1"},
>
> `ISO8859-1` may not be available on all underlying OSes.
Is there a safe subset?
I haven't seen a failure yet, if/when it occurs, we make an exception or narrow
the test to known systems.
> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 111:
>
>> 109: @Test(dataProvider = "CharsetCases", enabled = true)
>> 110: void testCase(String nativeEncoding) throws IOException {
>> 111: String osName =
>> System.getProperty("os.name").toLowerCase(Locale.ROOT);
>
> Not used anywhere else.
Right, dead code now without host dependencies.
> test/jdk/java/lang/ProcessBuilder/ReaderWriterTest.java line 122:
>
>> 120: "ReaderWriterTest$ChildWithCharset");
>> 121: var env = pb.environment();
>> 122: env.put("LANG", "en_US." + cleanCSName);
>
> Does this work on Windows?
Should be removed, the tests work because they set sun.stdout/stderr.encoding.
-
PR: https://git.openjdk.java.net/jdk/pull/4134
Re: RFR: 8264208: Console charset API [v2]
Hello, I like the API, it is useful, however not enough to replace the defaultCharset once the Change to UTF8 is done. You still need a way to query the platforms file encoding (especially on Windows). Also I wonder if the Javadoc needs to discuss platform aspects of console, especially System.out and LANG on unix vs. windows. Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Naoto Sato Gesendet: Friday, April 9, 2021 11:06:00 PM An: core-libs-dev@openjdk.java.net ; security-...@openjdk.java.net Betreff: Re: RFR: 8264208: Console charset API [v2] > Please review the changes for the subject issue. This has been suggested in > a recent discussion thread for the JEP 400 > [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. > A CSR has also been drafted, and comments are welcome > [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflected the review comments. - Changes: - all: https://git.openjdk.java.net/jdk/pull/3419/files - new: https://git.openjdk.java.net/jdk/pull/3419/files/d6db04bb..8fd8f6e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3419&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419 PR: https://git.openjdk.java.net/jdk/pull/3419
Re: New candidate JEP: 400: UTF-8 by Default
Hello, Thanks for the hint. The question is if this would return UTF-8 after the JEP is implemented or not (should probably be mentioned in the JEP). If it keeps returning the legacy/platform file encoding that would be a good API for my purpose (but sounds like that would be rather confusing in regards to the default constructor) -- http://bernd.eckenfels.net Von: Remi Forax Gesendet: Thursday, March 11, 2021 2:19:19 AM An: Bernd Eckenfels Cc: core-libs-dev ; jdk-dev Betreff: Re: New candidate JEP: 400: UTF-8 by Default - Mail original - > De: "Bernd Eckenfels" > À: "core-libs-dev" > Cc: "jdk-dev" > Envoyé: Jeudi 11 Mars 2021 02:12:49 > Objet: Re: New candidate JEP: 400: UTF-8 by Default > I like it. The only thing which I feel is missing would be an official API to > get the operating environments default encoding (essentially to get the value > used if COMPAT would have been specified). > > For example, in our server application, we do have some code which is > specified > as using exactly this charset (I.e. if user configures > targetEncoding=PLATFORM > we are using intentionally the no-arg APIs). We can change that code to > specify > a Charset, but then we need a way to retrieve that - without poking into > unsupported system properties or environment properties. For example > System.platformCharset(). > > I understand that this might have it’s own complications - as not all OS have > this concept (for example on Windows there might be different codepages > depending on the unicode status of an application). But falling back to > today’s > file.encoding code would at least be consistent and the behavior most > implementer would desire when adapting legacy code to this JEP. Hi, FileReader has a method named getEncoding() > > Gruss > Bernd > -- > http://bernd.eckenfels.net regards, Rémi
Re: New candidate JEP: 400: UTF-8 by Default
I like it. The only thing which I feel is missing would be an official API to get the operating environments default encoding (essentially to get the value used if COMPAT would have been specified). For example, in our server application, we do have some code which is specified as using exactly this charset (I.e. if user configures targetEncoding=PLATFORM we are using intentionally the no-arg APIs). We can change that code to specify a Charset, but then we need a way to retrieve that - without poking into unsupported system properties or environment properties. For example System.platformCharset(). I understand that this might have it’s own complications - as not all OS have this concept (for example on Windows there might be different codepages depending on the unicode status of an application). But falling back to today’s file.encoding code would at least be consistent and the behavior most implementer would desire when adapting legacy code to this JEP. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von mark.reinh...@oracle.com Gesendet: Thursday, March 11, 2021 1:27:05 AM An: naoto.s...@oracle.com Cc: core-libs-dev@openjdk.java.net ; jdk-...@openjdk.java.net Betreff: New candidate JEP: 400: UTF-8 by Default https://openjdk.java.net/jeps/400 Summary: Use UTF-8 as the JDK's default charset, so that APIs that depend on the default charset behave consistently across all platforms and independently of the user’s locale and configuration. - Mark
Re: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module
Hello, Actually, in HTML was a separator, and in xhtml it should enclose paragraphs. However I was under the impression Javadoc always used the separator style (it would be strange to start the first sentence in Javadoc with . Is this doccheck enforcing a new policy? This officially Oracle guide for example has a different example: https://www.oracle.com/de/technical-resources/articles/java/javadoc-tool.html#format Gruss Bernd -- http://bernd.eckenfels.net Von: net-dev im Auftrag von Jonathan Gibbons Gesendet: Tuesday, March 2, 2021 8:41:03 PM An: core-libs-dev@openjdk.java.net ; hotspot-compiler-...@openjdk.java.net ; net-...@openjdk.java.net ; security-...@openjdk.java.net Betreff: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module Please review some minor doc fixes, for issues found by _doccheck_.There are two kinds of errors that are addressed. 1. Incorrect use of ``. In HTML, `` marks the *beginning* of a paragraph. It is not a terminator, to mark the end of a paragraph, or a separator to mark the boundary between paragraphs. In particular, it should not be used at the end of a description before a javadoc block tag, such as `@param` or before other HTML block tags, like `` or ``. 2. References to the id `package-description`, following the recent standardization of all ids generated by javadoc, - Commit messages: - JDK-8262875: doccheck: empty paragraphs, etc in java.base module Changes: https://git.openjdk.java.net/jdk/pull/2795/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2795&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262875 Stats: 9 lines in 8 files changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2795/head:pull/2795 PR: https://git.openjdk.java.net/jdk/pull/2795
Re: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and ==
I like the text it’s good to mix object and value identities. I would only miss
unequal behavior of NaN in the description.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von Joe
Darcy
Gesendet: Thursday, January 28, 2021 8:17:39 AM
An: core-libs-dev@openjdk.java.net
Betreff: Re: RFR: JDK-8257086: Clarify differences between {Float,
Double}.equals and ==
On Thu, 10 Dec 2020 01:32:24 GMT, Stuart Marks wrote:
>
>
> Great, let me know if you'd like me to provide some text for any particular
> topics in this area.
Before sending out another iteration in code, there the draft javadoc text of a
discussion at the end of the class-level discussion of java.lang.Double:
* Floating-point Equality, Equivalence,
* and Comparison
*
* IEEE 754 floating-point values include finite nonzero values,
* signed zeros ({@code +0.0} and {@code -0.0}), signed infinities
* {@linkplain Double#POSITIVE_INFINITY positive infinity} and
* {@linkplain Double#NEGATIVE_INFINITY negative infinity}), and
* {@linkplain Double#NaN NaN} (not-a-number).
*
* An equivalence relation on a set of values is a boolean
* relation on pairs of values that is reflexive, symmetric, and
* transitive. A set can have multiple equivalence relations defined
* for it. For example, {@link java.util.HashMap HashMap} compares
* keys in the set of objects using the equivalence relation of {@link
* Object#equals Object.equals} while {@link java.util.IdentityHashMap
* IdentityHashMap} compares keys in the set of objects using the
* equivalence relation of reference equality.
*
* For floating-point values to be used in data structures like
* sets and maps, the {@linkplain Double#equals equals} or {@linkplain
* Double#compareTo comparison} method must satisfy the usual
* requirements of being an equivalence relation or analogous
* requirement for comparison methods. However, surprisingly, the
* built-in {@code ==} operation on floating-point values does
* not implement an equivalence relation. Despite not
* defining an equivalence relation, the semantics of the IEEE 754
* {@code ==} operator were deliberately designed to meet other needs
* of numerical computation. There are two exceptions where the
* properties of an equivalence relations are not satisfied by {@code
* ==} on floating-point values:
*
*
*
* If {@code v1} and {@code v2} are both NaN, then {@code v1
* == v2} has the value {@code false}. Therefore, for two NaN
* arguments the reflexive property of an equivalence
* relation is not satisfied by the {@code ==} operator.
*
* If {@code v1} represents {@code +0.0} while {@code v2}
* represents {@code -0.0}, or vice versa, then {@code v1 == v2} has
* the value {@code true} even though {@code +0.0} and {@code -0.0}
* are distinguishable under various floating-point operations. For
* example, {@code 1.0/+0.0} evaluates to positive infinity while
* {@code 1.0/-0.0} evaluates to negative infinity and
* positive infinity and negative infinity are neither equal to each
* other nor equivalent to each other.
*
*
*
* For ordered comparisons using the built-in comparison operator
* ({@code <}, {@code <=}, etc.), NaN values have another anomalous
* situation: a NaN is neither less than, greater than, nor equal to
* any value, including itself. This means the trichotomy of
* comparison does not hold.
*
* To provide the appropriate semantics for {@code equals} and {@code
* compareTo} methods, those methods cannot simply to wrappers around
* {@code ==} or ordered comparison operations. Instead, {@link
* Double#equals equals} defines NaN arguments to be equal to each
* other and defines {@code +0.0} to not be equal to {@code
* -0.0}, restoring reflexivity. For comparisons, {@link
* Double#compareTo compareTo} defines a total order where {@code
* -0.0} is less than {@code +0.0} and where a NaN is equal to itself
* and considered greater than positive infinity.
*
* The operational semantics of {@code equals} and {@code
* compareTo} are expressed in terms of {@linkplain doubleToLongBigs
* bit-wise converting} the floating-point values to integral values
*
* The natural ordering implemented by {@link compareTo
* compareTo} is {@linkplain Comparable consistent with equals}; that
* is values are only reported as equal by {@code equals} if {@code
* compareTo} on those objects returns zero.
*
* @jls 4.2.3 Floating-Point Types, Formats, and Values
* @jls 4.2.4. Floating-Point Operations
* @jls 15.21.1 Numerical Equality Operators == and !=
Comments?
Thanks,
-
PR: https://git.openjdk.java.net/jdk/pull/1699
Re: JNLP
Hello, We ported a big JWS gui app to stand-alone swing with a home made installer/update mechanism. This was very easy to do (it had a main method for debugging anyway). The installer is not the most comfortable, but we can live with it since the whole application will be replaced by an web app anyway. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Thomas Vatter Gesendet: Thursday, December 10, 2020 1:12:45 PM An: core-libs-dev@openjdk.java.net Betreff: JNLP I'm using JNLP, how should I go on? -- Network Inventory Software IBM-Partner, RedHat- und SUSE-Partner, Oracle Technet Member www.network-inventory.de<http://www.network-inventory.de> Tel. 030-79782510 Fax 030-79782512 E-Mail: thomas.vat...@network-inventory.de
Re: RFR: JDK-8255395 Implement Enhanced Pseudo-Random Number Generators (CSR)
Hello, Not sure if it is needed to implement a new RandumGenerator interface instead of extending SecureRandom, but the extensions and the discovery mechanism looks good. One thing I am wondering about is if reseed() and reseed(Param) should be part of the new RandomGenerator interface as well. BTW a lot of the random number Discovery and configuration could have been avoided when the actual implementation just would have been stronger and less blocking. The focus should be on the two old factory methods to make them return top quality, it’s hard enough to make everyone use them for the correct use case. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Jim Laskey Gesendet: Thursday, November 5, 2020 2:02:24 PM An: core-libs-dev Betreff: RFR: JDK-8255395 Implement Enhanced Pseudo-Random Number Generators (CSR) Please review the CSR for JEP-356 Enhanced Pseudo-Random Number Generators. Thank you. -- Jim CSR: https://bugs.openjdk.java.net/browse/JDK-8255395 <https://bugs.openjdk.java.net/browse/JDK-8255395> JBS: https://bugs.openjdk.java.net/browse/JDK-8248862 <https://bugs.openjdk.java.net/browse/JDK-8248862> JEP: http://openjdk.java.net/jeps/356 <http://openjdk.java.net/jeps/356>
Re: jpackage OS X codesign IOException
Looks like the codesign command is not in your PATH Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Michael Hall Gesendet: Saturday, September 26, 2020 1:57:06 PM An: core-libs-dev@openjdk.java.net Betreff: jpackage OS X codesign IOException java.io.IOException: Command [codesign, -s, Developer ID Application: X (X), -, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage16414030388823297270/images/image-1807061985031173/HalfPipe.app] exited with 1 code X values changed by me
Fwd: RFR: 8223187: Investigate setLocale() call in jpackage native launcher
Hello, What about system errors (exception messages from strerr?). I mean in case one wants to enforce English version with user.locale for support reasons? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Alexander Matveev Gesendet: Saturday, September 12, 2020 4:22:31 AM An: core-libs-dev@openjdk.java.net Betreff: RFR: 8223187: Investigate setLocale() call in jpackage native launcher setlocale() affects several C functions. We do not use most of these functions. We only using isspace() and toLower(). Based on how we use it I do not see any needs for setlocale(). After removing it I retested jpackage by changing locally on machine and using different language as input parameters for jpackage. No issues found. - Commit messages: - 8223187: Investigate setLocale() call in jpackage native launcher Changes: https://git.openjdk.java.net/jdk/pull/138/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=138&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223187 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/138.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/138/head:pull/138 PR: https://git.openjdk.java.net/jdk/pull/138
Re: Language locales have different calendars than country locales in 9+
Hello,
Is there a good description what calendar is actually used for a language-only
locale? Is there a typical association of calendars with locales or is it a
global default? If the unicode data does not have such a value, would it be
better to fall back to the next provider (like COMPAT)?
I understand that it was hinted at in the release notes, but this is a very
severe change in major locales - at least I was not expecting that (as opposed
to textual changes to timezones or month names).
I am a bit burned by using compat flags as they might get removed in the futur,
is there any plans on how long the JRE locale provider will be available, I.e.
ist it s safe bet to use it?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: naoto.s...@oracle.com
Gesendet: Friday, July 31, 2020 11:24:33 PM
An: Bernd Eckenfels ; core-libs-dev
Betreff: Re: Language locales have different calendars than country locales in
9+
Hi Bernd,
As you pointed out, the change you see here is the result of this change
in JDK9:
https://bugs.openjdk.java.net/browse/JDK-8008577
where the default locale provider was switched to CLDR. Although we
don't describe those behavior changes in the spec (as it is regarded as
l10n changes which may differ across implementations), it was generally
noted in JDK9's release note:
---
As a result, users may see differences in locale sensitive services
behavior and/or translations. [1]
---
You can use the COMPAT provider through the java.locale.providers system
property if you need the pre-JDK9 behavior.
HTH,
Naoto
[1] https://www.oracle.com/java/technologies/javase/v9-issues-relnotes.html
On 7/31/20 1:17 PM, Bernd Eckenfels wrote:
> Hello,
>
> Just wanted to mention a thing I noticed when switching from 8 to 11. I knew
> before that the Locale data provider has changed, and I could notice that for
> example in the writing style for abbreviated words in dates. However
> something I did not expect is, that the definition of Calemdars change as
> well.
>
> Locale.GERMAN and Locale.GERMANY construct different calemdars under Java 11
> with CLDR as opposed to Java 8 or Java 11 with compat. The most notably
> changes are when calculating calendar weeks (min days in first week) or the
> start of a week (Sunday vs. Monday).
>
> I haven't seen that explicitely mentioned and I also wonder if this should be
> mentioned in the Locale JavaDoc that language locales and country locales
> might differ severely in that aspect.
>
>
> GERMANY:
> Calendar.minDays 4
> java.util.GregorianCalendar[time=1596218932830,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=…,firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=830,ZONE_OFFSET=360,DST_OFFSET=360]
> 11.0.1+13-LTS de_DE 2011-01-01 2010-52
>
> GERMAN
> Calendar.minDays 1
> java.util.GregorianCalendar[time=1596218932879,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=...,firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=879,ZONE_OFFSET=360,DST_OFFSET=360]
> 11.0.1+13-LTS de2011-01-01 2011-01
>
> Sample code:
>
> Date d = new Date(129384360L);
>
> Locale l = Locale.GERMANY;
>
> Calendar c = Calendar.getInstance(l);
> System.out.println("Calendar.minDays "+ c.getMinimalDaysInFirstWeek() +
> " " + c);
>
> SimpleDateFormat sdf = newSimpleDateFormat("-MM-DD -ww", l);
> System.out.printf("%s %-5s %s%n", System.getProperty("java.vm.version"),
> l, sdf.format(d));
>
>
> --
> http://bernd.eckenfels.net
>
Language locales have different calendars than country locales in 9+
Hello,
Just wanted to mention a thing I noticed when switching from 8 to 11. I knew
before that the Locale data provider has changed, and I could notice that for
example in the writing style for abbreviated words in dates. However something
I did not expect is, that the definition of Calemdars change as well.
Locale.GERMAN and Locale.GERMANY construct different calemdars under Java 11
with CLDR as opposed to Java 8 or Java 11 with compat. The most notably changes
are when calculating calendar weeks (min days in first week) or the start of a
week (Sunday vs. Monday).
I haven't seen that explicitely mentioned and I also wonder if this should be
mentioned in the Locale JavaDoc that language locales and country locales might
differ severely in that aspect.
GERMANY:
Calendar.minDays 4
java.util.GregorianCalendar[time=1596218932830,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=…,firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=830,ZONE_OFFSET=360,DST_OFFSET=360]
11.0.1+13-LTS de_DE 2011-01-01 2010-52
GERMAN
Calendar.minDays 1
java.util.GregorianCalendar[time=1596218932879,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=...,firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2020,MONTH=6,WEEK_OF_YEAR=31,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=213,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=8,HOUR_OF_DAY=20,MINUTE=8,SECOND=52,MILLISECOND=879,ZONE_OFFSET=360,DST_OFFSET=360]
11.0.1+13-LTS de2011-01-01 2011-01
Sample code:
Date d = new Date(129384360L);
Locale l = Locale.GERMANY;
Calendar c = Calendar.getInstance(l);
System.out.println("Calendar.minDays "+ c.getMinimalDaysInFirstWeek() + " "
+ c);
SimpleDateFormat sdf = newSimpleDateFormat("-MM-DD -ww", l);
System.out.printf("%s %-5s %s%n", System.getProperty("java.vm.version"), l,
sdf.format(d));
--
http://bernd.eckenfels.net
Re: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0
It does not sound aligned if you allow to change the op code which is compared in equal() but remember the hashcode. But I guess it would be best to use a IdendityHashMap if you care for the objects. In that case you can implement hashcode uncached and aligned with equals. (And not use it) Gruss Bernd -- http://bernd.eckenfels.net Von: Joe Wang Gesendet: Friday, June 26, 2020 8:29:41 AM An: Bernd Eckenfels ; Core-Libs-Dev Betreff: Re: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0 On 6/25/2020 5:14 PM, Bernd Eckenfels wrote: > Hello, > > What is the advantage of having such a narrow hashcode value space compared > to the built in idendity hashcode? Would stocking to the object idendity not > only reduce the footprint, but also make hash lookups faster? Without the > unclear relationship to the op code? It's a general contract to override hashCode() when equals() is overridden, although due to the hacky nature the later was implemented and also the narrow scope it was applied in the (BCEL) code it didn't provide more than the Object identity. Still, it's right to keep the hashCode() method along with equals(), would have allowed all other subtypes to behave correctly, and beneficial to others who may read the code (who might wonder why it's missing). It's a bit improvement over no hashCode(). -Joe > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > > Von: core-libs-dev im Auftrag von Joe > Wang > Gesendet: Friday, June 26, 2020 1:53:08 AM > An: Core-Libs-Dev > Betreff: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL > 6.0 > > Hi, > > Please review a fix to a BCEL regression. At issue was the addition of > hashCode() method to Instruction.java in BCEL 6.0. This hashCode() > method was implemented to return the instruction's opcode that > unfortunately is mutable. The problem hasn't showed up until the code > path led to calls to remove from a HashSet a target that has been > changed since it was added to the HashSet. The proposed patch is to make > the hashCode final/immutable. > > This patch implies that a target object is considered the same one even > if its field values may have been changed. It therefore may not be > appropriate in other situations (or may cause problems). However, since > it had always had no hashCode() override before BCEL 6.0, thereby > relying on Object's identity hash code, its use case has been limited > and time-tested. It can benefit from this patch in that it provides the > same function as Object's hash code, and then serves as a reminder (to > any who might read the code) how it was used (objects considered to be > the same over the course as far as the hashCode is concerned). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248348 > webrevs: http://cr.openjdk.java.net/~joehw/jdk16/8248348/webrev/ > > Thanks, > Joe >
Re: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0
Hello, What is the advantage of having such a narrow hashcode value space compared to the built in idendity hashcode? Would stocking to the object idendity not only reduce the footprint, but also make hash lookups faster? Without the unclear relationship to the op code? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Joe Wang Gesendet: Friday, June 26, 2020 1:53:08 AM An: Core-Libs-Dev Betreff: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0 Hi, Please review a fix to a BCEL regression. At issue was the addition of hashCode() method to Instruction.java in BCEL 6.0. This hashCode() method was implemented to return the instruction's opcode that unfortunately is mutable. The problem hasn't showed up until the code path led to calls to remove from a HashSet a target that has been changed since it was added to the HashSet. The proposed patch is to make the hashCode final/immutable. This patch implies that a target object is considered the same one even if its field values may have been changed. It therefore may not be appropriate in other situations (or may cause problems). However, since it had always had no hashCode() override before BCEL 6.0, thereby relying on Object's identity hash code, its use case has been limited and time-tested. It can benefit from this patch in that it provides the same function as Object's hash code, and then serves as a reminder (to any who might read the code) how it was used (objects considered to be the same over the course as far as the hashCode is concerned). JBS: https://bugs.openjdk.java.net/browse/JDK-8248348 webrevs: http://cr.openjdk.java.net/~joehw/jdk16/8248348/webrev/ Thanks, Joe
Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
LdapCtxt:
2568 /**
2569 * Sets the read timeout value
2570 */
2571 private void setChannelBindingType(String cbTypeProp) {
Not sure if that javadoc is the right one? And I also wonder if enforcing the
timeout is needed, and if yes if it should be documented why. Was not obvious
to me,
what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT
and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?)
This could be configured as a SASL property and it would add the benefit that
you don't need the instance specific if in the gssstub native code if you
instead have two different types values?
Gruss
Bernd
Von: security-dev im Auftrag von Alexey
Bakhtin
Gesendet: Mittwoch, Mai 27, 2020 11:43 AM
An: Valerie Peng
Cc: security-...@openjdk.java.net; core-libs-dev@openjdk.java.net; Thomas Maslen
Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
Hello Valerie, Unfortunately, Windows LDAP server with
LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type.
This is exact reason of these changes. I ve tried to fix inconsistency of
address type value in the latest webrev:
http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/
Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
Not completely sure about which of the involved apIs have what possible extensions. Maybe we can somehow make two mechanisms one which is the compatible default and one would be the rfc compliant method. Then SASL can be configured and use different mechanism names with a new propert? That would help jgss for the other mechanisms for channel bindings (cbt) as well. Not sure how jgss and JSSE will talk to each other.. via SASL? -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Alexey Bakhtin Gesendet: Tuesday, May 26, 2020 7:46:11 PM An: Weijun Wang Cc: security-...@openjdk.java.net ; core-libs-dev@openjdk.java.net ; Michael Osipov Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos Hello Max, Thank you review. If I understand correctly tls-server-end-point channel binding data is a hash of server certificate. Different SASL protocols could send cbData differently, with different prefix format. This is a reason I create TLSChannelBinding class and calculate hash from the LdapClient and add “tls-server-end-point:” prefix in the JGSS/Kerberos. Alexey > On 26 May 2020, at 17:50, Weijun Wang wrote: > > I have a question on GssKrb5Client.java: > > Do you think it's a good idea to let the SASL mechanism understand what TLS > binding is? Instead of passing the whole TlsChannelBinding object through a > SASL property, is it possible to only pass the actual cbData? After all, the > name "com.sun.security.sasl.channelbinding" suggests it's just a general > ChannelBinding which is independent with any application level info. > > From my reading of the code change, it looks like this cbData can be > calculated on the LDAP side. > > Thanks, > Max > >> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >> >> Hello, >> >> Could you please review the following patch: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >> >> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the >> tls-server-end-point channel binding >> (based on the TLS server certificate). The channel binding data is >> calculated as following : >> • The client calculates a hash of the TLS server certificate. >> The hash algorithm is selected on the base of the certificate >> signature algorithm. >> Also, the client should use SHA-256 algorithm, in case of the >> certificate signature algorithm is SHA1 or MD5 based >> • The channel binding information is the same as defined in rfc4121 >> [1] with small corrections: >> • initiator and acceptor addresses should be set to NULL >> • initiator and acceptor address types should be zero. >> It contradicts to the “Using Channel Bindings in GSS-API” >> document [2] that say that >> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >> instead of GSS_C_AF_UNSPEC=0x00. >> >> This patch introduces changes in the LDAP, SASL and JGSS modules >> to generate channel binding data automatically if requested by an >> application. >> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation >> but changes >> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to >> CHANNEL_BINDING_AF_UNSPEC. >> The patch introduces new environment property “com.sun.jndi.ldap.tls.cbtype” >> that indicates >> Channel Binding type that should be used in the LDAPS connection over >> JGSS/Kerberos. >> Right now "tls-server-end-point" Channel Binding type is supported only. >> The client extracts server certificate from the underlying TLS connection >> and creates >> Channel Binding data for JGSS/Kerberos authentication if application >> indicates >> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >> Client application should also specify existing >> "com.sun.jndi.ldap.connect.timeout” property >> to force and wait TLS handshake completion before JGSS/Kerberos >> authentication data is generated. >> >> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >> >> [2] - >> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >> >> Initial discussion of this issue is available at security-dev list: >> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html
Re: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds
Hello, I wonder why there are two times the same logic in internal public static methods. Maybe that could be consolidated as well? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Yangfei (Felix) Gesendet: Tuesday, March 10, 2020 3:54:54 AM An: core-libs-dev@openjdk.java.net Betreff: RFR(S): 8240734: ModuleHashes attribute not reproducible between builds Hi, We found module-info.class in java.base.jmod is not always consistent across different builds. The ModuleHashes attribute in this module-info.class is not reproducible between builds. Patch fixes the issue by using TreeMap instead of HashMap when computing ModuleHashes. Bug: https://bugs.openjdk.java.net/browse/JDK-8240734 Webrev: http://cr.openjdk.java.net/~fyang/8240734/webrev.00/ Passed tier1 test. Please review. Thanks, Felix
Re: jpackage current status
Hello Michael, Currently the native binaries (java launcher) are not included. If you want to do that, you need to generate the jlink image first (what you need to do anyway if you want a specific version). This is kind of by design, but it looks like if this can be configured in future versions. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Michael Hall Gesendet: Montag, Februar 24, 2020 9:33 PM An: Kevin Rushforth Cc: core-libs-dev Betreff: Re: jpackage current status > On Feb 24, 2020, at 1:48 PM, Michael Hall wrote: > > > >> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth >> wrote: >> >> Since your ToolProvider-based program doesn't explicitly require >> jdk.incubator.jpackage, it won't be in the module graph. It should work fine >> if you run with: >> >> $ java --add-modules jdk.incubator.jpackage ... >> > > I’m not understanding the module subtleties yet but yes that does work > command line. Other than -add-modules into the runtime are there any special > considerations for using it from an application? Ah, the obvious. Same solution for application also works. I can programmatically invoke jpackage with this. > > I am still wondering for the application embedded runtime exec not finding > linked native commands if this is expected not to work or is considered an > issue? > This remains a question for me. Should Runtime exec find the native commands included with an application embedded JRE? It currently doesn’t seem to on OS X.
Re: New candidate JEP: 371: Hidden Classes
Hello, I wonder will this (weak class) be useful for reflective method accessors and even be able to reduce/remove the need of jdk.internal.reflect.DelegatingClassLoaders? If so, that would be a good example to mention in the JEP (it only mentions Proxies). (And I was really surprised to see Nashorn mentioned after it is deprecated, even when it is certainly a good Test bed). Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von David Holmes Gesendet: Friday, January 24, 2020 11:56:07 PM An: hotspot-dev developers ; core-libs-dev Libs Betreff: Fwd: New candidate JEP: 371: Hidden Classes FYI. Cheers, David
Re: RFR [14/java.xml] 8233686: XML transformer uses excessive amount of memory
This does save object allocations and churn, not memory footprint I guess. The namespace mapping contains multiple stacks (with object arrays) and a hashtable and initialized records, so it seems to allocate a few kb on every node visited. (But 100MB allocation does sound like a very constructed case) BTW the thing I wondered, is there a process to keep xerces in sync? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Vyom Tiwari Gesendet: Freitag, November 8, 2019 11:14 AM An: Joe Wang Cc: core-libs-dev Betreff: Re: RFR [14/java.xml] 8233686: XML transformer uses excessive amount of memory Hi Joe, Fix looks OK to me , but i am not able to understand how come "NamespaceMappings" instance can increase memory uses from (20MB to 140MB ). Current scope of "ns" is "case Node.ELEMENT_NODE:" block and "NamespaceMapping" seems to be very lightweight class. Thanks, Vyom On Fri, Nov 8, 2019 at 12:33 AM Joe Wang wrote: > Please review a quick fix that reduces unnecessary object allocations. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8233686 > webrev: http://cr.openjdk.java.net/~joehw/jdk14/8233686/webrev/ > > Thanks, > Joe > > -- Thanks, Vyom
Re: Apache Phoenix with OpenJDK
Hello, If you can’t find the needed information on the Project Website it is probably best to contact the project on the user mailing list. https://phoenix.apache.org/mailing_list.html You might want to give more information like which component is failing, what are the exact error logs and what are the versions of the associated products (like HBase). Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Rachu Vmpp Gesendet: Freitag, Oktober 11, 2019 8:15 PM An: core-libs-dev@openjdk.java.net Betreff: Apache Phoenix with OpenJDK Dear Fellas, Is openJDK 11 compatible with Apache Phoenix? I could see some PhoenixDialect unresolvable name error. Can somebody help?
Re: RFR 8230365 : Pattern for a control-char matches non-control characters
Hallo, Since not all combinations make sense (Exception+convert) a multi value might be better: jdk.regex.control=WARN|EXCEPTION|STANDARD|LEGACY With Exception generating an error, Standard beeing the planned new default (treating upper/lower same and error on all undefined chars) and legacy beeing the manual fallback to current behavior and WARN the same fallback but with logging. I guess some form of early feedback like EXCPETION or WARN is needed, even when it is between a rock and a hard place. Maybe have at least one iteration where it defaults to LEGACY (+Release Notes announcement), then WARN and then finally STANDARD? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Ivan Gerasimov Gesendet: Donnerstag, September 5, 2019 4:00 AM An: Martin Buchholz; Stuart Marks Cc: core-libs-dev Betreff: Re: RFR 8230365 : Pattern for a control-char matches non-control characters Thank you Martin! On 8/30/19 6:19 PM, Martin Buchholz wrote: > There's a strong expectation that ctrl-A and ctrl-a both map to > \u0001, so I support Ivan's initiative. > I'm surprised java regex gets this wrong. > Might need a transitional system property. > Right. I think it would be best to introduce two system properties: The first, to turn on/off the restrictions on the control-char names. This will be enabled by default, and will permit names from the limited list: capital letters and a few other special characters. The second one, to enable mapping of lower-case control-char names to their upper-case counterpart. This option should be turned off by default for the current release of JDK, and then turned on by default for some subsequent release (when, presumably, most applications that use this kind of regexp are fixed). This all feels like a little bit too much for such a rarely used feature, but probably is a proper thing to do anyway :-) If we have an agreement on these system properties, I can create a separate test to verify all possible combinations. > What's the best bit-twiddle? Untested: > if ((c ^= 0x40) < 0x20) return c; > if ((c ^=0x20) <= 26 && c > 0) return c; > > 0x40 is more readable than 64. > `((ch-0x3f)|(0x5f-ch)) >= 0` does the trick for regular (non-lower-case) ids. > Does ctrol-? get mapped to 0x7f ? > Yes. I've got it in the test at the end of the line 4997. Would you please help review the updated webrev: http://cr.openjdk.java.net/~igerasim/8230365/02/webrev/ With kind regards, Ivan
Re: [JSR] [JEP] Java Specification Requirement / Java Enhancement Proposal : 'Parallel OR' and 'Parallel AND'
Hello, I don’t think you will get a new infix operator for this. And adding it to existing operators will be acquire risky change, might not improve performance for most situations - and most of all it is quite unlikely that you have a large number of terms at static compile time anyway. However if you want to evaluate expressions in parallel on a dynamic and large collection, you can easily use a parallel stream. Using predicates as the expression terms to evaluate you can use for example findAny() for checking a or condition. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Prakhar Makhija Gesendet: Mittwoch, Juli 24, 2019 4:49 PM An: David Holmes; core-libs-dev@openjdk.java.net Betreff: [JSR] [JEP] Java Specification Requirement / Java Enhancement Proposal : 'Parallel OR' and 'Parallel AND' Hi David / All, Earlier wanted to discuss just the implementation of 'OR operator', neither 'Conditional OR operator', nor 'Bitwise OR operator' Same goes with 'AND operator' Technically OR operator and AND operator are just binary operators, that's true I don't find it wrong considering there can be n operands, in an expression, with either of the two operators or a combination of both, where n >= 2 n can go nearby anything in powers of 10, it will take those many sequential clock cycles, to actually resolve the expression If you consider the same n as an expression of powers of 2, the same thing can be done in parallel clubbed with divide and conquer, taking the same number of clock cycles, but saving actual response time This can be given as a input from console, or as a property, specifying which implementation to use at runtime, sequential or parallel But with the latter would lead to very frequent resource starvage, this would need to be handled, to actually free the resources and give to pid or ppid, heirarically, or based upon who is the callee, or who asked who to wait, or some more other logic All the threads parallelly evaluating the same expression, with either operand, should be terminated and concluded as, when any thread results to: 'true' in case of OR 'false' in case of AND An expression can have further sub-expressions; so an expression with combination of both operands, will be considered as parent expression Yes it does change the conventional implementation of OR operator, and AND operator, in Java So it would be better to have two new operators/symbols itself Parallel OR ||| Parallel AND &&& We can go with the symbol |&& also in case of Parallel AND Looking forward to hearing your thoughts Best Wishes & Regards Prakhar Makhija Hi Prakhar, On 22/06/2019 1:28 am, Prakhar Makhija wrote: > Topic: OR operator represented by || That should be the subject of your email - not a reply to a digest. > Query: The expression evaluation of the operands, of OR operator, does it > happen in parallel, when Java code runs, in the current versions? No, there is no parallel evaluation of anything in Java. It would be wrong to do so in this case as: "The conditional-or operator || operator is like | (§15.22.2), but evaluates its righthand operand only if the value of its left-hand operand is false." David
Re: RFR 8225474: JDI connector accept fails "Address already in use" with concurrent listeners
stopListening seems not atomically using listenMap. (Ie change get/remove to remove only) BTW this would be a good usecase for a CopyOnWriteMap... -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Andrew Leonard Gesendet: Freitag, Juni 7, 2019 6:14 PM An: core-libs-dev@openjdk.java.net Betreff: RFR 8225474: JDI connector accept fails "Address already in use" with concurrent listeners Hi, Please can I request a sponsor and review of this patch for JDK-8225474. A problem that we have seen intermittently with JDI connector stress tests for quite a while that is caused by an non-thread safe HashMap in the connector class. I've created a standalone testcase that reproduces it reliably. http://cr.openjdk.java.net/~aleonard/8225474/webrev.00 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leon...@uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: can File.exists can return false if the file exists?
Yes it can and does, the getBooleanAttributes method of the filesystem providers cannot communicate IOExceptions, so it will have to return unset flags for this’s case. (Also there are some OS specific conditions where the file stat might be stale, especially if it is a networked filesystem). The missing possibility for returning IOExceptions on File IO was one of the drivers for NIO APIs (unfortunately the alternative Files.exist(Path) took no advantage of this) What you can do is to open the file and inspect the exception and/or use Files.walkFileTree to iterate the parent (as it gives you basicfileattributes view based on the directory read) . Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Sean Bridges Gesendet: Donnerstag, April 4, 2019 9:45 PM An: core-libs-dev@openjdk.java.net Betreff: can File.exists can return false if the file exists? Hey, Is it possible for File.exists(...) to return false even if the file exists. The java docs for File.exists say, "return true if and only if the file or directory denoted by this abstract pathname exists; false otherwise" Looking at the implementation, the method does, s.getBooleanAttributes(this) & FileSystem.BA_EXISTS) != 0 But FileSystem.getBooleanAttributes says, "Return the simple boolean attributes for the file or directory denoted by the given abstract pathname, *or zero if it does not exist or some* * other I/O error occurs*." So it seems that File.exists can return false for files which exist. I think we ran into this on a linux server which reached the limit on open file handles, and File#exists returned false even though the file existed. Is there a way to reliably tell in java if a files exists. Even a method which returned true/false/unknown would be preferable. Thanks, Sean
Re: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes
Instead of removing the file path, would it be possible to add it to all implementations guarded by jdk.includeInExceptions=filename? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Alan Bateman Gesendet: Freitag, März 22, 2019 5:35 PM An: Langer, Christoph; Java Core Libs Betreff: Re: RFR(S): 8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes On 22/03/2019 08:37, Langer, Christoph wrote: > Hi, > > when contemplating over JDK-8211752, I found a few minor cleanups for the > implementations of UnixFileSystem/WinNTFileSystem. Can I please get reviews? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221262 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221262.0/ This looks okay to me. -Alan
Re: jpackage ALL-SYSTEM
Hm, we really should think about renaming --bind-services into --add-all-junk. Will using the option by default make image creation even less useful (i.e. does not safe much) in jpackage? Will there be a option to turn it off? Otherwise I guess it’s best to only support --runtime-Image method. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Andy Herrick Gesendet: Freitag, März 8, 2019 9:13 PM An: core-libs-dev@openjdk.java.net Betreff: Re: jpackage ALL-SYSTEM With jpackage EA 3 (build 17) the option --add-modules does not properly recognize the special cases ALL-SYSTEM, ALL-DEFAULT, and ALL_MODULE_PATH. This will be addressed in the next EA release. The default jlink options used (in EA 3) may also not include --bind-services jlink option, which it will moving forward. In many cases the jlink options used by jpackage to construct the runtime for a modular application may not be exactly what the application wants. In that case it is advisable to run jlink first to create the optimal runtime image for a specific application, then to run jpackage with --runtime-image option to use that runtime image when packaging the application. /Andy On 3/8/2019 9:57 AM, Michael Hall wrote: > I have made changes to my application that make it mostly functional with the > exception of JMX pid attach as built by jpackage. > I thought I had this functionality working when I first got the application > to use Java 9 but it no longer appears to work again now, either with my Java > 9 app or my 13-internal+0-jdk13-jpackage.17 version app. > I understand for this issue serviceability-dev might be a better list for > this but there may be one jpackage issue concerned as well. > Again, I don’t consider this a jpackage problem, my application now builds as > successfully as it currently can with jpackage as-is. > What I get attempting a JMX attach is… > 2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] > com.sun.tools.attach.AttachNotSupportedException: no providers installed > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at > jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202) > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at > us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44) > 2019-03-08 08:27:03.174 HalfPipe[2071:67749] at > us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139) > > The application also can’t be connected to from jconsole. Eclipse can be, so > can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing —add-modules > ALL-SYSTEM > I was going to try this with my application but it did not work. The error > persisted on that as a jvm argument. > Using it as a jpackage —add-modules parameter gets... > Module ALL-SYSTEM does not exist. > > The one question I would have for jpackage is should this work as a > —add-modules parameter? > > However, if anyone has any suggestions on getting JMX attach to work besides > adding serviceability-dev to my forums that would be appreciated as well. > > Thanks.
Re: jpackage ALL-SYSTEM
Can you confir it works if you start your application with a stand-alone JDK? I suspect you have a custom jlink Image which misses the modules. Can you share your jpackage configuration or at least run „Java –list-modules“ and –validate-modules in your installed app? I think you Need at least jdk.attach jdk.attach provides com.sun.tools.attach.spi.AttachProvider used by jdk.attach -- http://bernd.eckenfels.net Von: Michael Hall Gesendet: Freitag, 8. März 2019 18:29 An: core-libs-dev@openjdk.java.net Betreff: jpackage ALL-SYSTEM I have made changes to my application that make it mostly functional with the exception of JMX pid attach as built by jpackage. I thought I had this functionality working when I first got the application to use Java 9 but it no longer appears to work again now, either with my Java 9 app or my 13-internal+0-jdk13-jpackage.17 version app. I understand for this issue serviceability-dev might be a better list for this but there may be one jpackage issue concerned as well. Again, I don’t consider this a jpackage problem, my application now builds as successfully as it currently can with jpackage as-is. What I get attempting a JMX attach is… 2019-03-08 08:27:03.173 HalfPipe[2071:67749] No attach providers 2019-03-08 08:27:03.174 HalfPipe[2071:67749] com.sun.tools.attach.AttachNotSupportedException: no providers installed 2019-03-08 08:27:03.174 HalfPipe[2071:67749]at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:202) 2019-03-08 08:27:03.174 HalfPipe[2071:67749]at us.hall.scripting.PidConnect.pidConnect(PidConnect.java:44) 2019-03-08 08:27:03.174 HalfPipe[2071:67749]at us.hall.scripting.RhinoScriptableObject.pidConnect(RhinoScriptableObject.java:139) The application also can’t be connected to from jconsole. Eclipse can be, so can a Java 8 app (Weka 3-8-2). jconsole shows Eclipse doing —add-modules ALL-SYSTEM I was going to try this with my application but it did not work. The error persisted on that as a jvm argument. Using it as a jpackage —add-modules parameter gets... Module ALL-SYSTEM does not exist. The one question I would have for jpackage is should this work as a —add-modules parameter? However, if anyone has any suggestions on getting JMX attach to work besides adding serviceability-dev to my forums that would be appreciated as well. Thanks.
Re: "java.lang.Error: Probable fatal error:No fonts found" does not show on 11
: Fontconfig returned no font for serif:regular:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for serif:bold:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for serif:regular:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for serif:bold:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:regular:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:bold:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:regular:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:bold:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no fonts at all. Feb 28, 2019 9:50:32 AM sun.font.FcFontConfiguration warning WARNING: Failed to get info from libfontconfig Feb 28, 2019 9:50:32 AM sun.font.FcFontConfiguration warning WARNING: Failed to get info from libfontconfig Exception in thread "main" java.lang.InternalError: java.lang.reflect.InvocationTargetException at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86) at java.base/java.security.AccessController.doPrivileged(AccessController.java:310) at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189) at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223) at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251) at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75) Gruss Bernd -- http://bernd.eckenfels.net Von: Philip Race Gesendet: Donnerstag, Februar 28, 2019 12:45 AM An: Bernd Eckenfels; 2d-dev Cc: awt-...@openjdk.java.net; Java Core Libs Betreff: Re: "java.lang.Error: Probable fatal error:No fonts found" does not show on 11 Wrong list. You want 2d-dev. -phil. On 2/27/19, 3:26 PM, Bernd Eckenfels wrote: > Hello, > > (please let me know in case I picked the wrong list.) > > Since OpenJDK does not ship Default *.ttf font files the change that a JRE is > installed in a way that no System Fonts can be found is quite high. > > In OpenJDK8 it is a bit unfortunate that in this situation even for the > headless graphics context that you can can a Java.lang.Error: > > I wonder if this is intentional. How About returnign an empty Array or Maybe > a RntimeException instead? In my case by upgrading from Oracle JRE to Open > JDK (in my case Azul) a perfectly fine working Installation is not aborting. > > The JasperReports component used is failing does not even need the System > Fonts (which I will report to them seperately). For Zulu it is enough to > install Dejavu Fonts in System Directory or copy them to JRE/lib/fonts/, but > I have also seen OpenJDK builds which seem to use fontmanager libraries > instead of fixed file path. Here I guess the dependency on System config is > even higher. > > I tested on a minimal System with no X11: > >> ls /usr/share/fonts >> cat /etc/centos-release > CentOS Linux release 7.3.1611 (Core) > > And my test program (below) Returns for Java 8: > >> zulu8*x64/bin/java -cp . FontTest > Are we headless? true > g = sun.java2d.HeadlessGraphicsEnvironment headless: true > Exception in thread "main" java.lang.Error: Probable fatal error:No fonts > found. > at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1236) > at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) > … > at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1220) > at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) > at sun.font.SunFontManager.initialiseDeferredFonts(SunFontManager.java:927) > at sun.font.SunFontManager.loadFonts(SunFontManager.java:3302) > at sun.awt.X11FontManager.loadFonts(X11FontManager.java:466) > at sun.font.SunFontManager.loadFontFiles(SunFontManager.java:3429) > at > sun.font.SunFontManager.getInstalledFontFamilyNames(SunFontManager.java:3766) > at > sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:225) > at > sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:252) >
"java.lang.Error: Probable fatal error:No fonts found" does not show on 11
a.desktop/sun.awt.X11FontManager.(X11FontManager.java:56) ... 12 mor If there is no known issue for that, is it worth to file a Bug for it? (I Need to recreate it with a Oracle OpenJDK binary yet if it is only a fontconfig Problem – but in that case a null check is probably also a good thing?) Gruss Bernd
Re: LTS releases and JEP 182: Policy for Retiring javac -source and -target Options ?
I had the same doubts about the @deprecation N+1 Policy. In both cases a „must be deprecated in at least a LTS version“ would be more conservative (but understandable very expensive) Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Alan Bateman Gesendet: Mittwoch, Februar 27, 2019 2:18 PM An: Andrew Leonard; core-libs-dev@openjdk.java.net Betreff: Re: LTS releases and JEP 182: Policy for Retiring javac -source and -target Options ? On 27/02/2019 10:18, Andrew Leonard wrote: > Hi, > Does anyone know if this JEP will be modified to cater for the shorter > release cycles and LTS releases? > https://bugs.openjdk.java.net/browse/JDK-8046172 > The original Impact statement stated: "but even with this new policy > source code 10 or more years old should still be able to be compiled" > however now, for example with JDK12 this policy will only support 1+3 = > 12, 11, 10, 9, which means LTS JDK8 would not be recognised? > "1+3" is essentially only 18 months now! > JDK 12 dropped support for compiling to --release 6, see JDK-8028563 [1]. You shouldn't have any issue compiling to --release 8. The policy documented in JEP 182 pre-dates the more rapid cadence, the policy hasn't been updated yet. The topic has come up on jdk-dev, discuss, and other places. Joe Darcy's recent mail to jdk-dev [2] might be useful. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8028563 [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002628.html
Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.
For security reasons I would add it to `jdk.includeInExceptions`, but maybe as a default? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Roger Riggs Gesendet: Dienstag, Februar 12, 2019 8:07 PM An: Lindenmaier, Goetz; Java Core Libs Cc: hotspot-runtime-...@openjdk.java.net Betreff: Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. Hi, On 02/12/2019 08:14 AM, Lindenmaier, Goetz wrote: > Hi Roger, > > thanks for looking at my change! > >> A few higher level issues should be considered, though the details of >> the webrev captured my immediate attention. >> >> Is this the right feature > Yes!! Maybe, that's what debuggers are for. > >> and is this the right level of implementation (C++/native)? > See below. Maybe 10 years ago, when native was the only solution. Now there are tools to analyze bytecode in java. > >> From a security perspective, adding field names to exceptions exposes >> information to callers that they could not otherwise get and that breaks >> encapsulation. >> That needs to be evaluated. > I can not comment on that. How can I trigger an evaluation of this? > Who needs to evaluate this? > >> I think there are ways to make this easier to implement and be easier to >> maintain and perform better. >> >> NullPointerException: >> 28: unused import of Field > Removed > >> 64: The lazyComputeMessage boolean should be inverted so it does not >> require >>initialization, false is the default, anything else adds overhead. >>And it may not be needed. > Peter Levart proposed to initialize the message with a sentinel instead. > I'll implement this as a proposal. That's an extra overhead too, any assignment is. > >> 91: Why do you think synchonization is necessary? It is a performance hit. >>It is highly unlikely to be called from multiple threads and the >> value will >>be the same whether it is computed once or multiple times by >> different threads. > I guess we can go without. > It would be possible to construct a case where two threads > do getMessage() on the same NPE Object but the string is not > the same. Really!, if the bci is the same, the bytecode is the same, what could be different that would change the data used to create the exception? > >> 99: extendedMessage will never be null (so says the javadoc of >> getExtendedNPEMessage) >> Bug: If it does return null, then null is returned from getMessage >> regardless of the value of super.getMessage(). > Fixed. > >> 121: Simplify getExtendedNPEMessage by making it only responsible for >> the detail >> and not concatenation with an existing message. Put that in >> getMessage(). > Fixed. You are right, I only call this when the message is NULL. > >> Its not strictly necessary to change the updated message with >> setMessage(). >> Avoiding that will avoid complexity and a performance hit. >> The message will be computed each time it is needed, and that happens >> infrequently. >> (Even in the serialization case, it will be re-computed from the >> attached stack frames). > No, you can not recompute it from the stacktrace because that > does not contain the BCI. Also, after deserialization, the bytecode > might look different or not available at all. It depends on the actual > bytecode that has been running when the exception was thrown. Right, I realized this too when thinking about it over the weekend. If a suitable low impact mechanism can't be found, then just go back to not exposing the extended message and use only the original. Its a bad idea to twist and contort the local design and accessibility just for serialization. What remote or delayed client needs to know this? > >> And it avoids adding setMessage() to Throwable, that's significant >> change since >> the current implementation only allows the message to be initialized >> not updated. >> Immutable is an important characteristic to maintain. > Yes, I don't like I have to set this. But it follows the same pattern > as with the stack trace which is only computed on demand. Thus, > Throwable is not immutable anyways. Before, I implemented this by a > JNI call hiding this in the Java code. > I proposed implementing setting the field by reflection, Christoph > proposed a shared secret. David favored the package private setter. > Please advice what is best. All of them are bad. Private needs to mean private. And making it mutable, also means that synchronization or volatile is needed to ensure a consistent value for getMessage(). That turns into a p
PreparedStatement.setBinaryStream Javadoc
Hello, The JavaDoc for some of the setBinary/ASCII... methods of PS say something about „more practical“ but it is not clear if it means this method is more practical than another method, or if this method should not be used in favor of another. When a very large binary value is input to a LONGVARBINARY parameter, it may be more practical to send it via a java.io.InputStream object. Also, does this not apply to BLOB or VARBINARY? I would clarify this to something like (if I understood the meaning correctly): For large content the use of an InputStream/Reader can avoid keeping the data in memory, It however depends on the driver how the data is internally processed or buffered. BTW those functions do not mention if the stream is closed or not. After the method returns the stream is not closed. Some more clarifications could also be given (not sure if all of them are correct): The stream is positioned after the specified length. The reading blocks till the end of stream is signaled (will not return when abailable()==0) EOFException is thrown If stream is shorter than specified length. Gruss Bernd -- http://bernd.eckenfels.net
Re: High memory usage / leaks was: Best mailing list for JVM embedding
Hello, I think in the Java 9 timeframe the Zip implementation was changed to no longer mmap the Zip index table. So this was not visible in the heap but now is. (Although it seems to be a bit slower). That might be the reason for your regression. You could use the following System property in Java 8 to get the new method there as well (in Java 9 the property and the old method is gone) https://bugs.openjdk.java.net/browse/JDK-8175192 Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Robert Marcano Gesendet: Donnerstag, Januar 24, 2019 5:26 PM An: core-libs-dev@openjdk.java.net Betreff: 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
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. -- 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 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: jpackage usage
Is this a console application? I think the launcher won’t show that. So the program actually runs, it just not displays a console window. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Skillzore Gaming Gesendet: Mittwoch, Januar 16, 2019 9:15 PM An: core-libs-dev@openjdk.java.net Betreff: jpackage usage Hi! I am trying out jpackage from https://jdk.java.net/jpackage/. I have been trying to figure out how to get it to build a working exe file. I have a helloWorld.jar built by gradle which is runnable and runs fine with "java -jar helloWorld.jar". But when I try to use it to build an exe file, the resulting installation (from the built exe file) does not work as expected. I build the exe file with jpackage.exe create-installer exe -n "hello" -j helloWorld.jar -o . -i . -c HelloWorld It installs just fine, but when trying to run the resulting hello.exe nothing happens. I think that I am doing something wrong in the creation of the exe. I am a bit unsure of what the -o, -i and -c parameters are intended to do and that is probably where I fail. Any insight would be appreciated since I am hoping to use this on a larger project later and the interwebs do not have much information on this as of yet. Regards, Simon
Re: Modular Applications - Regression
Well, I think that (jaxb) is a different (but related) issue. I was just addressing the „generate smaller runtime Image with jimage for classpath usage“ part. And that works. You can either do it on the command line or introduce an empty module with the needed Imports. In both cases jlink can produce a minimized Image (and still have a classpath used). Given the uncertainity involved in static scanning I would not want jlink to do jdeps work automatically, so there is not much else you can do besided providing the modules list yourself, or what would be your idea to make this work? (Actually when aiming for small Images, I would even specify the modules in a mp path scenario, only because a third party module Imports a JDK module does not mean it needs it at runtime for the specific case) Gruss Bernd -- http://bernd.eckenfels.net Von: Scott Palmer Gesendet: Montag, 14. Januar 2019 21:21 An: Bernd Eckenfels Cc: core-libs-dev Betreff: Re: Modular Applications - Regression Aren’t you just saying that jlink works when you don’t use the stuff that broke? Can you use jlink with JAXB or JAX-WS that does not rely on the .jmod files from JDK 9 or 10? Is there a way to use JAXB or JAX-WS on the module path like there was with JDK 9 & 10? >From what I can tell, if one of the modules you need is JAXB or JAX-WS and you >already had this working with Java 9 or 10, you have to make a lot of changes. > You can’t build a JRE image with jlink that contains the new replacements for >JAXB or JAX-WS. You can include JAXB or JAX-WS on the classpath, but you >can’t go back to how it worked with JDK 9 & 10. Applications based on a JRE image that includes the java.xml.bind, java.xml.ws, or java.activation modules can’t be made to work anymore without resorting to hacks like running jlink to pull the .jmod files for those modules from JDK 10 and the rest of the runtime from JDK 11. Scott > On Jan 14, 2019, at 2:37 PM, Bernd Eckenfels wrote: > > JLink works fine with applications on the classpath, all you have to do is to > list the modules needed manually (and JDeps helps with that). > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > > Von: core-libs-dev im Auftrag von > Scott Palmer > Gesendet: Montag, Januar 14, 2019 8:16 PM > An: Alan Bateman > Cc: core-libs-dev > Betreff: Re: Modular Applications - Regression > > > >> On Jan 14, 2019, at 10:33 AM, Alan Bateman wrote: >> >> On 14/01/2019 15:03, Scott Palmer wrote: >>> : >>> >>> Does this not require ALL dependencies - down the entire dependency chain, >>> including every transitive dependency, to be 100% modular? >> Look for "automatic modules", this is how the module system facilitates >> top-down migration where you can migrate to modules without waiting >> everything you depend on to migrate first. Automatic modules also support >> bridging to the class path so you can migrate without moving everything from >> the class path to module name. > > Sorry, I’m asking this in the context of building a modular app that I can > then run jlink or jpackage on. (I *think* I understand automatic modules.) > However, a workflow that will run perfectly fine with JDK 9 & 10 can’t easily > be ported to JDK 11 because jlink can't work with automatic modules and > java.activation is no-longer available as an explicit module (until the issue > you cited is fixed, but note that the module name has changed, thus requiring > a stub module for modules that are expecting a module named java.activation). > >> >>> >>> I don’t know of many applications outside of those included in the JDK >>> (where dependencies are not an option) that this restriction actually >>> applies to. In fact since Java 11 there is a regression where applications >>> that could be built as modular with JDK 9 & 10 no longer can be, because >>> the java.activation module was removed and no modular replacement is >>> available. Many dependency chains lead to java.activation. >> The JavaBeans Activation Framework (JAF) was always maintained as a project >> in Java EE, never here. In any case, you can download JAF from Maven and >> deploy it on the module path, it should just work. The only issue with link >> time where it needs to be migrated to an explicit module before it can be >> linked into a run-time image. There is an issue in its Eclipse project to >> migrate it to an explicit module [1]. > > This issue breaks many cases where jlink used to work. This is why I refer to > the current state of things as a regression. It’s more than a simple matter > of obtaining the replacement
Re: Modular Applications - Regression
JLink works fine with applications on the classpath, all you have to do is to list the modules needed manually (and JDeps helps with that). Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Scott Palmer Gesendet: Montag, Januar 14, 2019 8:16 PM An: Alan Bateman Cc: core-libs-dev Betreff: Re: Modular Applications - Regression > On Jan 14, 2019, at 10:33 AM, Alan Bateman wrote: > > On 14/01/2019 15:03, Scott Palmer wrote: >> : >> >> Does this not require ALL dependencies - down the entire dependency chain, >> including every transitive dependency, to be 100% modular? > Look for "automatic modules", this is how the module system facilitates > top-down migration where you can migrate to modules without waiting > everything you depend on to migrate first. Automatic modules also support > bridging to the class path so you can migrate without moving everything from > the class path to module name. Sorry, I’m asking this in the context of building a modular app that I can then run jlink or jpackage on. (I *think* I understand automatic modules.) However, a workflow that will run perfectly fine with JDK 9 & 10 can’t easily be ported to JDK 11 because jlink can't work with automatic modules and java.activation is no-longer available as an explicit module (until the issue you cited is fixed, but note that the module name has changed, thus requiring a stub module for modules that are expecting a module named java.activation). > >> >> I don’t know of many applications outside of those included in the JDK >> (where dependencies are not an option) that this restriction actually >> applies to. In fact since Java 11 there is a regression where applications >> that could be built as modular with JDK 9 & 10 no longer can be, because the >> java.activation module was removed and no modular replacement is available. >> Many dependency chains lead to java.activation. > The JavaBeans Activation Framework (JAF) was always maintained as a project > in Java EE, never here. In any case, you can download JAF from Maven and > deploy it on the module path, it should just work. The only issue with link > time where it needs to be migrated to an explicit module before it can be > linked into a run-time image. There is an issue in its Eclipse project to > migrate it to an explicit module [1]. This issue breaks many cases where jlink used to work. This is why I refer to the current state of things as a regression. It’s more than a simple matter of obtaining the replacement module for the modules that were removed from the JDK - because no such modules currently exist. Even if you modularize your library or application - you can’t run jlink on it if the dependency chain ever leads to an automatic module. Therefore jpackage and jlink tools can’t work on projects that they previously could work on due to the changes in the JDK being made without a suitable replacement ready for java.activation. Somehow java.activation became un-modularized in the process of removing it from the JDK. So more to the point - very few application modules are suitable for jlink input. The only practical case seems to be to run jlink by explicitly including only modules that have no automatic module transitive dependencies (e.g. JavaFX). Even that can’t be done to include JAXB or JAX-WS into a Java 11 JRE image, to make a JRE compatible with Java 9 & 10, because of java.activation Is that correct? Scott > > -Alan > > [1] https://github.com/eclipse-ee4j/jaf/issues/13
Re: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random)
Hm strange, never saw it this way. Would other types have the same problem (should be visible in your histogram for long as well, right?) Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Brian Burkhalter Gesendet: Donnerstag, Dezember 20, 2018 8:03 AM An: core-libs-dev Betreff: 8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random) https://bugs.openjdk.java.net/browse/JDK-8215441 This issue was filed to cover improving the uniformity of randomly generated BigIntegers. It is not intended to resolve [1] which is deliberately left open. The proposed patch implements a modified version of the “workaround” suggested in [1]. The problem is that the magnitude of the random BigInteger is created from a sequence of bytes generated by Random.nextBytes() [2]. The likelihood that any of these bytes is zero is small so the distribution of the resulting random BigIntegers is skewed towards values close to the maximum bit size “numBits” specified to the constructor. The workaround suggested in [1] is to randomly change numBits to the value numBits = Random.nextInt(numBits + 1) [3]. (Actually the suggested workaround is nextInt(numBits) which is incorrect as the parameter is an exclusive upper bound.) This greatly improves the uniformity of the distribution. A remaining problem however is that now the very largest numbers in the interval [0,2^numBits) are underrepresented. A modification of this approach is to increment the new value of numBits as numBits = Random.nextInt(numBits + 1) + 1 [4]. This was empirically observed to improve the underrepresentation of the largest values. The distribution of the random BigIntegers was estimated using [5]. For a given maximum bit length, bin size, and number of random values to generate, this creates a histogram and calculates the coefficient of variation of the numbers generated. The histogram bin at index zero represents the largest valued bin in the result. The count in a given histogram bin is the number of values for which that bin is the leftmost (largest valued) with at least one non-zero bit. The bin of maximum index represents zero. Results for the current and two modified approaches for 256 bits with a 1-bit bin size and for 4096 bits with a 4-bit bin size are given at [6-11]. As may be observed, the original histogram is clustered towards the largest possible value 2^numBits - 1, and the coefficient of variation is small. The results for the two variants of the patch show a flattened distribution, i.e., more uniform, and a significantly larger coefficient of variation. The second approach shows better flattening of both ends of the histogram. These results are samples only but are exemplary of the results observed over numerous runs of this code. The test ModPow is modified as the modPow() method throws an ArithmeticException for a zero modulus. The current algorithm never generates a random BigInteger equal to zero however so that exception never occurs. That is not the case for either modified version. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8146153 [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Random.html#nextBytes(byte[]) [3] http://cr.openjdk.java.net/~bpb/8146153/webrev.00/ [4] http://cr.openjdk.java.net/~bpb/8146153/webrev.01/ [5] http://cr.openjdk.java.net/~bpb/8146153/StatsBigIntegerRandom.java [6] http://cr.openjdk.java.net/~bpb/8146153/before-256-1.txt [7] http://cr.openjdk.java.net/~bpb/8146153/after-256-1.txt [8] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-256-1.txt [9] http://cr.openjdk.java.net/~bpb/8146153/before-4096-4.txt [10] http://cr.openjdk.java.net/~bpb/8146153/after-4096-4.txt [11] http://cr.openjdk.java.net/~bpb/8146153/after-extra-bit-4096-4.txt
Re: Throwable.addSuppressed again
Just an Addition: looks like the OOME uses already enableSuppression=true (in most? Cases) so a change to check enableSuppression before checking self-supression seems like an very effective change (if it is decided to Keep this Assertion at all). Gruss Bernd -- http://bernd.eckenfels.net
Throwable.addSuppressed again
Hello, a while back I reported a Problem with „self Suppression“ in the context of FilterOutputStream where a „cached“ exception thrown by flush() and close() resulted in a IllegalArgumentException: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/026743.html This was fixed for the Filter streams: https://bugs.openjdk.java.net/browse/JDK-8042377 However the discussion if this is generally a bad behavior of Thread.addSuppressed had no conclusion. I just stumbled across another case where the IllegalArgumentException of Throwable.addSuppressed was a Problem: i had seen a case where an OutOfMemoryException in a try-with-resource created the same Problem. I cant reproduce the Situation clearly (it is related to Closing URLClassLoaders) but it looks like in some cases there is an native OOM exception instances are re-used. So if a OOM leads to cleanup of resources which trigger the exception again, it will happen. In this case it is rather unfortunate (if somebody expects to see and handle the OutOfMemoryException it wont be visible anymore since only the IllegalArgumentException is propagated) I do think (again) that Throwable.addSuppressed should throw the IAE ever, it is more robust to just silently skip the Operation. Alan, did you know if there have been any follow-up discussion? BTW: there is also a constructor switch to not record suppressed exceptions, this switch is however evaluated after the identity check is done. This might be worth re-arranging, then Errors and VM Exceptions could at least turn the recording off for themselves. (not sure who and why uses this constructor) https://hg.openjdk.java.net/jdk/jdk/file/dcbb71b9e7c0/src/java.base/share/classes/java/lang/Throwable.java#l1033 Gruss Bernd -- http://bernd.eckenfels.net
Re: The meaning of the java.vendor property?
Martin, Volker, Many things for quickly providing these clarifying words! Going forward, I will be assuming that "vendor" means whoever built the distribution and that there is some intended differentiation in the values of "java.vendor" and "java.vm.vendor". Bernd From: Martin Buchholz Date: Friday, December 14, 2018 at 5:52 AM To: "Mathiske, Bernd" Cc: "core-libs-dev@openjdk.java.net" Subject: Re: The meaning of the java.vendor property? There's a configure flag for java.vendor (but not java.specification.vendor) which is a strong hint. --with-vendor-name Set vendor name. Among others, used to set the 'java.vendor' and 'java.vm.vendor' system properties. [not specified] On 12/14/18, 9:13 AM, "Volker Simonis" wrote: Hi Bernd, from my understanding you can choose to freely set the following properties (and we do that for SapMachine, as you can see): java.vendor = SAP SE java.vendor.url = https://sapmachine.io java.vendor.url.bug = https://github.com/SAP/SapMachine/issues/new java.vm.vendor = SAP SE The following "specification.vendor" properties have to show the Java SE spec lead (which currently is Oracle) so you shouldn't change them: java.specification.vendor = Oracle Corporation java.vm.specification.vendor = Oracle Corporation Regards, Volker On Thu, Dec 13, 2018 at 11:14 PM Mathiske, Bernd wrote: > > I was wondering if it’s OK to modify the “java.vendor” system property as reported by System.getProperty() in our OpenJDK builds. Some binary OpenJDK distribution builders seem to be doing so, but others not. Is there a rule for this? The documentation does not seem exactly conclusive: > > https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html > https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getProperties() > > What is a “vendor” in this context? Is it always supposed to be “Oracle Corporation” to stay compatible? Or is it supposed to be whoever builds and packages the binaries so we can track the origin of the binary artifacts better? > > Bernd >
The meaning of the java.vendor property?
I was wondering if it’s OK to modify the “java.vendor” system property as reported by System.getProperty() in our OpenJDK builds. Some binary OpenJDK distribution builders seem to be doing so, but others not. Is there a rule for this? The documentation does not seem exactly conclusive: https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getProperties() What is a “vendor” in this context? Is it always supposed to be “Oracle Corporation” to stay compatible? Or is it supposed to be whoever builds and packages the binaries so we can track the origin of the binary artifacts better? Bernd
DataTruncation has static message
Hello, The java.sql.DataTruncation Exception/warning has a few detail members, especially the index of the field in question. Yet it will not be reflected in getMessage/toString. I wonder if the message should be dynamic to at least include the index (if known). http://hg.openjdk.java.net/jdk/jdk/file/7d3391e9df19/src/java.sql/share/classes/java/sql/DataTruncation.java Gruss Bernd -- http://bernd.eckenfels.net
Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions
Hello,
What is the purpose of setting some of them to 0 twice? (It’s a new array which
should be all-0 anyway.)
+ for (int i = 1; i < 9 ; i++) {
+subkeyHtbl[2*i] = 0;
+subkeyHtbl[2*i+1] = 0;
+}
Also, is the subkeyH no longer be needed (or can be redesigned to use
subkeyHtbl[0] and 1?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von
Kamath, Smita
Gesendet: Montag, November 19, 2018 10:52 PM
An: 'Vladimir Kozlov'
Cc: Anthony Scarpino; core-libs-dev@openjdk.java.net; hotspot compiler
Betreff: RFR(S)JDK-8214074: Ghash optimization using AVX instructions
Hi Vladimir,
I'd like to contribute an optimization for GHASH Algorithm using AVX
Instructions. I have tested this optimization on SKX x86_64 platform and it
shows ~20-30% performance improvement for larger message sizes (for example 8k).
I, smita.kam...@intel.com<mailto:smita.kam...@intel.com> , Shay Gueuron,
(shay.gue...@intel.com<mailto:shay.gue...@intel.com>) and Regev Shemy
(regev.sh...@intel.com<mailto:regev.sh...@intel.com>) are contributors to this
code.
Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074
Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/
For testing the implementation, I have executed TestAESMain.java. I have
executed Jtreg tests and tested this code on 64 bit Windows and Linux platforms.
Please review and let me know if you have any comments.
Thanks and Regards,
Smita
Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
Hello,
I wonder if in the Windows temp case LocalLow is (still) the right place. If
this Installer is not started in the low context it will endanger its extracted
temp file by making them accessible to low integrity processes, right?
And if this should search %TEMP%., %LOCALAPPDATA%\temp first.
But the variables are known to have problems too, To be robust and Windows
ready compliant it looks like another jpackager runtime function for
SHGetKnownFolderPath would be good (pretty sure it’s already used somewhere,
just not with a stable API exposed?)
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von
Philip Race
Gesendet: Montag, November 12, 2018 10:55 PM
An: Andy Herrick
Cc: build-dev; core-libs-dev@openjdk.java.net
Betreff: Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
74
75 static String getTmpDir() {
76 String os = System.getProperty("os.name").toLowerCase();
77 if (os.contains("win")) {
78 return System.getProperty("user.home")
79 + "\\AppData\\LocalLow\\Sun\\Java\\JPackager\\tmp";
80 } else if (os.contains("mac") || os.contains("os x")) {
81 return System.getProperty("user.home")
82 + "/Library/Application Support/Oracle/Java/JPackager/tmp";
83 } else if (os.contains("nix") || os.contains("nux")
84 || os.contains("aix")) {
85 return System.getProperty("user.home") + "/.java/jpackager/tmp";
86 }
87
88 return System.getProperty("java.io.tmpdir");
This seems unduly complex, and I don't understand the implication of
supporting AIX .. or some unknown "Unix", when packager is targeted
only at mac, linux + windows.
I think its sufficient to look for the strings windows, macos and linux.
And if you want a persistent storage location then default to the "unix"
location if there's no match .. although I am not sure it makes sense
on platforms that aren't targeted by jpackager.
-phil.
>
> -phil.
>
> On 11/12/18, 12:22 PM, Philip Race wrote:
>> Adding build-dev back ..
>>
>> I noticed that module jdk.jpackager.runtime requires java.desktop on
>> all platforms
>>
>> So far as I can tell this is for a Mac-only support for receiving and
>> handling file open events. Probably it only makes sense or gets used
>> when the API is used from a running desktop application.
>>
>> I might ask if we need this at all, but I definitely think it should
>> not be required on all platforms if needed only for Mac even if
>> we might want it on windows in a future version.
>>
>> Do we not envisage cases where you need the runtime API for
>> some kind of daemon service for which there should be a singleton ?
>> Do you really want to force the desktop module to be dragged along
>> in such a case ?
>>
>> I think we should remove this dependency even if it means losing a
>> MacOS feature at least for now.
>>
>> -phil.
>>
>> On 11/11/18, 2:40 PM, Andy Herrick wrote:
>>> On 11/9/2018 5:25 PM, Andy Herrick wrote:
>>>> This is an update to the Request For Review of the implementation
>>>> of the Java Packager Tool (jpackager) as described in JEP 343:
>>>> Packaging Tool <https://bugs.openjdk.java.net/browse/JDK-8200758>
>>>>
>>>> This refresh renames the packages used to jdk.jpackager and
>>>> jdk.jpackager.runtime, removes the JNLPConverter demo, adds an
>>>> initial set of automated tests, and contains fixes to the following
>>>> issues:
>>>>
>>>> JDK-8213324 jpackager deletes existing app directory without warning
>>>> JDK-8213166 jpackager --argument arg is broken
>>>> JDK-8213163 --app-image arg does not work creating exe installers
>>>> JDK-8212089 Prepare packager for localization
>>>> JDK-8212537 Create method and class description comments for main
>>>> functionality
>>>> JDK-8213332 Create minimal automated tests for jpackager
>>>> JDK-821 Fix issues found in jpackager with automated tests
>>>> JDK-8213394 Stop using Log.info() except for expected output.
>>>> JDK-8213345 Secondary Launchers broken on mac.
>>>> JDK-8213156 rename packages for jpackager
>>>> JDK-8213244 Fix all warnings in jpackager java code
>>>> JDK-8212143 Remove native code that supports UserJvmOptionsService
>>>> JDK-8213162 Association description in Inno Setup cannot contain
>>>> double quotes
>>>>
>>>> The following additional issues are targeted to be address in the
>>>> next few weeks:
>>>&g
Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged
http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html
In checkContext should the security manager be null checked first instead of
last to optimize for the typical case? (If the side effects in that expression
are desired it should be documented)
I find the tail call optimization comment in wrapException adds only confusion
to an otherwise clear helper. But maybe it’s just me who does not understand it.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von
Vladimir Ivanov
Gesendet: Donnerstag, November 1, 2018 5:11 AM
An: dean.l...@oracle.com; security-...@openjdk.java.net; core-libs-dev Libs;
hotspot-dev developers
Betreff: Re: RFR(M) 8212605: Pure-Java implementation of
AccessController.doPrivileged
Dean,
src/java.base/share/classes/java/security/AccessController.java:
+ /**
+ * Internal marker for hidden implementation frames.
+ */
+ /*non-public*/
+ @Target(ElementType.METHOD)
+ @Retention(RetentionPolicy.RUNTIME)
+ @interface Hidden {
+ }
You declare @Hidden, but then map it to _method_Hidden along with
@Hidden from java.lang.invoke.LambdaForm.
What do you think about moving LambdaForm.Hidden to
jdk.internal.vm.annotation instead and share among all usages?
Best regards,
Vladimir Ivanov
On 31/10/2018 15:23, dean.l...@oracle.com wrote:
> https://bugs.openjdk.java.net/browse/JDK-8212605
> http://cr.openjdk.java.net/~dlong/8212605/webrev.1
>
> This change implements AccessController.doPrivileged in Java. This
> gives a performance improvement while also being useful to Project Loom
> by removing the Java --> native --> Java transition. One reason
> doPrivileged has historically been in native is because of the need to
> guarantee the cleanup of the privileged context when doPrivileged
> returns. To do that in Java, the information that
> AccessController.getContext needs is pushed onto the Java stack as
> arguments to a method that getContext will recognize during its stack
> walk. This allows us to remove the native privileged stack while
> guaranteeing that the privileged context goes away when the method returns.
>
> Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security
> tests. For the first few rounds of testing, I kept the old native
> privileged stack and compared the results of the old and new
> implementations for each getContext call, which did catch some early
> bugs. The changes were also examined by internal security experts and
> run through additional internal security tests.
>
> The improvement on this [1] doPrivileged microbenchmark is approximate 50x.
>
> There is no attempt to optimize getContext() or security permission
> checks in this change, however, this is intended to be a first step
> towards other possible improvements, for example those proposed here [2].
>
> dl
>
> [1]
> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java
>
> [2]
> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html
>
>
Re: Is it possible to find PDB (windows debugging info) for publishedjvm.dll?
Sorry for offtopic – figured might still be a good Addition to the question, If you can switch the JDK (and do not yet need Java 11) then you can use the binaries from the ojdkbuild Project (Fedora/RH upstream), they provide the PDB files in the *debuginfo* packages (havent tested them myself). Its a pitty, seems not to be a standard Service of openjdk Vendors (not even the paied ones). https://github.com/ojdkbuild/ojdkbuild/releases Gruss Bernd -- http://bernd.eckenfels.net Von: Alexander Miloslavskiy Gesendet: Mittwoch, 17. Oktober 2018 19:39 An: core-libs-dev Betreff: Is it possible to find PDB (windows debugging info) for publishedjvm.dll? Hello, I'm trying to debug a native crash that regularly happens for one of our customers. It crashes somewhere amidst java interpreter code, with corrupted value in CPU's RIP register. So it's quite complicated. It would certainly help me a lot if I had access to jvm.pdb files for published JRE's... I'm mostly after 10.0.1+10 and 8.0_144-b01 at the moment. According to the published binaries, the PDB's are generated here on the build server: t:\workspace\build\windows-x64\support\modules_libs\java.base\server\jvm.pdb I believe they are saved somewhere after building, at least internally? Is there some way to obtain those pdb's myself? If not, can someone send me the PDB's, at least for 10.0.1+10? I understand that I can build OpenJDK myself to obtain the PDB's, but unfortunately they will not match dumps provided by the client.
Re: RFR: 8211859: (fc) Avoid initializing AtomicBooleanfromRandomAccessFile
Hello, just noticed it is probably intended to not be synchronized for the reads (since it is volatile)?. In that case using `this` monitor would also allow to remove the volatile. However not sure if that is good or bad for the Performance (close does not do DCL then anymore, but ist probably not called that often anyway) Gruss Bernd -- http://bernd.eckenfels.net Von: Bernd Eckenfels Gesendet: Montag, 8. Oktober 2018 21:28 An: core-libs-dev Betreff: AW: RFR: 8211859: (fc) Avoid initializing AtomicBooleanfromRandomAccessFile getChannel() Synchronizes only on `this` and `close()` on `closeLock`. It does I guess work since the important part is make sure only one thread does the close work, however Publishing the close change to getChannel is a secondary effect of the AtomicBoolean which the new Version does not have(?). I guess the most efficient method would be to only use this as a monitor. While this is not the cleanest usage it is already used, so it does not make it worse… Gruss Bernd -- http://bernd.eckenfels.net Von: Alan Bateman Gesendet: Montag, 8. Oktober 2018 21:21 An: Claes Redestad; core-libs-dev Betreff: Re: RFR: 8211859: (fc) Avoid initializing AtomicBoolean fromRandomAccessFile On 08/10/2018 16:32, Claes Redestad wrote: > Hi, > > aligning the closing of RandomAccessFiles with the implementation in > FileInput-/OutputStream improves startup in a few tests. > > Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211859 This looks okay to me. -Alan
AW: RFR: 8211859: (fc) Avoid initializing AtomicBoolean fromRandomAccessFile
getChannel() Synchronizes only on `this` and `close()` on `closeLock`. It does I guess work since the important part is make sure only one thread does the close work, however Publishing the close change to getChannel is a secondary effect of the AtomicBoolean which the new Version does not have(?). I guess the most efficient method would be to only use this as a monitor. While this is not the cleanest usage it is already used, so it does not make it worse… Gruss Bernd -- http://bernd.eckenfels.net Von: Alan Bateman Gesendet: Montag, 8. Oktober 2018 21:21 An: Claes Redestad; core-libs-dev Betreff: Re: RFR: 8211859: (fc) Avoid initializing AtomicBoolean fromRandomAccessFile On 08/10/2018 16:32, Claes Redestad wrote: > Hi, > > aligning the closing of RandomAccessFiles with the implementation in > FileInput-/OutputStream improves startup in a few tests. > > Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211859 This looks okay to me. -Alan
Re: are there src git repositories for javase (was: core-libs-dev Digest, Vol 138, Issue 30)
Hello, there is no official/canonical one as far as I know, but there are a few (externally maintained) Repos which are produced by mirroring the HG trees. I cannot endores any of them, but in GitHub you find: Older versions: https://github.com/openjdk-mirror SAP maintained: https://github.com/SAP/SapMachine/tree/jdk/jdk Ojdkbuild: https://github.com/ojdkbuild/upstream_jdk AdoptOpenJDK: https://github.com/AdoptOpenJDK/openjdk-jdk11 Gruss Bernd BTW: ist not a good idea to respond to Digest mails, it messes up the threading and the subject -- http://bernd.eckenfels.net Von: Prakhar Makhija Gesendet: Montag, 8. Oktober 2018 18:44 An: core-libs-dev@openjdk.java.net Betreff: Re: core-libs-dev Digest, Vol 138, Issue 30 Guys are there src git repositories for javase? Please share the links I found git repos for javaee only On Mon 8 Oct, 2018, 5:30 PM , wrote: > Send core-libs-dev mailing list submissions to > core-libs-dev@openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > or, via email, send a message with subject or body 'help' to > core-libs-dev-requ...@openjdk.java.net > > You can reach the person managing the list at > core-libs-dev-ow...@openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core-libs-dev digest..." > > > Today's Topics: > >1. Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > (Aleksei Voitylov) >2. Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > (Thomas St?fe) > > > -- > > Message: 1 > Date: Sat, 6 Oct 2018 18:07:52 +0300 > From: Aleksei Voitylov > To: Kim Barrett > Cc: build-dev , hotspot-dev developers > , core-libs-dev@openjdk.java.net > Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > Message-ID: <10d8f2ea-883e-ec21-4fea-06a52a52f...@bell-sw.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Kim, > > from an ARM port perspective, the stable GCC version is 4.9. The port > compiles with stock GCC 7.3 but a lot of testing is required before > moving to GCC 7.3. I agree on the overall direction and we'll commit > resources to testing it further, but from an ARM port perspective it may > happen JDK 12 is a little too optimistic. > > GCC x86 is a lot more stable than for ARM32 and AARCH64. > > -Aleksei > > On 05/10/2018 00:09, Kim Barrett wrote: > >> On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov < > aleksei.voity...@bell-sw.com> wrote: > >> > >> Kim, > >> > >> Thank you for posting this. It's an important step to make. I wanted to > clarify a couple of points: > >> > >> 1. Since this is infrastructure JEP, is the version of JDK which will > undergo such changes going to be some future version or does it apply to > past versions as well? I'm concerned with how we can simplify security > backports to 8u which (I currently assume) is not subject to this change. > > Future version (perhaps as soon as JDK 12). I don't think there is > > any desire to backport this change. And yes, introducing the use of > > new language features will make backports even more interesting than > > they already are. That seems unavoidable if we're going to pursue > > this direction. > > > >> 2. Which versions of GCC do you tentatively consider at this point? > Non-x86 ports may have a problem upgrading to a specific version of GCC > which the shared code will use and may need additional lead time to adjust. > > I think our (ad hoc) testing has been limited to gcc 7.x. But looking > > at the gcc language conformance tables and release notes, gcc 5.x > > might be good enough, and gcc 6.x seems fairly likely sufficient. Of > > course, older versions are more likely to have bugs in some of these > > new features. Updating the minimum supported versions for gcc and > > clang are noted as TBD in the JEP. > > > > > > -- > > Message: 2 > Date: Mon, 8 Oct 2018 12:48:57 +0200 > From: Thomas St?fe > To: Kim Barrett > Cc: build-dev , HotSpot Open Source > Developers , Java Core Libs > > Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > Message-ID: > go62sypqo9x1aw9ezeu3gxcb...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Kim, > > is this JEP only about C++14 features or shall we discuss older > features too? The reason I am askin
Re: JarFile constructor throws undocumented exception (only) on Windows OS
Why does that actually throw an Exception on Linux/Unix, it is a perfectly
legal file name.
Gruss
Bernd
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: -2122936656m Auftrag von
Gesendet: Freitag, Oktober 5, 2018 11:00 AM
An: core-libs-dev@openjdk.java.net
Betreff: Re: JarFile constructor throws undocumented exception (only) on
Windows OS
Just for reference - this came up while debugging an issue, that one of
our users of Apache Ant project raised here
https://bz.apache.org/bugzilla/show_bug.cgi?id=62764#c8
-Jaikiran
On 04/10/18 3:06 PM, Jaikiran Pai wrote:
> Please consider the following trivial code:
>
> import java.util.jar.*;
> import java.io.*;
>
> public class JarFileTest {
> public static void main(final String[] args) throws Exception {
> final String tmpDir = System.getProperty("java.io.tmpdir");
> try {
> final JarFile jarFile = new JarFile(tmpDir + File.separator
> + "*");
> } catch (IOException ioe) {
> System.out.println("Got the expected IOException " + ioe);
> }
> }
> }
>
> The constructor of the JarFile is passed a string which intentionally is
> an (wildcard) invalid path. The above code (as expected) throws an
> IOException on *nix systems across various version of Java (tested
> against Java 8, 11). The same code throws an IOException (as expected)
> in Java 8 on Windows OS too. However, in Java 11, on Windows OS, this
> code throws a different exception (java.nio.file.InvalidPathException)
> which isn't IOException or a subclass of it:
>
> Exception in thread "main" java.nio.file.InvalidPathException: Illegal
> char <*> at index 38: C:\Users\someone\AppData\Local\Temp\1\*
> at
> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> at
> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
> at java.base/java.io.File.toPath(File.java:2290)
> at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1220)
> at
> java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727)
> at java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:845)
> at java.base/java.util.zip.ZipFile.(ZipFile.java:245)
> at java.base/java.util.zip.ZipFile.(ZipFile.java:175)
> at java.base/java.util.jar.JarFile.(JarFile.java:341)
> at java.base/java.util.jar.JarFile.(JarFile.java:312)
> at java.base/java.util.jar.JarFile.(JarFile.java:251)
> at JarFileTest.main(JarFileTest.java:8)
>
>
> The javadoc of JarFile constructor(s) mentions that:
>
> * @throws IOException if an I/O error has occurred
>
> Given that the javadoc doesn't mention anything about this other
> exception, would this throwing of java.nio.file.InvalidPathException be
> considered a bug in the implementation?
>
> If this indeed is considered a bug, it appears to be the code in
> java.util.zip.ZipFile$Source.get method which calls File#toPath(), which
> as per its javadoc is indeed expected to throw an
> java.nio.file.InvalidPathException if a Path cannot be constructed out
> of the File. Looking at the implementation of the underlying
> java.nio.file.FileSystem on *nix and Windows, they differ when it comes
> to whether or not the exception gets thrown (Unix one seems to always
> return a result). But keeping the implementation of
> java.nio.file.FileSystem aside, I guess the
> java.util.zip.ZipFile$Source.get code needs to have a catch block for
> the InvalidPathException to wrap that into a IOException? Something like:
>
>
> # HG changeset patch
> # User Jaikiran Pai
> # Date 1538645309 -19800
> # Thu Oct 04 14:58:29 2018 +0530
> # Node ID ff1bfd8cc9a3b385716fa5191bb68989d552f87e
> # Parent 8705c6d536c5c197d0210acccf145ebc48f90227
> Wrap and throw an IOException when a InvalidPathException is thrown
>
> diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java
> b/src/java.base/share/classes/java/util/zip/ZipFile.java
> --- a/src/java.base/share/classes/java/util/zip/ZipFile.java
> +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java
> @@ -35,6 +35,7 @@
> import java.lang.ref.Cleaner.Cleanable;
> import java.nio.charset.Charset;
> import java.nio.charset.StandardCharsets;
> +import java.nio.file.InvalidPathException;
> import java.nio.file.attribute.BasicFileAttributes;
> import java.nio.file.Files;
> import java.util.ArrayDeque;
> @@ -1218,8 +1219,13 @@
>
>
> static Source get(File f
Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
Yes you are right @apinote is aproperiate section (was confusing it with
implnote).
Still think a ‚literal specified list‘ is no longer a good (as in canonical)
usecase for that method.
I used it in the past often to get a List for using toString() on it, but I
guess even for that case List.of can be used instead now.
So @see List#of and let the reader figure out when to use them?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Jaikiran Pai
Gesendet: Donnerstag, September 6, 2018 9:13 AM
An: Bernd Eckenfels; core-libs-dev@openjdk.java.net
Betreff: Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
Hello Bernd,
Thank you for the review and sorry about the delayed response. Comments inline.
On 29/08/18 4:26 PM, Bernd Eckenfels wrote:
Hello,
Not an Reviewer But just wanted to give a short Feedback: I like the new
Version it is really helpful.
However I wonder if the usage example should be outside of the apinote.
+ * @apiNote
+ * This method also provides a convenient way to create a fixed-size
* list initialized to contain several elements:
*
* List stooges = Arrays.asList("Larry", "Moe", "Curly");
*
*
My limited understanding of the @apiNote is that it is supposed to be used for
additional details of the API and/or its usage examples and the javadoc itself
(outside of the @apiNote) should be a specification of the API. In this case, I
moved that section to @apiNote since that part appears to mention how/when to
use that API in. Having said that, I can move it out of @apiNote and let it
stay the way it previously was, if you and others feel that's the way to go.
Given the existence of List.of() I wonder if you either mention it as a
alternative to the example (with slightly different semantic) or just remove
the sample completely?
I'm not too sure mentioning List.of() construct here will be useful, but I do
see why you mention that. I think the existing example does seem like a useful
usage example, irrespective of whether or not we decide to have it in or
outside of an @apiNote.
-Jaikiran
Re: Are TimeZone instances guaranteed to be thread-safe
Ah BTW, there is a TimeZone.getTimezone(ZoneOffset.UTC) construct which can be used. The ZoneId is also immutable, but that construct does say nothing about TimeZone instance. Gruss Bernd -- http://bernd.eckenfels.net Von: Bernd Eckenfels Gesendet: Samstag, September 1, 2018 3:22 AM An: core-libs-dev@openjdk.java.net Betreff: Are TimeZone instances guaranteed to be thread-safe Hello, I am not sure I missed it, but it looks like there is no definition in the JCL JavaDoc about instances of j.u.TimeZone (specifically SimpleTimeZone as well as instances obtained with getDefault or by Id) beeing reentrant/thread Safe or not. (There are for examplequite a few non-final fields in SimpleTimeZone as well), Since TimeZone is used together with Calendar it might be natural for developers to know. Is there a helper/factory which would allow access to some standard timezones (at least GMT/UTC). This might be especially useful if we cannot define TimeZone instances generally as thread safe, because then we can at least declare it for this „fast“ implementation. [ Background of my question is BTW the rs.getTimestamp(idx, Calendar) method in the JDBC API where the need for constructing a Calendar object is painful and it would help if I could at least use new Calendar(SimpleTimeZone.UTC). (And having an alternative like getTimestamp(Int, ZoneId) would be even better ] I can imagine naming it GMT vs. UTC might also be a nice bike shed. Gruss Bernd -- http://bernd.eckenfels.net
Are TimeZone instances guaranteed to be thread-safe
Hello, I am not sure I missed it, but it looks like there is no definition in the JCL JavaDoc about instances of j.u.TimeZone (specifically SimpleTimeZone as well as instances obtained with getDefault or by Id) beeing reentrant/thread Safe or not. (There are for examplequite a few non-final fields in SimpleTimeZone as well), Since TimeZone is used together with Calendar it might be natural for developers to know. Is there a helper/factory which would allow access to some standard timezones (at least GMT/UTC). This might be especially useful if we cannot define TimeZone instances generally as thread safe, because then we can at least declare it for this „fast“ implementation. [ Background of my question is BTW the rs.getTimestamp(idx, Calendar) method in the JDBC API where the need for constructing a Calendar object is painful and it would help if I could at least use new Calendar(SimpleTimeZone.UTC). (And having an alternative like getTimestamp(Int, ZoneId) would be even better ] I can imagine naming it GMT vs. UTC might also be a nice bike shed. Gruss Bernd -- http://bernd.eckenfels.net
Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
Hello,
Not an Reviewer But just wanted to give a short Feedback: I like the new
Version it is really helpful.
However I wonder if the usage example should be outside of the apinote.
Given the existence of List.of() I wonder if you either mention it as a
alternative to the example (with slightly different semantic) or just remove
the sample completely?
„Similiar to List.of() which constructs an unmodifiable List from given
elements Arrays.asList() can be used to construct a List from a fixed size of
Elements. Both constructs won’t allow structural changes to the resulting List,
however when constructed with asList() the content could be modified.“
But I must honestly say this would encourage a usage which is a bit
questionable in many cases?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: -997621984m Auftrag von
Gesendet: Mittwoch, August 29, 2018 9:07 AM
An: core-libs-dev@openjdk.java.net
Betreff: Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
Anyone willing to help review the patch, please?
-Jaikiran
On 20/08/18 5:56 PM, Jaikiran Pai wrote:
> Hello everyone,
>
> I'm requesting a review of a documentation change which was discussed in
> a recent thread[1][2]. Here's an initial proposed draft, for a better
> documentation of Arrays.asList method:
>
> /**
> * Returns a fixed-size list backed by the specified array. The passed
> * array is held as a reference in the returned list. Any subsequent
> * changes made to the array contents will be visible in the returned
> * list. Similarly any changes that happen in the returned list will
> * also be visible in the array. The returned list is serializable and
> * implements {@link RandomAccess}.
> *
> * The returned list can be changed only in certain ways. Operations
> * like {@code add}, {@code remove}, {@code clear} and other such, that
> * change the size of the list aren't allowed. Operations like
> * {@code replaceAll}, {@code set}, that change the elements in the list
> * are permitted.
> *
> * This method acts as bridge between array-based and
> collection-based
> * APIs, in combination with {@link Collection#toArray}.
> *
> * @apiNote
> * This method also provides a convenient way to create a fixed-size
> * list initialized to contain several elements:
> *
> * List<String> stooges = Arrays.asList("Larry", "Moe",
> "Curly");
> *
> *
> * The returned list throws a {@link
> UnsupportedOperationException} for
> * operations that aren't permitted. Certain implementations of the
> returned
> * list might choose to throw the exception only if the call to such
> methods
> * results in an actual change, whereas certain other
> implementations may
> * always throw the exception when such methods are called.
> *
> * @param the class of the objects in the array
> * @param a the array by which the list will be backed
> * @return a list view of the specified array
> */
> @SafeVarargs
> @SuppressWarnings("varargs")
> public static List asList(T... a)
>
>
> I've edited some of the existing documentation of that method, moved
> some existing parts into @apiNote and added additional parts both to the
> spec as well as the @apiNote. For a complete reference of what's
> changed, I've also attached a patch of this change.
>
> P.S: Is there a specific (make) target that I can run to make sure
> changes like this one haven't caused any javadoc generation issues? I
> typically run just "make" and did it this time too, but I'm not sure it
> parses and generates the javadocs (couldn't find it in the generated
> exploded build image).
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054894.html
>
> [2] https://bugs.openjdk.java.net/browse/JDK-7033681
>
> -Jaikiran
Re: (XS) java.logging Level.java minor cleanups
Hello Mandy, the fields Level#name, Level#value and resourceBundleName accessed from KnownLevel inner class are private and therefore an synthetic accessor will be used. Eclipse warns about this. But, Looking at it again, it is not only a non-issue with JEP 181 in Java 11, it is also hard to fix for 8u since the Level class is public and so the fields really should stay private. (I gues I was just suprised to see any synthetic accessors in Performance critical JCL classes) Gruss Bernd -- http://bernd.eckenfels.net Von: mandy chung Gesendet: Donnerstag, 23. August 2018 22:02 An: Bernd Eckenfels; Daniel Fuchs Cc: core-libs-dev@openjdk.java.net Betreff: Re: (XS) java.logging Level.java minor cleanups On 8/23/18 2:49 PM, Bernd Eckenfels wrote: > > Did you had any opinion on the synthetic accessors as well? : >> BTW: I get a synthetic Accessor warning on l.name/value, is this >> what nestmates will resolve – is it worth adjusting the modifiers for>> those fields anyway? What warning message did you get? Mandy
Re: (XS) java.logging Level.java minor cleanups
Yes, Seeburger AG OCA should be on file (b.eckenf...@seeburger.de)
Thanks for following up
Did you had any opinion on the synthetic accessors as well?
Gruß
Bernd
--
https://Bernd.eckenfels.net
Von: Daniel Fuchs
Gesendet: Donnerstag, August 23, 2018 11:20 AM
An: Bernd Eckenfels; core-libs-dev@openjdk.java.net
Betreff: Re: (XS) java.logging Level.java minor cleanups
Hi Bernd,
Good finding! I agree with the proposed cleanup.
I am always a bit uneasy of touching these classes
as they have a propensity to come back and bite you
from behind when you're not looking ;-)
I have applied your patch and sent it to our test system
for more confidence and everything went well.
I'll happily sponsor your patch.
You did sign the OCA - right?
MfG,
-- daniel
On 11/08/2018 20:31, Bernd Eckenfels wrote:
> Hello,
>
> while investigating a Memory leak fix from IBM (IJ05380 is in 8.0.5.20 but
> not in 8u yet) I noticed that the (fixed) code registerWithClassLoader(Level)
> in the master queries a unused class name (pn) and it can use the method
> reference instead of Lambda. See patch below.
>
> There seems to be also a opportunity to use computeIfAbsent in a unrelated
> method add(Level), not sure if this is wanted, what do you think?
>
>
> index dbc27124d33..401c6dc73e0 100644
> --- a/src/java.logging/share/classes/java/util/logging/Level.java
> +++ b/src/java.logging/share/classes/java/util/logging/Level.java
> @@ -610,10 +610,7 @@ public class Level implements java.io.Serializable {
> }
>
> private static void registerWithClassLoader(Level customLevel) {
> - PrivilegedAction pa =
> - () -> customLevel.getClass().getClassLoader();
> - PrivilegedAction pn = customLevel.getClass()::getName;
> - final String name = AccessController.doPrivileged(pn);
> + PrivilegedAction pa = customLevel.getClass()::getClassLoader;
> final ClassLoader cl = AccessController.doPrivileged(pa);
> CUSTOM_LEVEL_CLV.computeIfAbsent(cl, (c, v) -> new ArrayList<>())
> .add(customLevel);
> @@ -624,19 +621,10 @@ public class Level implements java.io.Serializable {
> // the mirroredLevel object is always added to the list
> // before the custom Level instance
> KnownLevel o = new KnownLevel(l);
> - List list = nameToLevels.get(l.name);
> - if (list == null) {
> - list = new ArrayList<>();
> - nameToLevels.put(l.name, list);
> - }
> - list.add(o);
> -
> - list = intToLevels.get(l.value);
> - if (list == null) {
> - list = new ArrayList<>();
> - intToLevels.put(l.value, list);
> - }
> - list.add(o);
> + nameToLevels.computeIfAbsent(l.name, (k) -> new ArrayList<>())
> + .add(o);
> + intToLevels.computeIfAbsent(l.value, (k) -> new ArrayList<>())
> + .add(o);
>
> // keep the custom level reachable from its class loader
> // This will ensure that custom level values are not GC'ed
>
>
> I am happy if anyone can sponsor this change.
>
> BTW: I get a synthetic Accessor warning on l.name/value, is this what
> nestmates will resolve – is it worth adjusting the modifiers for those fields
> anyway?
>
> Gruss
> Bernd
>
Re: Removing the Barrier
You can remove all comments you like. If you do not distribute the resulting binaries you do not need to provide the changes/source you made (that’s a legal requirement from the GPL license). If you do need to provide source (because you distribute binaries) then you have to retain at least all copyright messages and license headers. This assumes the comments have no technical function, this is true for normal code but not formsome parts like for example tests where execution parameters can be found in the comments. I am not sure about other locations where code generation references comments is used (but simply speaking if a comment looks unstructured it probably has no function) Also keep in mind that comments are visible if you generate Javadoc or need to use src.zip (think IDEs) Having said all that, that kind of shredded code does not get you very far, it will certainly not allow to contribute changes back to OpenJDK projects. Besides changing all line numbers (by removing comments from Java classes) also makes interpreting stacktraces harder. Gruss Bernd -- http://bernd.eckenfels.net Von: -1060516144m Auftrag von Gesendet: Mittwoch, August 15, 2018 7:35 PM An: core-libs-dev@openjdk.java.net Betreff: Removing the Barrier Can you explain how to remove the requirement for comments in the OpenJDK build in the Java source files? It's really killing my schedule to have to reinsert comments by hand. Thanks. Max R. Software Developer
Re: C files and their Mapping(s)
If a Java class from does not use native Methods then no corresponding native implementation is existing/needed (with the Special exception of intrinsics). Most of the JCL is purely Java. What is it you want to modify? Gruss Bernd -- http://bernd.eckenfels.net Von: mr rupplin Gesendet: Samstag, 11. August 2018 22:17 An: core-libs-dev@openjdk.java.net Betreff: C files and their Mapping(s) Hello. Thanks for taking time. We had a quick question about the Java to C mappings in the JDK. For instance the System.java has a corresponding System.c and even a System.o. We find these without too much problem. However many of the "core" packages (corba, nashorn, jaxp, jaxws) do not have a corresponding C source folder. If we were to make changes to System.java we would, for example, also make changes to System.c. It is quickly clear then that we would need a mechanism for altering the remaining java classes. Since these do not have a C file what do we then alter? How would we rewrite a method, add one, etc.? -- -- -- -- Thank you, Max
(XS) java.logging Level.java minor cleanups
Hello,
while investigating a Memory leak fix from IBM (IJ05380 is in 8.0.5.20 but not
in 8u yet) I noticed that the (fixed) code registerWithClassLoader(Level) in
the master queries a unused class name (pn) and it can use the method reference
instead of Lambda. See patch below.
There seems to be also a opportunity to use computeIfAbsent in a unrelated
method add(Level), not sure if this is wanted, what do you think?
index dbc27124d33..401c6dc73e0 100644
--- a/src/java.logging/share/classes/java/util/logging/Level.java
+++ b/src/java.logging/share/classes/java/util/logging/Level.java
@@ -610,10 +610,7 @@ public class Level implements java.io.Serializable {
}
private static void registerWithClassLoader(Level customLevel) {
-PrivilegedAction pa =
- () -> customLevel.getClass().getClassLoader();
-PrivilegedAction pn = customLevel.getClass()::getName;
-final String name = AccessController.doPrivileged(pn);
+PrivilegedAction pa =
customLevel.getClass()::getClassLoader;
final ClassLoader cl = AccessController.doPrivileged(pa);
CUSTOM_LEVEL_CLV.computeIfAbsent(cl, (c, v) -> new ArrayList<>())
.add(customLevel);
@@ -624,19 +621,10 @@ public class Level implements java.io.Serializable {
// the mirroredLevel object is always added to the list
// before the custom Level instance
KnownLevel o = new KnownLevel(l);
-List list = nameToLevels.get(l.name);
-if (list == null) {
-list = new ArrayList<>();
-nameToLevels.put(l.name, list);
-}
-list.add(o);
-
-list = intToLevels.get(l.value);
-if (list == null) {
-list = new ArrayList<>();
-intToLevels.put(l.value, list);
-}
-list.add(o);
+nameToLevels.computeIfAbsent(l.name, (k) -> new ArrayList<>())
+.add(o);
+intToLevels.computeIfAbsent(l.value, (k) -> new ArrayList<>())
+.add(o);
// keep the custom level reachable from its class loader
// This will ensure that custom level values are not GC'ed
I am happy if anyone can sponsor this change.
BTW: I get a synthetic Accessor warning on l.name/value, is this what nestmates
will resolve – is it worth adjusting the modifiers for those fields anyway?
Gruss
Bernd
--
http://bernd.eckenfels.net
File Attributes from DirectoryStream (WindowsPathWithAttributes)?
Hello, in sun.nio.fs.WindowsDirectoryStream I see that the code which iterates the Directory goes to some length to retain the file attributes returned from that function (by attaching them to a WindowsPathWithAttributes (aka BasicFileAttributesHolder). And indeed I can see that class in my DirectroyStream Iterator or Filter. However I do not see that the normal WindowsFilesystemProvider (or actually WindowsFileAttributes#get() check for instances of that. This way None of the Files.getAttributeView seem to Benefit from that. So I wonder is this missing or is there some other way you are supposed to work with this cached Attributes? For 8 I can work with instanceof, but that might no longer be an Option with JPMS. Gruss Bernd -- http://bernd.eckenfels.net
List Windows FileStores misses named mounts
Hello,
I noticed that fs.getRootDirectories() or fs.getFileStores() on Windows only
list the Windows drives, but not other disks mounted on a path.
When I do the following I actually do get a FileStore for a Name-mounted FS:
FileSystem fs = FileSystems.getDefault();
Iterable rootStores = fs.getFileStores();
printStores(rootStores);
Path disk = Paths.get("C:", "temp", "disk").toAbsolutePath(); //
mountpoint
FileSystemProvider fsp = FileSystemProvider.installedProviders().get(0);
FileStore fss = fsp.getFileStore(disk);
printStore(fss)
this is the result on my Windows (USB+Virtual Drive Name mounted)
root dir C:\
root dir D:\
(C:) (NTFS) 17.658,68 MB 243.303,05 MB
rw r?=false cd?=false vsn=N/A on C:\
MYLINUXLIVE (D:) (FAT32)226,73 MB 957,50 MB
rw r?=true cd?=false vsn=N/A on D:\
--
vdisk (C:\temp\disk) (NTFS) 3,27 MB 7,00 MB
rw r?=false cd?=false vsn=N/A on C:\temp\disk
Code: https://gist.github.com/ecki/da76c0e724e947ebb77a05094dac1f5c
Is there a reason why named Mounts are not listed and is there a cleaner way
(without going through the FSP SPI) to get to its FileStore
Also what I noticed is that the „root“ member in WindowsFileSystem is the
identifying part but there is no API (other than parsing .toString()) to get to
it?
Gruss
Bernd
--
http://bernd.eckenfels.net
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Hello, Will there be: - support for displaying and asking for acceptance of license text - asking for target directory (installing outside of programfiles) - starting optional post-Installation class - menu entries - user vs. System wide Installation (on windows) - the new launchers also be available as jlink plugin - theming Installer Gruss Bernd -- http://bernd.eckenfels.net Von: -974640832m Auftrag von Gesendet: Donnerstag, Juli 26, 2018 2:12 AM An: core-libs-dev@openjdk.java.net Betreff: Re: Draft JEP proposal: JDK-8200758: Packaging Tool Thank you to all who provided feedback. I have updated the draft JEP [1], and I think I have incorporated most of the feedback I received. Specifically, I have reorganized and reworded a few things for clarity, added '.exe' and '.app in a .dmg' native package format to the list of features, and added the service bundler (daemon) feature to the "if we have time" list (at the top of that list). Please let me know if I missed an important point. I hope to submit this JEP in the next week or two. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 On 5/30/2018 5:10 PM, Kevin Rushforth wrote: > I would like to propose the following Draft JEP [1] for discussion. > > JDK-8200758: Packaging Tool > > This is intended as a JDK-scope replacement for the existing > javapackager tool that ships with Oracle JDK 10 (and earlier Oracle > JDK releases), and was delivered as part of the JavaFX build. The > javapackager tool has been removed from Oracle JDK 11 along with the > removal of JavaFX. > > Comments on this JEP are welcome. It is currently not targeted for a > specific release, but we are aiming for JDK 12. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >
Re: RFR 8207750 : Native handle leak in java.io.WinNTFileSystem.list()
Hello, I am not sure about the JNi conventions, but does the jObjectArray rv need to be released as local reference in some of the early returns as well? Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net Von: -1031249216m Auftrag von Gesendet: Mittwoch, Juli 18, 2018 4:38 AM An: Ivan Gerasimov Cc: core-libs-dev Betreff: Re: RFR 8207750 : Native handle leak in java.io.WinNTFileSystem.list() Hi Ivan, This looks all right to me. Thanks, Brian On Jul 17, 2018, at 5:01 PM, Ivan Gerasimov wrote: > In the file WinNTFileSystem_md.c there is a potential leak of native handle > obtained from FindFirstFileW() in the unfortunate event of memory allocation > failure. > > Would you please help review a simple fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8207750 > WEBREV:http://cr.openjdk.java.net/~igerasim/8207750/00/webrev/
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
You can add-modules from the JDK (only), so if you „—add-modules lang.base,JDK.jcmd,jdk.crypto.mscapi“ you get a super compact JRE which still can start your app from the classpath. Gruss Bernd -- http://bernd.eckenfels.net Von: Remi Forax Gesendet: Donnerstag, 28. Juni 2018 22:05 An: Bernd Eckenfels Cc: core-libs-dev Betreff: Re: Draft JEP proposal: JDK-8200758: Packaging Tool no you can't, --add-modules requires the module to have a module-info, being an automatic module is not good enough. regards, Rémi - Mail original - > De: "Bernd Eckenfels" > À: "core-libs-dev" > Envoyé: Jeudi 28 Juin 2018 17:34:35 > Objet: Re: Draft JEP proposal: JDK-8200758: Packaging Tool > you can jlink without any/complete module info files by specifying the module > names on the command line (--add-modules)as well. It produces a jre like > Directory including Java launcher which allows additions on the classpath. > > -- > https://Bernd.eckenfels.net > > From: core-libs-dev on behalf of > Scott > Palmer > Sent: Thursday, June 28, 2018 2:32:13 PM > To: Kevin Rushforth > Cc: core-libs-dev@openjdk.java.net > Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool > > Doesn’t jlink require a *fully* modularized application? I.e. no non-module > dependencies. > The packaging tool should work with all runnable Java applications, not just > fully modularized ones. > > Modularization seems to be a bit of an effort and is one of the main reasons > my > application(s) are still stuck on Java 8. > > Scott > > > >> On Jun 27, 2018, at 6:30 PM, Kevin Rushforth >> wrote: >> >> We're aiming to get this into JDK 12 early enough so that an EA build would >> be >> available around the time JDK 11 ships. That will allow you to take a jlinked >> image with JDK 11 and package it up using (the EA) jpackager. >> >> We will create a development branch in the JDK sandbox [1] some time in the >> next >> week or so so you can follow the development. >> >> Also, thank you to those who have provided feedback. I'll reply to feedback >> soon >> and then incorporate it into an updated JEP. >> >> -- Kevin >> >> >> On 6/27/2018 3:09 AM, Buchberger, Joerg wrote: >>> Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I >>> really mean it] >>> >>> But, to sum up my comprehension... >>> >>> anyone who placed their bets on javapackager, starting with last LTS Java 8 >>> will be left in the rain with followup LTS Java 11, because their ain't >>> neither >>> javapackager (anymore), nor jpackager (yet). >>> >>> Is this correct? >>> >>> So, strategic choice boils down to either throw away all work done based on >>> javapackager so far and the associated distribution concepts (reworking >>> everything from scratch) >>> or neglect Java 11 completely, thus placing all bets on jpackager really >>> coming >>> w/ Java 12 or even waiting for Java 14 as next LTS thereafter. >>> >>> Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in >>> ... >>> >>> Cheers >>> Jörg >>> >>> >>> On 5/31/2018 0:10 AM, Rushforth, Kevin wrote: >>>> I would like to propose the following Draft JEP [1] for discussion. >>>> >>>> JDK-8200758: Packaging Tool >>>> >>>> This is intended as a JDK-scope replacement for the existing >>>> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK >>>> releases), and was delivered as part of the JavaFX build. The >>>> javapackager tool has been removed from Oracle JDK 11 along with the >>>> removal of JavaFX. >>>> >>>> Comments on this JEP are welcome. It is currently not targeted for a >>>> specific release, but we are aiming for JDK 12. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>>>
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
you can jlink without any/complete module info files by specifying the module names on the command line (--add-modules)as well. It produces a jre like Directory including Java launcher which allows additions on the classpath. -- https://Bernd.eckenfels.net From: core-libs-dev on behalf of Scott Palmer Sent: Thursday, June 28, 2018 2:32:13 PM To: Kevin Rushforth Cc: core-libs-dev@openjdk.java.net Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool Doesn’t jlink require a *fully* modularized application? I.e. no non-module dependencies. The packaging tool should work with all runnable Java applications, not just fully modularized ones. Modularization seems to be a bit of an effort and is one of the main reasons my application(s) are still stuck on Java 8. Scott > On Jun 27, 2018, at 6:30 PM, Kevin Rushforth > wrote: > > We're aiming to get this into JDK 12 early enough so that an EA build would > be available around the time JDK 11 ships. That will allow you to take a > jlinked image with JDK 11 and package it up using (the EA) jpackager. > > We will create a development branch in the JDK sandbox [1] some time in the > next week or so so you can follow the development. > > Also, thank you to those who have provided feedback. I'll reply to feedback > soon and then incorporate it into an updated JEP. > > -- Kevin > > > On 6/27/2018 3:09 AM, Buchberger, Joerg wrote: >> Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I >> really mean it] >> >> But, to sum up my comprehension... >> >> anyone who placed their bets on javapackager, starting with last LTS Java 8 >> will be left in the rain with followup LTS Java 11, because their ain't >> neither javapackager (anymore), nor jpackager (yet). >> >> Is this correct? >> >> So, strategic choice boils down to either throw away all work done based on >> javapackager so far and the associated distribution concepts (reworking >> everything from scratch) >> or neglect Java 11 completely, thus placing all bets on jpackager really >> coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter. >> >> Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in >> ... >> >> Cheers >> Jörg >> >> >> On 5/31/2018 0:10 AM, Rushforth, Kevin wrote: >>> I would like to propose the following Draft JEP [1] for discussion. >>> >>> JDK-8200758: Packaging Tool >>> >>> This is intended as a JDK-scope replacement for the existing >>> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK >>> releases), and was delivered as part of the JavaFX build. The >>> javapackager tool has been removed from Oracle JDK 11 along with the >>> removal of JavaFX. >>> >>> Comments on this JEP are welcome. It is currently not targeted for a >>> specific release, but we are aiming for JDK 12. >>> >>> -- Kevin >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>> >
Re: free(): corrupted unsorted chunks
Are you using any native libraries in this VM, is there a hs_err or System core file? Can you run „ldd“ on the java launcher binary. Can you try a OpenJDK binary distribution independent of the OS compiled version? Gruss Bernd -- http://bernd.eckenfels.net From: core-libs-dev on behalf of Oliver Kohll Sent: Thursday, June 21, 2018 1:59:27 PM To: core-libs-dev@openjdk.java.net Subject: free(): corrupted unsorted chunks Hi, I'm a Java developer getting a crash and error message 'free(): corrupted unsorted chunks' in the log. this sounds like it could be a low level issue in the core Java libraries so I'm posting here, but if it would be better in another list (or even a different community) please let me know. So I'm requesting help because I don't know how to debug this further. In summary, the issue is We're getting a crash nearly once a day on our production system, at a time of day when it's most busy (mid morning). This crash hasn't been seen on our development environment, which is the same apart from the server has less memory and CPU resources. The environment is: * A VPS host * Ubuntu LTS 18 (Bionic) * The default Java 10 packaged as 11 I believe ( https://askubuntu.com/questions/1037646/why-is-openjdk-10-packaged-as-openjdk-11 ) * However, javac seems to be from JDK8: root@server:~# file /etc/alternatives/java /etc/alternatives/javac /etc/alternatives/java: symbolic link to /usr/lib/jvm/java-11-openjdk-amd64/bin/java /etc/alternatives/javac: symbolic link to /usr/lib/jvm/java-8-openjdk-amd64/bin/javac We're running our webapp on Tomcat 8 (also the Ubuntu default). When this happens, the server stops responding to HTTP requests (in fact the java process has quit) and needs to be restarted. The crash doesn't seem to correspond to a particular activity on the server as far as I can see, though it's hard to tell as many people are logged in at the same time. Does anyone have any pointers of a) how to track the bug further so I can report it, ideally without a big impact on our live server b) more immediately, any workarounds to try In the meantime I will see if I can downgrade to JDK8 on the test server, but I'm not sure if that's possible or whether it would make a difference. Regards Oliver
Re: RFC: Add new JCA provider to support hardware RNGs
Just a FYI under Linux when you read from urandom the Linux kernel will always XOR with random bytes generated with x64 rdrand instruction (arch_get_random_lomg() - if supported). Since it is a XOR it does not have to trust the quality of this black box hardware implementation. I would not implement a generator which does not have its own software whitening. (And most likely there is no need for one different than urandom on Linux). If you do implement whitening I would use a DRBG construction and no longer use a (low state) SHA1PRNG. Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net From: core-libs-dev on behalf of Gustavo Romero Sent: Wednesday, June 20, 2018 2:59:47 AM To: core-libs-dev; security-dev Cc: vladimir.koz...@oracle.com; Doerr, Martin Subject: RFC: Add new JCA provider to support hardware RNGs Hi, Please, could I get comments on the following change? Since it's related to security, I would be glad if security experts could also comment on that. webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/ It introduces a way to get benefits from hardware instructions in userspace that can delivery a random number and so be used to speed up and avoid blocking in some SecureRandom methods, notably generateSeed() and nextBytes(), without loosing the random number quality. Particularly on Power, the new POWER9 CPUs introduced a hardware instruction called 'darn' that can be used for that purpose. The main idea is to add a new JCA provider called "HWTRNG" (if no better name is suggested), adding new helper methods that can then be intrinsified and that will be used by generateSeed() and nextBytes(). In that sense, this change also adds the proper mechanisms in the Interpreter, C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other platforms) to intrinsify these helper methods that will be used in the end by generateSeed() and nextBytes() methods. The added helpers are: byte[] getRandomSequence0(int) byte[] getRandomSequence1(byte[]) long validRandomLong(void) long randomLong(void) The helpers also take care of checking if the returned random number is valid and attempt 10 times (as recommended by ISA) get a valid random number before falling back to a software alternative (HWTRNG is based mostly on JCA provider NativePRNG and so the fall back mechanism will use the exactly same methods found in NativePRNG and hence behave similarly. Nonetheless, in my experience such a hardware failures (which are the main cause of a returned invalid random number) are quite rare: in my tests I was never able to exhaust the HW RNG and force it to generate an invalid random number). The user, besides having to specify explicitly the use of a non-default provider (HWTRNG), will have to unlock the VM experimental options to effectively use the hardware RNG as an unique random source by passing options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics". On Power, for the Interpreter and C1 Compiler, besides avoiding the blocking effect of a low entropy on /dev/random, I was able to get about 126 Mbps (3x higher than the version without 'darn') on generaSeed() and nextBytes(). The maximum theoretical value on a POWER9 machine is usually 128 Mbps. I'll address the details about the file headers (Copyright, dates, authors, versions, etc) after I get some feedback about this change. Thanks in advance. Best regards, Gustavo
