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

[Langer, Christoph]

Hi,

I think exchanging file handles or pointers to malloced memory is not so likely to happen, at least not between an external library and the JVM. Usually these things are not exposed by the VM. But can be weird things in the wild, of course.

One notable point is the vfprintf hook where hotspot and a custom launcher can exchange file handles. If somebody uses this facility and runtimes differ, the program is likely to crash or expose weird errors. We know that case ��

Best regards
Christoph


> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Volker Simonis
> Sent: Montag, 30. März 2020 11:13
> To: Martijn Verburg <martijnverburg at gmail.com>
> Cc: jdk8u-dev at openjdk.java.net
> Subject: Re: Updating Visual Studio for 8u builds after EOL of VS2010 in July
> 
> 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
> >> > >
> >> > >