FULL PRODUCT VERSION :
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)

A DESCRIPTION OF THE PROBLEM :
In Java 8 you have stopped caching Locales. I can’t see any justification for this and I think it will have negative affect on the larger companies who use multiple locales. The people who originally designed java were smart people and would have had a reason for the caching, which was probably for the larger companies. I don’t know what tests you did to decide that caching was wrong but I can’t see that you did any testing on worst case situations. E.g. Take a European company with 4 European subsidiaries all; on the same time zone so all the staff in the various countries will be working at the same time . There is a real chance that every transaction will be for a different locale so in a thousand transactions you could be creating a thousand locales. So it looks like we might be causing a performance hit on the type of company that really shouldn’t get it. What is the performance gain that you think you are getting by your change?

Finally we must be one of the few development companies that still use the rather buggy but lightweight java locales. This is because about 9 years ago, the first time we hit a dodgy locale I created a utility to allow the changing of any of the different parts of a locale driven by simple parameters. To implement this, when our server starts up, the first thing it does is check if there are any locale patches, instantiates the relevant locale(s) and applies patches. Of course this only works on cached locales.

So this is another feature that we’ve lost.


REGRESSION. Last worked in version 7u80


REPRODUCIBILITY :
This bug can be reproduced often.