Created attachment 148867 [details]
message during first start after deleting user profile

we have preconfigured java runtime for all users with a "javasettings_Windows_X86_64.xml" in "C:\Program Files\LibreOffice\share\config". at first start (e.g. after deleting a user profile) lo creates a new user profile including an empty "user" "javasettings_Windows_X86_64.xml":

<?xml version="1.0" encoding="UTF-8"?>
<!--This is a generated file. Do not alter this file!-->
<java xmlns="http://openoffice.org/2004/java/framework/1.0" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <enabled xsi:nil="true"></enabled>
 <userClassPath xsi:nil="true"></userClassPath>
 <vmParameters xsi:nil="true"></vmParameters>
 <jreLocations xsi:nil="true"></jreLocations>
 <javaInfo xsi:nil="true"></javaInfo>
</java>

starting with lo 6.1.5 we noticed, that lo complains during first start:
"The configuration has been changed" (please see attached picture).

till now we used a "javasettings_Windows_X86_64.xml" with "vendorUpdate="2013-05-02".
and this seems to be the problem now. 
creating a new "javasettings_Windows_X86_64.xml with JRE 1.8.0_202 changes
the date to "vendorUpdate="2019-01-19". this will work with lo 6.1.5.2, but
not with LO 6.1.4.2 and LO 6.2.0.3. the latter two (network installations on
my test system) still need "vendorUpdate="2013-05-02".

steps to reproduce:
- LO 6.1.5.2 is installed in "C:\Program Files\LibreOffice" 
  (with system integration)
- Java JRE x64 is installed in "C:\Program Files\Java\jre1.8.0_202".
  (btw: a JDK 11.0.2 is installed on my test system too)
- attached java extensions is installed in 
  "C:\Program Files\LibreOffice\share\uno_packages":
  unopkg add broadcastcomp.uno.zip --shared --verbose
  btw: it seems to be neccessary to use a java extension which will be
       initialized during lo start.
- make sure lo is not running
- copy attached "javasettings_Windows_X86_64.xml" into 
  "C:\Program Files\LibreOffice\share\config"
- delete lo user profile
- start lo 
- this should work, cause vendorUpdate is "2019-01-19".

but it will fail if you change the vendorUpdate to "2013-05-02" or 
try the same with LO 6.1.4.2/LO 6.2.0.3.