I am trying to migrate to java 19 from java 18.
Here is the code I run:
NumberFormat currencyFormatter = NumberFormat.getCurrencyInstance(Locale.CANADA_FRENCH);
currencyFormatter.setMaximumFractionDigits(2);
currencyFormatter.setCurrency(Currency.getInstance(Locale.CANADA_FRENCH));
var result = currencyFormatter.format(100);
System.out.println(result);
It gives different results for those 2 java versions.
Java 18:
100,00 $ CA
Java 19:
100,00 $
I cannot find any details in release notes regarding that change. Am I doing something wrong, or this is expected ?
I cannot find any details in release notes regarding that change.
That's true. You will not find any because maintaining localization changes is not a responsibility of the JDK team. Each JDK release (since 9, see JEP-252) uses embeded data from The Unicode Common Locale Data Repository (CLDR) to produce given locale ouput. The CLDR has it's own independent maintainers and release cycle and its contnents may change inbetween JDK releases. That means you should be aware of potential changes in that matter without being notified by the JDK team. As Joachim Sauer mentioned in the comment (he was working on JDK and JEP-252 implementation), if your code relies on these changes you can always override the defaults and use custom formatting rules.
You can get more context about CLDR in What is Common Locale Data Repository (CLDR) - JDK 9.
Related
When Javadoc processed a package-info.java file in Java 8, the output placed the Javadoc comments (except for the summary sentence) after the generated class and other summary tables. Here is a Java 8 example: https://docs.oracle.com/javase/8/docs/api/java/nio/file/package-summary.html
Sometime between Java 8 and Java 11 this changed, and the Javadoc output in Java 11 now places all Javadoc comments before the generated class and other summary tables. Here is the same example in Java 11: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/package-summary.html
What I'd like, but have been unable to find, is a way to control this behavior in Java 11. I'd prefer to revert to the Java 8 behavior (in Java 11) or, even better, to be able
to control this behavior such that some package comments appear before and some after the summary tables.
Is there a way to control this Javadoc behavior in Java 11? At the moment I am constrained to Java 11 and cannot use features from earlier or later versions.
From Oracle
You can customize the content and format of the javadoc command output
with doclets. The javadoc command has a default built-in doclet,
called the Standard Doclet, that generates HTML-formatted API
documentation. You can write your own doclet to generate HTML, XML,
MIF, RTF or whatever output format you want.
The StandardDoclet delegates to HtmlDoclet. You might be able to get away with subclassing that and overriding generatePackageFiles.
IMO probably not worth the effort, but hey.
How can I find the Public Suffix List version Guava is using? Is there a command to see the version when I have the package installed? Or is there some note in the release notes I am missing?
I see that they use Mozilla Foundation's Public Suffix List but this list seems to update much more frequently than Guava releases. Does Guava pull the latest every time they do a release? This question I hope to answer once I know where to find the version.
We don't document which version we're using. But you can look at PublicSuffixPatterns at some release tag and follow the link to the commit that updated it most recently. That should tell you approximately how old the data is.
Traditionally, we updated about every 6 weeks, and the file history suggests that that's still approximately correct.
Ideally someday we'll provide a way for users to regenerate the patterns file themselves, but we haven't yet.
you can see that guava uses it's own sort of engine to acknowledge theses values, but it's engine is well documented Here
This question is related to an issue raised for Maven, which doesn't seem to escape paths forwarded to argument files supported by the JavaDoc-tool on Windows. The problem is that it's unclear from the documentation of JavaDoc itself how paths under Windows should be provided in those files.
The following is for Java 7:
If a filename contains embedded spaces, put the whole filename in double quotes, and double each backslash ("My Files\Stuff.java").
https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
The following from Java 8:
If a file name contains embedded spaces, then put the whole file name in double quotation marks.
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html
In docs of Java 11 that part is completely missing, no mention of quotes, spaces or backslashes anymore:
https://docs.oracle.com/en/java/javase/11/javadoc/javadoc-command.html#GUID-EFE927BC-DB00-4876-808C-ED23E1AAEF7D
If you have a look at the URIs, in former versions of Java they were Windows-specific, while the last one is not. So I guess things have been refactored and some details of the argument files have been simply lost.
So, I need a place where I can talk to people about those differences in the documentation AND in the end how things are supposed to work on Windows. If backslash is an escape character in paths only and all that stuff. I would simply like to get some awareness from people who might know why the docs lack some details now and maybe even provide those details again.
So who/where do I write to? I don't know if it's Oracle or the OpenJDK project or someone completely different. Thanks!
I think, but don't take that authoritatively too lightly, that the javadoc tool is just an optional tool (can anyone show a formal obligation for any JDK to include a javadoc tool implementation ?) with a kind of de-facto standard set by the original owners, Sun thence Oracle.
But de-facto is only de-facto. Meaning formally and strictly speaking, that no JDK implementer has any obligation to make his javadoc tool behave like all the others do.
I think the best two places are the javadoc-dev mailinglist as well as the bugs database. Starting at some point in time (9, I guess) the have unified the parsing of the #files across tools. I have failed to find the code in the Mercurial repo last time.
Eclipse Data Tools Platform has a “Driver Definitions” entry, where you can indicate the JDBC drivers you want to use. When adding one, the wizard asks you to select a “driver template” from a provided list. In my eclipse Neon Java EE version, the list contains, among others, [Name=Other Driver; System Vendor=Derby; System Version=10.2], and [Name=Other Driver; System Vendor=Derby; System Version=10.1]. I can’t see a difference between these two templates, except that they end up with different indicated System Version as a result of the wizard (expectedly). However, in both cases (selecting the 10.2 line or the 10.1 line), when the wizard asks for a jar containing the driver, I use a jar containing the 10.10 version, so this indicated System Version is incorrect in both cases.
My questions are: how does eclipse use these version numbers? If it does not use them, why does eclipse bother displaying a list with different entries for different versions? Can I get problems if the version of the driver I use does not match the indicated one? Should I somehow tell eclipse the right version I use?
The system version is the supported (minimum) version of the target database. The definition of a higher version can contain new features, keywords, data types etc of that database version. In other words: improved/closer support for the database version you are targeting.
For example on of the differences between the Derby 10.1 definition and Derby 10.2 definition is the default length reported for blobs:
In 10.1:
<predefinedDataTypeDefinitions xmi:id="BINARY_LARGE_OBJECT_1" lengthSupported="true"
defaultLength="1024" maximumLength="2147483647" primitiveType="BINARY_LARGE_OBJECT" jdbcEnumType="2004" javaClassName="java.sql.Blob">
In 10.2:
<predefinedDataTypeDefinitions xmi:id="BINARY_LARGE_OBJECT_1" lengthSupported="true"
defaultLength="2147483647" maximumLength="2147483647" primitiveType="BINARY_LARGE_OBJECT" jdbcEnumType="2004" javaClassName="java.sql.Blob">
Sometimes there might be no difference at all, but a separate (identical) definition might be provided just to avoid confusion for users to indicate that version is supported, and to make it easier to add corrections/improvements at a later time for that specific database version if necessary.
In short: use the version that is closest (but lower than or equal to) the version you are targetting; in this case: use the 10.2 definition.
I wanted to use a particular option -DentityExpansionLimit in java using a jdk and I was unsuccessful on an old version. I there anyway I can see which was the version this option was first implemented on? I was unable to find any answers and was hoping there is like a guide where an option was first implemented or even all the new features implemented for each version. Please let me know.
Seems like it was first introduced in Java 1.4.
Reference Links:
http://docs.oracle.com/javase/7/docs/technotes/guides/xml/jaxp/JAXP-Compatibility_160.html
http://www.oracle.com/technetwork/java/javase/relnotes-139182.html
As per the link:
New system property to limit entity expansion
The entityExpansionLimit system property lets existing applications constrain the total number of entity expansions without recompiling the code. The parser throws a fatal error once it has reached the entity expansion limit. (By default, the limit is set to 64000.)
To set the entity expansion limit using the system property, use an option like the following on the java command line: -DentityExpansionLimit=100000
I think your best option is to use google and check the release notes of each version.
Example: http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-429209.html
In your case, seems like your flag comes from JSDK v1.4.2