I am using the javaFX 2.2 with jdk1.6 in a swing environment. I am trying to display a browser on the JPanel and i am successfully able to do this.
THe only problem i see is when i run my application on any other machine which doesn't have the javaFX2.2 runtime env it gets stuck and doesn't display any error message.
How can I make sure that if the javafx runtime env. is available on the machine or not before doing
new JFXPanel()
because code stuck at the above line.
boolean isJavaFxAvailable;
try {
Class jfxPanel = classLoader.loadClass("javafx.embed.swing.JFXPanel");
isJavaFxAvailable = true;
} catch (ClassNotFoundException e) {
isJavaFxAvailable = false;
}
There needs to be a JavaFX runtime at every maschine which runs a JavaFX application. I beleave this runime may be delivered by a webstart, but it must accessable.
Take a look here:
How to get the version number of JavaFX?
Related
I'm writing an IntelliJ plugin, and attempting to integrate JxBrowser into the plugin's tool window via Java Swing.
I'm using the toolWindow extension to keep the tool window integration simple.
plugin.xml
<extensions defaultExtensionNs="com.intellij">
<toolWindow id="pluginid" anchor="right" factoryClass="com.solutionloft.codeclippy.MainWindowFactory" />
</extensions>
And so my main factory class looks like this:
public class MainWindowFactory implements ToolWindowFactory {
#Override
public void createToolWindowContent(#NotNull Project project, #NotNull ToolWindow toolWindow) {
Browser browser = new Browser();
BrowserView view = new BrowserView(browser);
Content content = toolWindow.getContentManager().getFactory().createContent(view, "", false);
toolWindow.getContentManager().addContent(content);
browser.loadHTML("<html><body><h1>Hello World!</h1></body></html>");
}
}
This appears to work when I run the plugin locally initially (the tool window comes up, and I can see Hello World), but if I terminate the process and then try to run it again, I run into this error:
Received signal 10 BUS_ADRERR 000103bc3000
[0x00017cd9540c]
[0x00017cd95301]
[0x7fff572eef5a]
[0x7fbe7e9f5000]
[end of stack trace]
Process finished with exit code 138 (interrupted by signal 10: SIGBUS)
Am I missing some kind of cleanup step? I'm not sure what could still be running - the only workaround I've found at this point is to do a full computer restart, so I guess some process must be still running that's causing it to conflict. What's the proper way to clean up? Does it have anything to do with browser.dispose()? I haven't had much luck finding documentation on when .dispose() would be appropriate / if it's needed.
I'm using:
* macOS High Sierra
* Java 1.8.0_151 as my JDK
* PyCharm Ultimate as my JRE
Thanks!
Update: Noticed if I kill this process /System/Library/Frameworks/LocalAuthentication.framework/Support/coreauthd, the problem goes away for the next few runs. But sometimes this process doesn't exist and killing a still-running java process is the fix... odd.
According to TeamDev support, the solution is to set the system property jxbrowser.ipc.external=true. Calling System.setProperty("jxbrowser.ipc.external", "true") before you create your browser instance should do the trick. The catch is that the JxBrowser will run in lightweight mode.
You may also ensure that you're properly disposing all browser instances via browser.dispose() and the Chromium engine via BrowserCore.shutdown().
According to the article, all browser instances should disposed when you don't need them. Please try disposing all browser instances before closing your application.
With Install4j I am trying to do a silent upgrade without shutting down the app it is upgrading. I am receiving the following error "The application is running. Please close all instances and run this installer again." Is there any way around this. I am calling the installer from my code with the following code
String [] args = new String[1];
args[0] = "-q";
ApplicationLauncher.launchApplicationInProcess("6661", args, new ApplicationLauncher.Callback() {
#Override
public void exited(int i) {
logger.info("The installer exited");
}
#Override
public void prepareShutdown() {
logger.info("Calling the prepareShutowon fuction");
}
}, ApplicationLauncher.WindowMode.DIALOG, null);
This does not seem to work. The upgrade only works if I close the application which I do not want do.
With Install4j I am trying to do a silent upgrade without shutting down the app it is upgrading.
That is not possible, on Windows JAR files and executables cannot be overwritten if they are in use by a running executable.
In the updater, you need a "Shut down calling launcher" action just before the new installer is started. You have probably removed that action from the default configuration. The new installer can then restart the application automatically with an "Execute launcher" action on the "Finish" screen.
I'm doing a Java based media-player but I have a problem showing the video in full screen.
When I use components.getMediaPlayer().setFullScreen(true); I get the following error:
Exception in thread "JavaFX Application Thread"
java.lang.UnsatisfiedLinkError: Unable to load library 'X11': JNA
native support (win32-x86/X11.dll) not found in resource path
I use a JVM 32Bit, JNA 3.5.2 and VLCJ 3.0.1.
From what I have seen is loading the 32bit libraries but my OS is 64bit. Is this the problem?
It looks like you are trying to load the X11 library in Windows.
That is not going to work.
vlcj uses the X11 native library on Linux to switch a Java JFrame to full-screen.
On Windows, vlcj provides a different native solution using the Win32 API.
So on Windows you can do something like this when you create your media player:
mediaPlayerComponent = new EmbeddedMediaPlayerComponent() {
#Override
protected FullScreenStrategy onGetFullScreenStrategy() {
return new Win32FullScreenStrategy(frame);
}
};
On Linux you would use something like this:
mediaPlayerComponent = new EmbeddedMediaPlayerComponent() {
#Override
protected FullScreenStrategy onGetFullScreenStrategy() {
return new XFullScreenStrategy(frame);
}
};
Of course if you want to support either/or, you can make a conditional check at runtime, something like:
mediaPlayerComponent = new EmbeddedMediaPlayerComponent() {
#Override
protected FullScreenStrategy onGetFullScreenStrategy() {
if (RuntimeUtil.isWindows()) {
return new Win32FullScreenStrategy(frame);
}
else {
return new XFullScreenStrategy(frame);
}
}
};
Why is full-screen functionality implemented this way?
It is because full-screen functionality using core Java is unreliable - on some Windows versions it may be full-screen apart from the task bar for example, and on some Linux window managers it may not work at all.
To answer your question about 32-bit DLL vs 64-bit OS: what matters here is whether your JVM architecture is 32-bit, i.e. the JVM architecture must match the architecture of the shared libraries that you are trying to load.
I'm trying to set up JRI with Eclipse on a Windows 7 x64 system. I tried it once on my Laptop and it worked. Now on my Desktop it fails although everything of the R, rJava and JRI installation is exactly the same.
I set the JRI and R Paths correctly to:
C:\Program Files\R\R-2.15.1\library\rJava\jri;C:\Program Files\R\R-2.15.1\bin\x64
Also I set R_DOC_DIR etc in Eclipse.
Every time I try to run new Rengine(...); it fails without any error or exception. Debugging revealed an: <terminated, exit value: 10>C:\Program Files\Java\jre6\bin\javaw.exe (01.10.2012 18:00:31)
Is there anything I can try? It really bothers me that it works an my Laptop but not on my Workstation despite the same settings everywhere.
Edit: The code that is used to get the Rengine object.
public static Rengine getRengine(){
if (re == null) createRengine();
return re;
}
public static void createRengine(){
if (re!=null) return;
try{
if (!Rengine.versionCheck()) {
System.err.println("** Version mismatch **");
System.exit(1);
}
String[] arguments = {"--save"};
re=new Rengine(arguments, false, null);
if (!re.waitForR()) {
System.out.println("Cannot load R");
return;
}
}
catch (Exception e){
e.printStackTrace();
}
}
Edit: The last time i tried it i got an errormessage (creating of the REngine worked, this happened never before), R was missing a registryentry. After installing R 2.15.1 again it suddenly worked. Now after a restart it's the same like before. The program crashes at the creation of the REngine.
I was having the exact same problem. It turns out I had unchecked the box that asks to make a registry entry with the R version number. Once I let the installer run with that box checked, it seemed to work.
I would make sure your regedit looks like this:
Next up: getting this working in a portable way...
I am using R 3.2.2 and eclipse Mars on Windows 10 x64.
I faced the described issue today and tried around a bit. Finally, I found the root cause in the build path. Please check whether the following conditions are fulfilled:
1.) The following Java libraries from the JIRI folder on your hard disk shall be included as (user) libraries:
JIRI.jar
REngine.jar
JRIEngine.jar
2.) The native library jiri.dll is located in the subfolder "i386" for x86, whereas for x64 it is available in the subfolder "x64". The relevant one shall be added as separate native library location to the Java Build Path of the eclipse project. Otherwise, the file may not be considered as it is not located in the main JIRI folder.
Best regards
Philipp
I'm having some trouble playing MIDI files in Java. What I get is a MidiUnavailableException (MIDI OUT transmitter not available) when I try to play it. My code is standard:
try {
midiseq = MidiSystem.getSequencer();
midiseq.open();
midiseq.setSequence(MidiSystem.getSequence(sound1));
midiseq.setLoopCount(Sequencer.LOOP_CONTINUOUSLY);
midiseq.start();
} catch (Exception e) {e.printStackTrace();}
midiseq is a Sequencer; sound1 is an InputStream.
This code works on several other computers, and even works in Eclipse and when used in a JAR file, just not when I launch it from the command prompt. I've downloaded a more stable Java midi application, and it threw the same exception.
It can't be a hardware problem because Eclipse can run it without problems, neither can it be a coding problem because this runs correctly on other computers. Even this one line of code throws this exception:
javax.sound.midi.MidiSystem.getSequencer();
Thanks in advance.
edit: My operating system is Windows Vista. Before I asked this question I've downloaded the latest JRE and JDK (1.6.0_13 I think).
edit: The code:
ClassLoader.getSystemClassLoader().loadClass("com.sun.media.sound.RealTimeSequencer");
System.out.println( "Sequencer class loaded" );// Otherwise ClassNotFoundException
prints "Sequencer class loaded."
But this code:
try{
System.out.println(javax.sound.midi.MidiSystem.getSequencer());
System.exit(0);
} catch(Exception e) {
throw new RuntimeException(e);
}
System.exit(1);
throws the MidiUnavailableException.
Also, this code:
MidiDevice.Info[] devices = MidiSystem.getMidiDeviceInfo();
if (devices.length == 0) {
System.out.println("No MIDI devices found");
} else {
for (MidiDevice.Info dev : devices) {
System.out.println(dev);
}
}
gives me this:
Microsoft MIDI Mapper
Microsoft GS Wavetable Synth
Real Time Sequencer
Java Sound Synthesizer
First have a look at the capabilities of your system:
MidiDevice.Info[] devices = MidiSystem.getMidiDeviceInfo();
if (devices.length == 0) {
System.out.println("No MIDI devices found");
} else {
for (MidiDevice.Info dev : devices) {
System.out.println(dev);
}
}
If there is nothing there, you might need to install soundbanks to enable the
jvm to create a software sequencer.
Also check the output of MidiSystem.getReceiver() as the dreaded MidiUnavailableException will also occur if a receiver can not be created (MidiSystem javadoc).
I expect that installing the soundbank file will give the jvm the opportunity to fall back on a synthesizer receiver, and not require hardware access anymore (which seems to fail:)
Is it possible that it has something to do with permissions? If you're running the JAR file as a different (more privileged) user than the plain command-line program, that might explain the difference. If it's not that, maybe some Java system property... I can't think of anything else that would make a difference between running the same code as a JAR file or as individual .class files.
It might help if you edit the question to provide more details about the different ways you've been running the program.
WHen launching from the command prompt makes it fail, but launching from a JAR works, I'd check if you really use the same Java version for both cases. For the Jar, check file associations in Windows Explorer, and for the commandline, check whether java -version outputs the expected version (if not, dig through your PATH variable).
Also (another shot in the dark), can you try and do a hard-shutdown on any other application that may be using sound and specifically Midi devices? I know that people get this problem on some Linuxes when another application uses Midi and doesn't release it.
When you have JMF2.1.1e installed, remove all sound.jar files which are not only installed in the JMF directory but also in the jre and jdk directories.
http://www.coderanch.com/t/274513/java/java/javax-sound-midi-compatibility-JMF says:
The problem is the file sound.jar Find it in 3 places and delete it.
C:\Program Files\JMF2.1.1e\lib\sound.jar
C:\Program Files\Java\jdk1.6.0_07\jre\lib\ext\sound.jar
C:\Program Files\Java\jre1.6.0_07\lib\ext\sound.jar
Also, remove sound.jar reference from PATH and CLASSPATH
This is an old sound.jar that messes up the new sound API in the new versions of Java.
Could you add your operating system and java version?
And post the exception; Java generally does a fair job saying whats wrong. It's just not always easy to understand :)
On my mac with java 1.5.0_16 I don't get an exception (on the command line).
The following program
public class MidiTester {
public static void main(String[] args) {
try{
System.out.println(javax.sound.midi.MidiSystem.getSequencer());
System.exit(0);
} catch(Exception e) {
throw new RuntimeException(e);
}
System.exit(1);
}
}
prints
com.sun.media.sound.RealTimeSequencer#d08633
You could check whether you have the sequencer class on the classpath:
ClassLoader.getSystemClassLoader().loadClass("com.sun.media.sound.RealTimeSequencer");
System.out.println( "Sequencer class loaded" );// Otherwise ClassNotFoundException
This would at least make it clear whether you do not have the classes (in the java accessed via the PATH), or whether it's something different like a permission problem.
Point explorer to your JRE folder (the one above the bin folder on the $PATH you are using to run the program) e.g. "C:\Program Files\Java\jre1.6.0"
Go into the \lib folder. Do you see a folder called "audio"? Does it have anything in?
If not, go to http://java.sun.com/products/java-media/sound/soundbanks.html
download any of the MIDI banks as described, and copy it into the said folder.
let us know if it works!
I've found the same problem: unable to play MIDI. But I've noticed that the problem had started when I upgrade the JDK from 1.6.0_10 to 1.6.0_13.
I tested both JDKs with the simple program:
public class MidiTester {
public static void main(String[] args) {
try{
System.out.println(javax.sound.midi.MidiSystem.getSequencer());
System.exit(0);
} catch(Exception e) {
throw new RuntimeException(e);
}
System.exit(1);
}
}
JDK 1.6.0_10 gave the result:
com.sun.media.sound.RealTimeSequencer#1bd747
JDK 1.6.0_13 gave the result:
Exception in thread "main" java.lang.RuntimeException: javax.sound.midi.MidiUnavailableException: MIDI OUT transmitter not available
at ivan.seaquest.MidiTester.main(MidiTester.java:10)
Caused by: javax.sound.midi.MidiUnavailableException: MIDI OUT transmitter not available
at com.sun.media.sound.AbstractMidiDevice.createTransmitter(AbstractMidiDevice.java:444)
at com.sun.media.sound.AbstractMidiDevice.getTransmitter(AbstractMidiDevice.java:299)
at javax.sound.midi.MidiSystem.getSequencer(MidiSystem.java:451)
at javax.sound.midi.MidiSystem.getSequencer(MidiSystem.java:348)
at ivan.seaquest.MidiTester.main(MidiTester.java:7)
I'm going to create a bug at Sun. I hope it helps...
I have had the same problem. The error was caused by JMF included in the classpath.