I have just started working with JavaFX and have come to an obstacle. When I open SceneBuilder it renders very strangely. When the window is restored it seems zoomed in, and when maximized it looks better, but still not quite OK and inoperable.
The same goes for HelloWorld example that I created, and examples I found on internet, so I think it is something systemic. I have tried with Java 7u71 and with Java 8u25. No change. Please help if you know how to fix this.
After reading system requirements (http://www.oracle.com/technetwork/java/javafx/downloads/supportedconfigurations-1506746.html) I came across this line:
To avoid rendering issues on Windows platforms, upgrade the ATI driver to Catalyst 11.09 or later.
If you have a old laptop like I do (with ATI FireGL V5200 and ATI driver 8.561.0.0), try to disable HWA. I did this by setting JAVA_TOOL_OPTIONS in Windows Environment variables. See answer: How to disable or bypass Hardware Graphics Acceleration(Prism) in JavaFX
For Java 7: JAVA_TOOL_OPTIONS=-Dprism.order=j2d
For Java 8: JAVA_TOOL_OPTIONS=-Dprism.order=sw
Related
I've been setting up a 2018 MacBook Pro for Java development. It's running Mojave 10.14.1 - just like the older machine I'm migrating from, an early 2013 MacBook Pro. I installed Java 1.8.0_192 and immediately noticed that I could not launch jars or any Java app that had a UI on this mac. I uninstalled and tried each of these: 1.8.0_172, 1.8.0_191, 1.8.0_192, and 11.0.1. I traced the issue further and found a common error:
Caused by: java.lang.NullPointerException
at java.awt.Window.init(Window.java:497)
at java.awt.Window.<init>(Window.java:537)
at java.awt.Frame.<init>(Frame.java:420)
at java.awt.Frame.<init>(Frame.java:385)
at javax.swing.SwingUtilities$SharedOwnerFrame.<init>(SwingUtilities.java:1763)
at javax.swing.SwingUtilities.getSharedOwnerFrame(SwingUtilities.java:1838)
at javax.swing.JWindow.<init>(JWindow.java:187)
at javax.swing.JWindow.<init>(JWindow.java:139)
Curious, I launched our Swing-based product and it reported the same error. I googled and found only unanswered posts.
(revising this to be formatted as a question and not a blog post)
What gives?
I had the same issue and I found it reported here.
In my case, I was using a docking station for my MacBook Pro and DisplayLink Driver for extended display. This made Jmeter crash.
The workaround was to disconnect my laptop from its docking station and launching the application.
The solution to this problem was simple, but not immediately obvious.
I dug into the JVM and found that the native code wasn't able to identify a compatible graphics mode from the OS. This results in a null GraphicsConfiguration. That's not good - it causes a NullPointerException in Window.java...guess what line. (Line 497)
I suspected the OS wasn't returning the right information about its graphics setup and then started to suspect the graphics driver. That's when I remembered Macs have parameter RAM (PRAM) and non-volatile RAM (NVRAM).
I zapped the PRAM and NVRAM and now the machine is working fine!
To zap the PRAM and NVRAM:
shut down your mac
restart while holding option+command+P+R
keep holding these until the mac appears to reboot again (the apple logo
will appear, disappear, and reappear)
If your mac starts up without the disappearing mac logo, shut it down and retry.
Reset NVRAM or PRAM on your Mac
I hope resetting the PRAM helps others!
We have the same issue when trying to open an inhouse Java-based application in conjunction with Dell D6000 docks using DisplayLink software.
As others have suggested disconnecting the Dock then launching the application works after which you can reconnect the dock and move the application to the other screen.
The other way we have managed to get it to work is with the laptop open making the laptop screen the main display this is done in the system prefs in the display settings and moving the white bar to the laptop screen then opening the application.
I think it has been said before when the main display is one run through DisplayLink it can't detect the display so return a null value, even running most recent drivers (24th Aug 2020) this is still the case.
So its workarounds not solutions if you are in the same boat
My Java SE (8u111) just won't work. I can't open java programs. Not even the Java Control Panel. I have reinstalled 5 times over, and java just won't work. Everytime i try to open Java (The CP or Program) it appears in Taskmgr, does some work (CPU and Disk rate is picking up), then the rates goes back to 0 (except memory), and Java closes itself without any error notices.
The first time i installed Java, it worked without compatibility mode.
Now, it doesn't.
The only things i did before it breaks are:
I updated Intel HAXM
I turned on Intel VT
I ran Remix OS Player
Java breaks.
After it breaks, i did these to solve:
Uninstall Intel HAXM
Disabled Intel VT
Reinstalled Java 5 times over, one in a different drive
Still doesn't work.
If i apply compatibility mode set to Windows 98 / Windows Me or older, it works. But if i set it to Windows XP or newer, it will not work. Do anybody know why?
I run Java SE 8u111 (on first install, never updated), on Windows 10 version 1607
Intel Core i5-7200U, Nvidia Geforce 920MX, all running on a new 2 week old laptop.
One more thing, i doubt this'll help but, I use custom DPI Scaling (145%)
Test by launching from the console. it's as simple as typing java -jar path-to-your-jarfile into the terminal (can be opened with "win+r" and typing "cmd"). That might at least give you an idea what is the actual problem. --Paul
Thank you Paul for suggesting! After i run my java programs from the console, i found that all of the programs' crashes was caused by java.lang.IllegalArgumentException: 33 incompatible with Text-specific LCD contrast key.
I did a quick google search and read https://www.rarst.net/software/cleartype-install4j-java-bug/.
Then i remembered that, i have modified the registries of cleartype before java breaks. So i re-calibrated the cleartype settings through Windows Control Panel, and now... Everything works! All of the java programs, Java Control Panel, and java on the web is now working!
I might have figured out why the compatibility mode only works on Windows 98 or older. My cleartype parameters was invalid and java could not process the cleartype. Cleartype was implemented on Windows XP (i think). With compat. mode telling Java that this machine is Windows 98, Java would not start collecting configs and information on cleartype and/or load cleartype, making it not crash.
My problem is solved! Thank you!
I'm developing a desktop application for Mac. When I run the application using Java6 it works fine, but when I run it using Java7, the application window seems to be limited to a width 1024 pixels (i.e. when it starts the window is 1024px wide, and can't be expanded/dragged to make it wider). I've tried all sorts of ways to adjust the size (setting window state to maximized, explicitly setting the width, etc.). I've also tried changing where I set the Window size, but so far no luck.
I have tried searching for anyone who has had similar problems, but have not had much luck. The only real hit I got was from an OTN discussion forum: https://community.oracle.com/thread/2617106, but there is no resolution and the discussion seems to be archived so I can't reply to it.
If anyone out there has come across this issue, I'd love to hear about it.
Environment:
Operating System: Mac OS X 10.7.5
Java Version: 1.7.0_55 (Oracle Corporation)
New Information:
Have found a related bug report in OpenJDK: https://bugs.openjdk.java.net/browse/JDK-8046008?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel
This seems to indicate that it is a problem for Mac OS X 10.7.5, which I am using.
I'm having a strange bug wich i suspect to be specific to either MacOS X Lion and/or Java VM implementation on this OS.
When a java app summons a secondary window like a dialog box, i'm often unable to interact with its content ie. click, use menus, etc.
At first i though my app was buggy but since i had developped it on windows (where it worked fine) and switched to mac. I though some weird swing setting was to blame and i had noticed on the console that a compatibility mode with cocoa was enabled when i launched my app.
But i encountered the same bug with eclipse itself (a well known java based ide) tough it does not always happen in it while it's all the time with my app.
I have browsed for this issue but found nothing. Meanwhile i found that there is an issue between oracle and apple about java. I downladed a java update specific to Lion but the bug is still here
My question is : have you encountered the same bug ? is it macos lion specific ? have you found a workaround ??
Thanks
Made some research. Eclipse seems to be the cause of the bug. More precisely SWT support in eclipse under MacOS environnement.
The bug is not present with netbeans.
I would appreciate any help with this problem, I have spent hours trying to diagnose it myself to no avail and haven't received a single response when posting it to the Netbeans user list and the bugs list.
Netbeans is an excellent IDE, and I have loved it since switching over from Eclipse a few months back. I do Java on Unix and Win32, and PHP on both, plus C on Linux (using Visual Studio on Windows as well). The problem is that I am far too accustomed to using the scroll wheel while coding now, and it doesn't work with Netbeans.
I am running Netbeans 6.5 on Vista (sp1) with a Microsoft Wireless Laser Mouse 6000. The scroll wheel refuses to work in any window, and mouse gestures on my laptop track pad also don't work (less important). My platform details are:
Software:
Vista Sp1
Product Version: NetBeans IDE 6.5 (Build 200811100001)
Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05
System: Windows Vista version 6.0 running on x86; Cp1252; en_AU (nb)
Hardware:
Mouse: Microsoft Wireless Lasermouse 6000
Driver First Attempt:
Mouse Driver: HID-compliant mouse
Driver provider: Microsoft
Date: 21/06/2006
Driver Version: 6.0.6001.18000
Driver Second Attempt:
Mouse Driver: Microsoft Wireless USB Mouse
Driver provider: Microsoft
Date: 26/11/2008
Driver Version: 6.31.230.0
I found a very old bug report that said the problem was because Microsoft started enabling smooth scrolling by default, meaning the Input API would spit out smaller scroll values - but no matter how much I spin the wheel the document doesn't move.
I also tried rolling the driver back, re-installing and newest drivers etc. Would appreciate any pointers on this problem, I am sure other people are also experiencing it as I have found a lot of references to the same problem online, but without solutions.
I tried another Logitech mouse that I have (MX5000) and it's scrollwheel also doesn't work. I assigned page up and page down shortcuts to two of the extra mouse buttons, but it just isn't the same. Please please can somebody who is using Netbeans on Vista help me out with this, its killing me!
The funny thing is, this mouse and scroll wheel work fine with Netbeans on Linux..
All I can do is partially confirm what you have reported.
I am running a Microsoft Intellimouse -- a Wireless Optical Mouse 2.0 on my Vista Ultimate laptop. I can confirm that the mouse wheel works correctly in every applicable application I've tried it with -- with the exception of Netbeans 6.5. I also have a Logitech optical wireless 4 button mouse w/mouse wheel, I'm not sure the model number. It is on my OpenSUSE 11.1 Linux laptop. I can confirm that the mouse wheel works correctly with every applicable application I've tried it with -- including Netbeans 6.5. When I switch the Logitech mouse to the Vista box, everything works -- including Netbeans 6.5. When I switch the Microsoft mouse to the Linux box, everything works -- including Netbeans 6.5. When I switch them back, the old behavior is maintained -- the Microsoft mouse wheel does not work with Netbeans 6.5 on Vista, all other combinations seem to work fine.
Are you this a Netbeans problem? Have you tried using your scroll wheel in any other Java applications?
I ask because there was a bug in Java related to scroll wheels for some mice not working. This is now fixed.
It may be worth updating the JVM you use to run Netbeans since the problems you are seeing might be caused by this bug which is now fixed.