So in Java 8 the following:
DateTimeFormatter df = DateTimeFormatter.ofPattern("E d MMM yyyy");
When applied in this manner:
LocalDate date = LocalDate.now();
date.format(df);
Would produce something like this:
"Available on Thu 30 Aug 2018"
However, the exact same code when run in Java 10 produces the following:
"Available on Thu. 30 Aug. 2018"
Notice the periods after the day and month sections...
I'm well aware I can just replace the periods in the string but I really don't want to have to do that. I'm wondering why this change has occurred and if there is an alternative pattern?
I cannot find any reference to this change online.
EDIT:
As per Basil's answer below, it's not a Java version issue. It's a locale issue. The docker image with my code is running on a US locale and my machine on an Aus one :)
Verify Locale
Punctuation and related matters (abbreviation, spelling, order of elements) are defined as part of cultural norms. In Java, these cultural norms are specified by a Locale.
Locale varied at runtime
One possible issue is that you are running code without specifying a Locale explicitly, which means you are relying implicitly on the JVM’s current default locale. That default may differ between runtime environments.
Log your default locale, to verify.
Locale.getDefault().toString()
Study the code example below to see how to specify your Locale explicitly. I recommend always making your Locale explicit (ditto for time zone, by the way).
Definition varied at runtime
Note that a major change happened with regard to date-time localization with Java 9: JEP 252: Use CLDR Locale Data by Default. At least for OpenJDK-based JVMs, the source of information about these cultural norms switched to the Common Locale Data Repository provided by the Unicode Consortium.
For the particular case discussed here, when using Locale.US, we see no difference, as you can see in code example below. But for some locales you may indeed see a difference between Java 8 and earlier versus Java 9 and later.
So, again, I wonder if a different locale was involved in your Question’s second example. The fix would be to specify explicitly the locale you or your user expects, rather than relying implicitly on the JVM’s current momentary default (the default can change at any moment during runtime!).
Cannot confirm problem
System.out.println( System.getProperty( "java.version" ) );
System.out.println( Locale.getDefault().toString() );
LocalDate ld = LocalDate.of( 2018 , Month.AUGUST , 30 );
Locale locale = Locale.US;
DateTimeFormatter f = DateTimeFormatter.ofPattern( "E d MMM yyyy" , locale );
String output = ld.format( f );
System.out.println( output );
When run in Java 10.0.2 via the OpenJDK-based Zulu JVM by Azul Systems in IntelliJ 2018.3 on a MacBook Pro Retina under macOS High Sierra, I get:
10.0.2
en_US
Thu 30 Aug 2018
For Java 8, see this same code run live at IdeOne.com. Be aware that the JVM used in IdeOne.com is fixed to a single Locale only, Locale.US.
en_US
1.8.0_112
output: Thu 30 Aug 2018
Australia
Here is an example of how your output is the norm in some other English-speaking locales, such as Australia.
LocalDate ld = LocalDate.of( 2018 , Month.AUGUST , 30 );
Locale locale = new Locale( "en" , "AU" ); // "en-AU" is English Australia.
DateTimeFormatter f = DateTimeFormatter.ofPattern( "E d MMM yyyy" , locale );
String output = ld.format( f );
Thu. 30 Aug. 2018