-
Bug
-
Resolution: Fixed
-
P3
-
11, 13
-
b24
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8225945 | 14 | Philip Race | P3 | Resolved | Fixed | team |
Whilst testing the fix for https://bugs.openjdk.java.net/browse/JDK-8222819
I happened to notice that in an ssh session, where we default to headless AWT,
that on Mac the splash screen still appeared if one was specified - as it
was in this case by SwingSet2. It appears whether you use a splash from
the command line or referenced in a jar manifest.
To be clear this is not being introduced by the above referenced fix,
the problem is pre-existing.
The problem is that the launcher always invokes a specified splashscreen
unless it sees the exact string "-Djava.awt.headless=true" in the command
line args.
So when we "default" to headless without that setting, it still tries
to show it. But the app then fails because of the headless AWT being
selected by (1) the launcher logic I am removing inJDK-8222819 as
well as similar logic in the java.desktop module.
So the logic inside the splashscreen code (which lives in java.desktop)
should be in sync with what the AWT code does. It can't use what is
there - since it uses Java - and it can't easily be reworked to be shared
in native, it is easier to recreate the isAquaDesktopSession()
function we removing. I would have done this directly as part of fixing
JDK-8222819 but the splashscreen initialisation logic needs some work
and that really has nothing to do with the launcher fix, in java.base,
so I am filing this separate bug.
Things that need doing include making "SplashInit"/DoSplashInit
return something other than void, so that the caller in the launcher
code's ShowSplashScreen() method can decide whether to proceed.
We can also move that call up, so that we don't do a lot of pointless
fiddling around with finding the right scaled image before we know
we need it.
Also I noticed that in the current code it calls DoSplashLoadFile()
and then do this
..
int SplashStreamInitFile(SplashStream * pStream, const char* filename) {
pStream->arg.stdio.f = fopen(filename, "rb");
pStream->read = readFile;
pStream->peek = peekFile;
pStream->close = closeFile;
return pStream->arg.stdio.f != 0;
}
JNIEXPORT int
SplashLoadFile(const char *filename)
{
SplashStream stream;
return SplashStreamInitFile(&stream, filename) &&
SplashLoadStream(&stream);
}
...
SplashLoadStream(SplashStream * stream)
{
int success = 0;
int c;
size_t i;
Splash *splash = SplashGetInstance();
if (splash->isVisible < 0) {
return 0;
}
isVisible == -1 is what will be set on X11 (and likely will in this
bug fix) when we decide we can't show the splash.
This looks to me like it leaks the open stream !
I happened to notice that in an ssh session, where we default to headless AWT,
that on Mac the splash screen still appeared if one was specified - as it
was in this case by SwingSet2. It appears whether you use a splash from
the command line or referenced in a jar manifest.
To be clear this is not being introduced by the above referenced fix,
the problem is pre-existing.
The problem is that the launcher always invokes a specified splashscreen
unless it sees the exact string "-Djava.awt.headless=true" in the command
line args.
So when we "default" to headless without that setting, it still tries
to show it. But the app then fails because of the headless AWT being
selected by (1) the launcher logic I am removing in
well as similar logic in the java.desktop module.
So the logic inside the splashscreen code (which lives in java.desktop)
should be in sync with what the AWT code does. It can't use what is
there - since it uses Java - and it can't easily be reworked to be shared
in native, it is easier to recreate the isAquaDesktopSession()
function we removing. I would have done this directly as part of fixing
and that really has nothing to do with the launcher fix, in java.base,
so I am filing this separate bug.
Things that need doing include making "SplashInit"/DoSplashInit
return something other than void, so that the caller in the launcher
code's ShowSplashScreen() method can decide whether to proceed.
We can also move that call up, so that we don't do a lot of pointless
fiddling around with finding the right scaled image before we know
we need it.
Also I noticed that in the current code it calls DoSplashLoadFile()
and then do this
..
int SplashStreamInitFile(SplashStream * pStream, const char* filename) {
pStream->arg.stdio.f = fopen(filename, "rb");
pStream->read = readFile;
pStream->peek = peekFile;
pStream->close = closeFile;
return pStream->arg.stdio.f != 0;
}
JNIEXPORT int
SplashLoadFile(const char *filename)
{
SplashStream stream;
return SplashStreamInitFile(&stream, filename) &&
SplashLoadStream(&stream);
}
...
SplashLoadStream(SplashStream * stream)
{
int success = 0;
int c;
size_t i;
Splash *splash = SplashGetInstance();
if (splash->isVisible < 0) {
return 0;
}
isVisible == -1 is what will be set on X11 (and likely will in this
bug fix) when we decide we can't show the splash.
This looks to me like it leaks the open stream !
- backported by
-
JDK-8225945 SplashScreen is still shown if defaulting to headless on MacOS
-
- Resolved
-