JDK-8217707 : JNICALL declaration breaks Splash screen functions
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 11.0.2,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86
  • Submitted: 2019-01-23
  • Updated: 2019-08-21
  • Resolved: 2019-03-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13
11.0.4Fixed 13 b15Fixed
Related Reports
Relates :  
JDK-8201226 - missing JNIEXPORT / JNICALL at some places in function declarations/implementations
Description
A DESCRIPTION OF THE PROBLEM :
The JNICALL (__stdcall) declarations added to the splash screen native source in response to bug #8201226 cause the splash screen function names to be decorated in 32-bit Windows. This way they can't be loaded anymore with GetProcAddress and their simple names (that they still have in 64-bit Windows, because __stdcall is ignored there).

REGRESSION : Last worked in version 8u202

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Call "dumpbin splashscreen.dll /EXPORTS"

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Should show
[...]
         11    0 0001C86A SplashClose
         12    1 0001D863 SplashGetScaledImageName
[...]
etc
ACTUAL -
Shows
[...]
         11    A 0001C868 _SplashClose@0
         12    B 0001D86B _SplashGetScaledImageName@20
[...]
etc

CUSTOMER SUBMITTED WORKAROUND :
Patch the source files, removing the JNICALL declarations in splashscreen_impl.h, splashscreen_impl.c and splashscreen_sys.c before building the JDK.

FREQUENCY : always
Comments
The easiest way to reproduce is to run SwingSet2.jar: java -jar SwingSet2.jar When run with 64 bit JDK 13, it shows the usual splash screen. When run with 32 bit JDK 13, no splash screen is shown; after a while you see the main window.
11-02-2019
[~ihse] Yes, splash screen functionality is broken in 32 bit Windows. Yes, I know Oracle does not support 32 bit platforms. At the same time, the fix is easy, so I'd rather fix it when I have spare time. If anyone else is interested in fixing the issue, I do not mind, of course.
06-02-2019
[~aivanov] I'm not sure I understand you. Is the functionality broken when using the supported Java interface? If so, I agree this is a real bug. Otherwise, it's a usage error. Note that 32-bit Windows is not supported by Oracle for JDK 13, so if this works on 64-bit Windows, then the functionality is working, from my perspective. Other companies might be interested in pursuing 32-bit support for Windows.
06-02-2019
Yes, exactly. The attached test case is misleading. It uses a native program to load splashscreen.dll and to look up SplashInit function. This is not a supported test case. The correct test case is to use Splash Screen feature in Java to demonstrate the exactly same problem: https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html java -splash:<file name> <class name> In the tutorial, the following command line is used: java -splash:images/splash.gif SplashDemo It may need to be updated for the correct location to the image and the class. The latest 32 bit Windows build of JDK 13 does not display the splash screen whereas 64 bit build does. The library splashscreen.dll is not a public interface, and it's possible to change the calling convention of the exported functions so that they can be looked up by their plain name in 32 bit Windows too.
04-02-2019
Additional information from submitter: The easiest way to reproduce is: - set the environment variable _JAVA_SPLASH_SCREEN to the name of some image file - then call the regular "java.exe". 64-bit "java.exe"s from any JDK version will show the image as splash screen. Also "java.exe" from a 32-bit version 8 JDK/JRE will show the image. Splash screen will not show with a 32-bit version 11 executable.
04-02-2019
I don't believe calling functions directly in splashscreen.dll has ever been supported. AFAIK, it's not an external interface, but an internal helper for the JDK itself. If the customer is doing things like this anyway, they'll need to update their code if/when the functions in splashscreen.dll changes.
25-01-2019
This "bug" mentions SplashInit (in the attached test) and SplashClose. But my patch http://hg.openjdk.java.net/jdk/jdk/rev/e0af66d6e968 from 8201226: missing JNIEXPORT / JNICALL at some places in function declarations/implementations did not Change those 2 functions. My patch instead fixed the Windows 32bit build by providing matching function decls+impls. for a couple of functions where this was needed. I do not think there is a guarantee to get the same undecorated functions names when going from jdk8 to 11 (or even 13!). (and I am not sure About Windows 32bit support at all)
25-01-2019
Regression of JDK-8201226
25-01-2019
Additional information from submitter: If I could, I would change the description now and remove the GetProcAddress stuff. I think, it's enough to say that the calling convention of existing functions should not be changed.
24-01-2019
Additional information from the submitter: =============================== The issue is in the result from building the JDK. I'm building the JDK on Windows with bash configure --disable-warnings-as-errors --with-boot-jdk=/path/to/jdk --with-target-bits=32 make Now if you have an existing custom launcher that uses the splash screen functions with LoadLibrary/GetProcAddress and worked with Java 8, it will not work anymore in 32-bit Windows, because it won't be able to get the functions' addresses. Attached is a small project for Visual Studio 2017 that shows an actual address when the JDK_HOME macro points to a Java 8 JRE or a 64-bit Java 11 JDK/JRE, but shows 0000000000000000 when JDK_HOME points to a 32-bit JDK built with the current JDK source. =================================
24-01-2019
According to description, JNICALL (__stdcall) declarations added to the splash screen native source w.r.t fix in JDK-8201226 cause the splash screen function names to be decorated in 32-bit windows. Ref: https://java.se.oracle.com/source/xref/jdk-jdk/open/src/java.desktop/share/native/libsplashscreen/
24-01-2019