Develop Reference

lwjgl 3 macOS issue with creating windows

I created some code to work with lwjgl3, and ran into an issue with the macOS bindings since I am working on a mac.
The issue is that I cannot seem to get my program to create any windows. I know this for sure as the program just stops at that point. There are no errors.
The line the code gets stuck on is:
long window = glfwCreateWindow(300, 300, "Hello World!", MemoryUtil.NULL, MemoryUtil.NULL);
Since I am developing on IntelliJ, whenever I disconnect the process, it crashes with :
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: EXC_I386_GPFLT
Exception Note: EXC_CORPSE_NOTIFY
I feel that that is not the issue, as I tried running another code dependant on lwjgl3, and it also got stuck at the part creating the window.
I know that the code is stuck at the part to create the window as I have put print statements every line.
I really hope that this is not a compatibility issue with either macOS Big Sur or the mac book pro 2015 model.
while glfwInit() return true, when I run System.out.println(glGetString(GL_VERSION) );, I get this error Fatal error: Thread[main,5,main]: No context is current or a function that is not available in the current context was called. The JVM will abort execution.
Here is the complete code that I am using for testing:
public static void main(String[] args) throws Exception{
GLFWErrorCallback.createPrint(System.err).set();
// Initialize GLFW. Most GLFW functions will not work before doing this.
if ( !glfwInit() )
throw new IllegalStateException("Unable to initialize GLFW");
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 2);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 0);
// Configure GLFW
glfwDefaultWindowHints(); // optional, the current window hints are already the default
glfwWindowHint(GLFW_VISIBLE, GLFW_FALSE); // the window will stay hidden after creation
glfwWindowHint(GLFW_RESIZABLE, GLFW_TRUE); // the window will be resizable
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
// Should be true for macOS, according to GLFW docs, to get core profile.
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
// According to Apple docs, non-core profiles are limited to version 2.1.
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
// Create the window
long window = glfwCreateWindow(300, 300, "Hello World!", MemoryUtil.NULL, MemoryUtil.NULL);
//glClearColor(1.0f, 0.0f, 0.0f, 0.0f);
System.out.println('0');
glfwDestroyWindow(window);
}
I have googled this multiple times:
cannot seem to find a relevant answer. One person suggested that macOS has a hidden popup that had to be closed for the window to be assigned, but I did everything to disable it (as I could not find it) and still nothing happened. I think the GL_VERSION indicates an issue with how openGL is being bound to Java.
[Edit]
Ensured that the app was running on the main thread by passing in the JVM option -XstartOnFirstThread.
[EDIT2]
After leaving the project for a few hours, I came back and reran it.
I added one extra line on the top:
System.out.println("Hello LWJGL " + Version.getVersion() + "!");
The createWindow(...) function started working, which is weird as I do not know why. It also started working if I removed the line, so if anyone knows what was happening please let me know.
I am leaving the question unanswered as I still do not know the reason for the issue, I just happened to be lucky that it fixed itself.
[EDIT3]
I force rebuilt the entire project on intellij and it stopped working again. Am really confused as to why it was working in between

I had the -XstartOnFirstThread on the gradle.properties. Try set it in the jvmargs of the run configuration you currently have. That fixed it for me

Android not calling first method/skipping first method

I'm using Azure Face API for facial recognition, some of my methods are only running correctly in debug mode:
public void detectFace(MenuItem item){
getPicture();
startFaceRecognition();
}
I first noticed the issue with the code above. The getPicture() method does not seem to run if the second method is called after, though does run if the startFaceRecognition() is called from within getPicture().
public void addFace(MenuItem item){
getPicture();
AddFaceParams params = new AddFaceParams("family", "personIdCode", "", currentPhotoPath);
new AddFaceTask().execute(params);
}
The second piece of code takes a picture and then sends the picture with relevant information to Azure with a HTTP request in an asynchronous task. I believe the issue is the getPicture() method isn't being called unless there's a breakpoint placed inside the method. It works if I step through the method, but not if it is run by itself.
Would this be some form of timing issue?
I am new to Java and Android development.

Java / Swing app fails to transition to fullscreen on OS X

I'm using a JOGL FPSAnimator and Apple's FullScreenUtilies class. I implemented this some time ago, and it worked fine. Here is my code for enabling the native OS X fullscreen capability, similar to other code on SO and around the web:
String className = "com.apple.eawt.FullScreenUtilities";
String methodName = "setWindowCanFullScreen";
try {
Class<?> clazz = Class.forName(className);
Method method = clazz.getMethod(methodName,
new Class<?>[] { Window.class, boolean.class });
method.invoke(null, frame, true);
} catch ...
It also works fine in the context of a simple test program I made in an attempt to isolate the issue. I'm not sure at what point the behaviour changed - I haven't spotted anything incriminating in SVN logs. It's likely that I first implemented the feature on an earlier version of OS X, and have also upgraded JOGL version and MyDoggy which we use for docking since. However, all of these things work with fullscreen in the context of other applications.
When I press the green fullscreen button, the usual OSX fullscreen transition starts (it gets its own desktop space), but the window appears frozen from that point on.
The main AWT Event thread carries on running, and I can see that my GLEventListener.display() method is being regularly called. I've tried adding a return to the beginning of that method to eliminate the impact of my rendering code, this unsurprisingly made no difference.
For testing purposes, I added a FullScreenListener:
FullScreenUtilities.addFullScreenListenerTo(frame, new FullScreenAdapter() {
#Override
public void windowEnteringFullScreen(FullScreenEvent arg0) {
log(">>> Entering fullscreen... <<<");
}
#Override
public void windowEnteredFullScreen(FullScreenEvent arg0) {
log(">>> Entered fullscreen. <<<");
}
});
As anticipated, I get the entering fullscreen event, but not the entered one.
It's a fairly large program, but there should be a fairly small surface of things that are potentially relevant here... unfortunately I haven't managed to trace them down. Happy if anyone has any pointers.

Android Libgdx Fatal signal 11(SIGSEGV) ,code 1, fault addr 0x0

I know this is an error with accessing memory outside the readspace but i have absolutely no idea how to fix this. I'm new to android, so i don't exactly know how to print out a more detailed error list from logcat in eclipse. I've tried everything from disposing literally everything, to calling System.gc to setting all my variables to null. However, whenever i switch screens the fatal signal occurs. I just need someone to tell me what exactly is going on or how i could get more details about the error.

I had the same error, what solved it was to make sure i'm on the UI thread, like this:
Gdx.app.postRunnable(new Runnable() {
#Override
public void run() {
// Your crashing code here
}
});

In my case i received same error when i try to create a new body and attach it's fixture, from beginContact (inside Contact Listener). After i moved outside Contact Listener my body creation everything was ok. Probably some conflict appears in Fixture createFixture (FixtureDef def) because according to manual: Contacts are not created until the next time step.

Can't write to textbox in a Swing application executed from console via ssh

I made a swing application with a JFrame. But when I execute this application from the console with java -jar when I am logged via ssh, I cannot write in any of the textboxes. Everything that I write appears in the console rather than in the textbox. See the image attached to show what happens. How can I solve this? Thank you very much in advance.
The problem http://img833.imageshack.us/img833/8688/screenshotoftheproblem.jpg
Javier

I had this problem also but solved by using ssh -Y (instead of -X). Found on forums that some java applications requires trusted (-Y) ssh to work properly. Hope that help others.

I'm assuming you are dealing with unix like operative systems, even you don't mention it. What version of JVM are you using? Is the same version in your ssh server and client? I had a problem with OS X's JVM, I could not run GUI through ssh from a Linux client, but between same Linux flavour, there were no problems. You might want to add debug output to your ssh command line, through "-v" switch. I would recommend trying a very simple application, a trivial example: just a text box on a JFrame; to rule out any possible layout stack or listener issues.
Could you try these code, and see if you can modify the JTextField
public class SimplestGUI extends JFrame
{
public static void main(String [] args)
{
SimplestGUI window = new SimplestGUI();
window.start();
}
public SimplestGUI()
{
initGUI();
}
private void initGUI()
{
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setSize(150,100);
JTextField textField = new JTextField();
textField.setText("123 probando");
getContentPane().add(textField);
}
public void start()
{
setVisible(true);
}
}
To compile and run use these command (assuming you have a JDK on your PATH):
javac SimplestGUI.java ; java -cp . SimplestGUI
If that works, then you should start adding your components, listener, adapters, etc. one by one, and see which one is causing the text fields not getting the input.
If doesn't work either, then my guess is that you might have a problem with different X Window versions or implementations.
¿Can you share your code to try it on another environment?