Develop Reference

JCEF (Java Chromium Embedded Framework) Browser does not load content; only blank screen on Eclipse

I have been trying to get the Java version of Chromium Embedded Framework (JCEF) to work on Eclipse for some time. I am able to verify that the library files are working correctly, since if I run the included sample class files on the VM, the program runs and some webpage is displayed. However, if I run the program from Eclipse, the program will always display a blank window. I am able to verify that the library binary jcef_helper.exe is successfully run, but not matter how I link the .jar files and other library files, the webpage will not generate and there will always be a blank screen. I cannot pinpoint the issue here. I tried specifying path, adding the JCEF library path of my OS environment variables PATH field to no avail. I have followed the documentation, even sample files behave the same way when I have anything to do with compilation/ run. One note of interest, my Eclipse console will display this during run:
initialize on Thread[AWT-EventQueue-0,6,main]
Perhaps there is a thread issue?
Code in question:
import java.awt.Component;
import java.awt.Dimension;
import java.awt.Toolkit;
import javax.swing.JFrame;
import javax.swing.WindowConstants;
import org.cef.CefApp;
import org.cef.CefApp.CefAppState;
import org.cef.CefClient;
import org.cef.CefSettings;
import org.cef.browser.CefBrowser;
import org.cef.handler.CefAppHandlerAdapter;
public class WebV
{
public static void main(String args[])
{
Dimension dispDimension = Toolkit.getDefaultToolkit().getScreenSize();
int width = (int)Math.round(dispDimension.getWidth() / 2);
int height = (int)Math.round(dispDimension.getHeight() / 2);
CefApp.addAppHandler(new CefAppHandlerAdapter(null)
{
#Override
public void stateHasChanged(CefAppState state)
{
if(state == CefAppState.TERMINATED)
{
System.exit(0);
}
}
});
CefSettings settings = new CefSettings();
settings.windowless_rendering_enabled = false;
CefApp cefApp = CefApp.getInstance(settings);
CefClient client = cefApp.createClient();
CefBrowser browser = client.createBrowser("http://www.google.com", false, false);
Component browserComponent = browser.getUIComponent();
JFrame frame = new JFrame();
frame.setTitle("WebV");
frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
frame.setSize(width, height);
frame.setResizable(true);
frame.setLocationRelativeTo(null);
frame.add(browserComponent);
frame.setVisible(true);
}
}
Tested with both Java 17 and Java 8.
Run on Eclipse, with VM args:
-Djava.library.path=./bin/lib/win64
Any inupt would be greatly appreicated.

This answer was kindly provided by 'Yanovsky' at the JCEF forums.
The simple example provided by the JCEF package is incomplete.
We need to add a CefMessageRouter instance to our browser client. This is demonstrated in the detailed examples, but not the simple one. This code should be added before we create our CefBrowser instance and after we have created a CefClient object:
CefMessageRouter msgRouter = CefMessageRouter.create();
msgRouter.addHandler(new MessageRouterHandler(), true);
msgRouter.addHandler(new MessageRouterHandlerEx(client), false);
client.addMessageRouter(msgRouter);
For reference, this is my post in the JCEF forum:
https://magpcss.org/ceforum/viewtopic.php?f=17&t=18834&sid=45381db639d1621f2f8b38b4d8848800

I just copied and pasted your code in eclipse and added the jars and ran the code and voila, google.com opened without any issues.
I didnt have to add any more new lines as suggested by mindoverflow.
The webpage was visible in the window after a few secs and not immediately.
Here's what popped up after running the code.
And in the eclipse console, I see this
initialize on Thread[AWT-EventQueue-0,6,main] with library path C:\path\to\dlls

Java crashes when creating a JFrame

I am baffled at this issue. I just wanted to create a JFrame for testing, this is the only class:
import javax.swing.*;
public class TextPaneTest extends JFrame {
public TextPaneTest(){
setTitle("Test");
setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
setLocationRelativeTo(null);
setSize(200, 200);
setVisible(true);
}
public static void main(String[] args){
new TextPaneTest();
}
}
I am using IntelliJ IDEA 2019.2.4 as my IDE.
The result is a small white JFrame opens up for 2 seconds and closes. You can't move or resize the window and the cursor remains in "wait" mode when you hover the frame.
This is my project structure:
And this is my run configuration:
There is no error message or exception. All the console shows is:
Process finished with exit code -1073740771 (0xC000041D)
I've already done a clean reinstall of both the JRE and JDK
This is my current java -version:
java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
My OS is Windows 10 Home Single Language 1903
I don't know what else to add. I've been using Java for the past 5 years as a hobbyist and I've never came across an issue so fundamental as this.
Update
Tried instantiating TextPaneTest() using SwingUtilities.invokeLater()
Tried building the JAR and running from a command window
None has worked so far. Exactly the same behaviour.
Update 2
Fixed it by switching the 64 bit JRE for the 32 one. Is this a bug with the 64 one or could there be an underlying problem?

I cannot reproduce the issue on my macintosh, but I notice you are doing everything on the main thread. You shouldn't do that. Make sure all events happen on the Event Dispatch Thread. For example,
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
new TextPaneTest();
}
});
}

JavaFX native packaging - bizarre error with initialising static variables

I'm working on a JavaFX project in Netbeans that's currently around 3000 lines long, and I've packaged as an .exe regularly for testing but never come across an issue like this curious incident.
When packaging natively as a Windows .exe file, I found that after installing the .exe and launching my program I was getting a popup saying "Class {mypackage}/{mymainclass} not found." followed by "Failed to launch JVM."
Launching the program in Netbeans, packaging as an .exe, and launching the .jar in Powershell with "java -jar {app}.jar" all gave absolutely no errors. Even the .jar inside the installed application folder was fine, with no errors on the command line.
After a few hours of trawling through git commits and packaging natively, I managed to trace the issue down to a single line of code:
private static ComboBox choices = new ComboBox();
When I initialise the ComboBox in an initialiser, the program magically works after being installed from an .exe:
private static ComboBox choices;
{
choices = new ComboBox();
}
However, when I use a static initialiser (by placing static in front of the first curly brace), even though Netbeans states "initialiser can be static", I get the same error as before.
This is puzzling, because Java is obviously fine with the code itself, but after it's been through the native packager it will not launch. I've used plenty of similar lines of code to initialise static variables in other classes, with no ill effects.
I tried adding a similar line to the main class: private static CheckBox chkbox = new CheckBox();
It caused the exact same error after the .exe was installed (as before, the .jar was fine), but when I cut-and-pasted the line to a different class, it had no effect.
Interestingly, my main class already has a static boolean that is initialised in the same way that the ComboBox and CheckBox were: private static boolean someBool = true; but the boolean causes no problems.
Can anyone explain the reason behind this? Thank you.
Edit: I also tried packaging on a different machine, but it stopped working after the same git commit.
I'm using version 1.8.0_144 of the JDK and JRE.
Edit 2: here is the main class of a simple example that produces the error.
package testproject;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.CheckBox;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;
public class MainApplication extends Application {
private static CheckBox testCheckBox = new CheckBox(); // Causes error after launching from installed .exe
/* UNCOMMENT THIS SECTION AND REMOVE THE " = new CheckBox()" ABOVE TO FIX THE ERROR
{
testCheckBox = new CheckBox();
}
*/
#Override
public void start(Stage primaryStage) {
StackPane root = new StackPane();
Scene scene = new Scene(root, 300, 250);
primaryStage.setTitle("Empty window");
primaryStage.setScene(scene);
primaryStage.show();
}
public static void main(String[] args) {
launch(args);
}
}

I would avoid creating JavaFX widgets in static initializers (such as a static field or static block), as this would create them when class is loaded, which might happen in any thread. You want that to happen in JavaFX Application Thread.
In your case it happens in main thread, which is definitely not correct.
Check this answer for more details about JavaFX application startup, and how threads are involved in the process.
Trying to initialize a JavaFX widget outside of "JavaFX Application Thread" is (to my understanding) undefined behavior, and might fail in many different ways (or succeed by luck). If that creation fails, then the class loading fails (because static init has failed), hence "class not found". Unfortunately, since this happens while loading main class, you don't get to see the initial error, just "class XXX not found".
Possibly in your case, the java launcher can deal with this initialization just fine, but the launcher used by your .exe is different. I'm not too surprised it fails. I'm equally surprised it works with regular java :)

Look & Feel troubles on Ubuntu

I'm writing an app that requires some widgets to use different look & feels. The rest of the app uses the system look & feel.
My approach to this was while initializing the app to swap the LF for the desired one, create the component and then reset the LF. This worked fine on Windows operating systems, but while testing it on Ubuntu it failed to set the LF for the component in a bizarre way.
On Ubuntu, UIManager.getSystemLookAndFeelClassName() reports that that the LF is a javax.swing.plaf.metal.MetalLookAndFeel. This is the first bit of trouble - I'd expect it to return com.sun.java.swing.plaf.gtk.GTKLookAndFeel. The strange part is that my approach works when the program is using the Metal LF, but fails when using the GTK LF, where it sets the entire frame and all components within it to the GTK LF.
The following SSCCE demonstrates the issue:
import javax.swing.*;
import java.awt.*;
import static javax.swing.UIManager.*;
public class LaFTest {
public static void main(String[] argv) throws ReflectiveOperationException, UnsupportedLookAndFeelException {
String[] keys = {
"java.specification.version",
"java.version",
"java.vm.version",
"java.specification.vendor",
};
for (String key : keys) {
System.out.printf("%-40s%s\n", key, System.getProperty(key));
}
System.out.println(UIManager.getSystemLookAndFeelClassName());
// Swap for "com.sun.java.swing.plaf.gtk.GTKLookAndFeel"
setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
JFrame frame = new JFrame("LaF Test");
Container content = frame.getContentPane();
content.setLayout(new GridLayout(2, 0));
JButton button = new JButton("System");
content.add(button);
LookAndFeel previous = getLookAndFeel();
for (LookAndFeelInfo feel : getInstalledLookAndFeels()) {
if (feel.getName().equals("Nimbus")) {
setLookAndFeel(feel.getClassName());
}
}
JButton second = new JButton("Nimbus");
content.add(second);
setLookAndFeel(previous);
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
}
Note, however, that I am unsure regarding the reproducibility of this issue. As quick Google shows no similar issues, it may be something specific to my machine. Regardless, it has persisted when updating from Ubuntu 12 to 13, and 13 to 14. From this I assume it's an issue with Swing and not the underlying system.
The output of the above program is, on my machine,
java.specification.version 1.7
java.version 1.7.0_51
java.vm.version 24.51-b03
java.specification.vendor Oracle Corporation
javax.swing.plaf.metal.MetalLookAndFeel
Using the Metal feel, the resulting window is
Swapping for the GTK feel,
I've been playing around with this for a while now, with no results. Is there something I'm missing? Can anyone reproduce this, and if so is it a bug in the Java distribution or my code? Is there a better way to achieve my goal?

I would have loved to debug this in depth, but a nearing deadline forced me to install the Oracle Java package, which fixed the issue. A disappointing answer, but it did fix the issue permanently.

Swing on OSX: How to Trap command-Q?

After being convinced ("schooled") that Swing apps on Mac do look native, I'm trying to make mine look as native as possible. Everything looks great, but when I hit command+Q or do it from the menu, my windowStateChanged(WindowEvent e) is not firing on my main JFrame (if I exit in any other way, it does fire). How can I respond to the real Apple quit?

You can implement com.apple.eawt.ApplicationListener and respond to the Quit event. An example may be found in the Mac OS X Reference Library example, OSXAdapter.
Addendum: See Java for Mac OS X 10.6 Update 3 and 10.5 Update 8 Release Notes for information on deprecation, the redesigned com.apple.eawt.Application class, and the location of API documentation for the Apple Java extensions. Control-click or right-click on the .jdk file to Show Package Contents. You can browse the classes of com.apple.eawt among the OpenJDK sources.
As shown in this complete example, you can specify the desired
QuitStrategy; a WindowListener will respond to ⌘Q:
Application.getApplication().setQuitStrategy(QuitStrategy.CLOSE_ALL_WINDOWS);
As noted here, you can set the property from the command line
java -Dapple.eawt.quitStrategy=CLOSE_ALL_WINDOWS -cp build/classes gui.QuitStrategyTest
or early in the program, before posting any GUI events:
System.setProperty("apple.eawt.quitStrategy", "CLOSE_ALL_WINDOWS");
EventQueue.invokeLater(new QuitStrategyTest()::display);
Console, after ⌘Q:
java.vendor: Oracle Corporation
java.version: 1.8.0_60
os.name: Mac OS X
os.version: 10.11
apple.eawt.quitStrategy: CLOSE_ALL_WINDOWS
java.awt.event.WindowEvent[WINDOW_CLOSING,opposite=null,oldState=0,newState=0] on frame0
Code:
package gui;
import java.awt.EventQueue;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JFrame;
import javax.swing.JTextArea;
/**
* #see https://stackoverflow.com/a/7457102/230513
*/
public class QuitStrategyTest {
private void display() {
JFrame f = new JFrame("QuitStrategyTest");
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
f.addWindowListener(new WindowAdapter() {
#Override
public void windowClosing(WindowEvent e) {
System.out.println(e);
}
});
f.add(new JTextArea(getInfo()));
f.pack();
f.setLocationRelativeTo(null);
f.setVisible(true);
}
private String getInfo() {
String[] props = {
"java.vendor",
"java.version",
"os.name",
"os.version",
"apple.eawt.quitStrategy"
};
StringBuilder sb = new StringBuilder();
for (String prop : props) {
sb.append(prop);
sb.append(": ");
sb.append(System.getProperty(prop));
sb.append(System.getProperty("line.separator"));
}
System.out.print(sb);
return sb.toString();
}
public static void main(String[] args) {
System.setProperty("apple.eawt.quitStrategy", "CLOSE_ALL_WINDOWS");
EventQueue.invokeLater(new QuitStrategyTest()::display);
}
}

The top voted answer is excellent but just to fill in the "best way":
System.setProperty("apple.eawt.quitStrategy", "CLOSE_ALL_WINDOWS");
This will trigger the standard window closing callback event which should work really nicely for portable code.
As a result of the discussion below it seems that its crucial to do this really early in the app. I wrote this early in the static initializer of the main class before any UI code was executed.

This is a pretty good question, and I must admit I don't have the answer. However, a couple years ago when I was working on a Java app and faced this problem, I solved it by registering a shutdown hook with the runtime that would do what I wanted the app to do before quitting. It's a heavy-handed solution but it worked. You can take a look at my code and see if it helps.

I was originally seeing a 'access restriction' violation when trying to access the com.apple.eawt.Application and com.apple.eawt.* subclasses.
(Note: I'm programming on a MAC, using Eclipse, with Java 1.6 using Swing)
So I needed to modify my java build path to allow access to the apple subclasses by adding "com/apple/eawt/**" access rule. After that this code below was able to compile and work for me:
//NOTE: This code only works for MAC OS. If you run this on Windows
//the application never starts (so you literally need to remove this block of code)
import com.apple.eawt.*;
import com.apple.eawt.QuitHandler;
Application a = Application.getApplication();
a.setQuitHandler(new QuitHandler() {
#Override
public void handleQuitRequestWith(com.apple.eawt.AppEvent.QuitEvent qe, com.apple.eawt.QuitResponse qr) {
// TODO Auto-generated method stub
int res = JOptionPane.showConfirmDialog(frame, "Are you sure you want to exit the program?", "Quit ?", JOptionPane.YES_NO_OPTION, JOptionPane.QUESTION_MESSAGE);
if (res == JOptionPane.YES_OPTION)
qr.performQuit();
else
qr.cancelQuit();
}
});

Have you tried setting up command-Q as an accelerator in your menu? Can you make your app respond to it?
I'm not positive, but I think this works in Linux and probably Windows with the equivalent Alt-F4. My app responds to the "killing" keystroke, I process some cleanup code and then I do a programmatic System.exit().
If you're "just" after graceful exit handling, you may also want to catch the WindowEvent WINDOW_CLOSING, where traditionally "are you sure?" stuff gets done.

Looking at the link to Java for Mac OS X 10.6 Update 3 and 10.5 Update 8 Release Notes I noticed that there is a section on Default Quit Action. This describes a system property to request that all windows are closed in response to the "Quit" menu item, which sounds like exactly what is needed? I have used this in my own application (using Info.plist to set the property on OS X only), and it seems to work as described. This would presumably only work on recent Java/OS X versions, but for those platforms seems like a neat solution, and doesn't require any code changes.