Updating Visual Studio for 8u builds after EOL of VS2010 in July

[Volker Simonis]

On Sun, Mar 29, 2020 at 10:45 PM Martijn Verburg
<martijnverburg at gmail.com> wrote:
>
> Hi Volker,
>
> We only ever received one bug report at AdoptOpenJDK on this (someone who had a Netbeans plugin that linked to msvcr100.dll.
>
> The workaround is for a user to install the Microsoft Visual C++ 2010 Service Pack 1 Redistributable Package - https://www.microsoft.com/en-us/download/details.aspx?id=26999
>

Thanks Martijn. Yes, this will help as long as the native library will
not exchange native file handles or free memory allocated by native
code in the jdk. Hopefully, there are not too many such libraries out
there :)

> Cheers,
> Martijn
>
>
> On Thu, 26 Mar 2020 at 18:53, Volker Simonis <volker.simonis at gmail.com> wrote:
>>
>> On Thu, Mar 26, 2020 at 12:36 PM Martijn Verburg
>> <martijnverburg at gmail.com> wrote:
>> >
>> > Hi Dave,
>> >
>> > We build with 2013 at Adopt - feel free to use the details in the scripts (
>> > https://github.com/AdoptOpenJDK/openjdk-build/blob/master/build-farm/platform-specific-configurations/windows.sh)
>> > :-).
>> >
>> > Cheers,
>> > Martijn
>> >
>>
>> Hi Martijn,
>>
>> thanks for answering to this request. The question was not so much
>> about how to use VS 2013, we've managed to do that :)
>>
>> The bigger concern is compatibility. Before moving to VS2013 we (and
>> other distributors) have built against and shipped msvcr100.dll as
>> part of their JDK. This means that JNI libraries usually also were
>> built against the same msvcr version. Now, when moving to VS 2013 we
>> will build against and ship msvcr130.dll. So two problems can arise:
>>
>> - JNI libraries still depended on using msvcr100.dll from the JDK and
>> won't start any more because they cant find it.
>>
>> - JNI libraries bring their own version of msvcr100.dll and will run,
>> but now we can get intricate problems whenever the JNI library
>> exchanges handles with JDK code or dynamic memory allocation/freeing
>> is passing the JDK / JNI library border.
>>
>> What are your takes on these kind of problems? Have you encountered
>> them when you were switching from VS 2010 to 2013 and if yes, how did
>> you cope with them?
>>
>> Thank you and best regards,
>> Volker
>>
>> >
>> > On Tue, 17 Mar 2020 at 17:01, Currie, Dave <currdavi at amazon.com> wrote:
>> >
>> > > Hi.
>> > >
>> > > As you may know, Visual Studio 2010, the current toolchain for building
>> > > OpenJDK 8 on Windows, will go EOL on July 14th, 2020 [1]. Most Windows
>> > > builds of OpenJDK 8 package msvcr100.dll, the C++ runtime DLL. At Amazon,
>> > > we have heard feedback that shipping this DLL is going to start raising
>> > > issues with compliance processes that require all libraries to be
>> > > up-to-date and supported.
>> > >
>> > > We have been testing Amazon Corretto built with Visual Studio 2013, an
>> > > updated toolchain. The changes to the build are simple but it does not work
>> > > out-of-the-box and there are caveats/jtreg failures that need to be
>> > > resolved. The biggest problem we have seen so far is that users who are
>> > > running native libraries via JNI may be inadvertently using the
>> > > msvcr100.dll that is loaded by the JVM and, when this is replaced, their
>> > > app will fail. There are simple workarounds (e.g. install [2]) but it will
>> > > not be drop-in compatible for this case.
>> > >
>> > > Is anyone else seeing similar feedback? Is anyone else considering a move
>> > > to VS13 (or later) for OpenJDK 8 updates and have you seen blockers in this
>> > > process?
>> > >
>> > > Dave Currie
>> > >
>> > > [1]
>> > > https://support.microsoft.com/en-us/lifecycle/search?alpha=Visual%20Studio%202010%20(all%20editions)
>> > > [2] https://www.microsoft.com/en-us/download/details.aspx?id=21576
>> > >
>> > >