I mentioned a small demo. in
Setting up policies for an Applet embedded in HTML & an Iced Tea JRE user commented that the demo. failed
for them. They refused permission to the applet (thereby limiting it to the sand-box) & were supposed to see
the green colored 'this applet is sand-boxed' page. Instead the applet completely failed and they saw a 'gray space'
where the applet should have been.
I am WAGing that it was attempting to instantiate a File object that is the difference. I.E.
The Sun/Oracle JRE will allow it without problem, only throwing a security exception
when the applet attempts to create the JFileChooser. OTOH the Iced Tea JRE does not allow the
File to be created.
As such, this code should fix that problem. It moves the creation/adding of the
JEditorPane and installation of 1st
an 'all else fails' message, then the green colored 'sand-boxed' page, to before the new File(..) call.
My question is. Does this code 'work as advertised' for users with an Iced Tea JRE?
To test it:
Visit the applet at
pscode.org/test/docload/applet-latest.html
Refuse the digitally signed code. This is very important to create the right
conditions to test the applet.
Observe/report whether the applet loads the green colored
sandbox.html. The sand-boxed
document will represent 'success' at fixing the bug.
Also of interest (what little there might be) is the homepage for the
Demo of Defensive Loading of Trusted Applets, which links
to the applet page(s), each of the HTML files displayed in the applet, and a ZIP archive containing the
source of the code & HTML, and an Ant build.xml so you can 'do this at home, kids'.
Here is the new code.
package org.pscode.eg.docload;
import java.awt.BorderLayout;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
import javax.swing.JApplet;
import javax.swing.JButton;
import javax.swing.JEditorPane;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JFileChooser;
import java.net.URL;
import java.net.MalformedURLException;
import java.io.File;
import java.io.IOException;
import java.security.AccessControlException;
/** An applet to display documents that are JEditorPane compatible.
This applet loads in a defensive way in terms of the security environment,
in case the user has refused to accept the digitally signed code. */
public class DocumentLoader extends JApplet {
JEditorPane document;
#Override
public void init() {
System.out.println("init()");
JPanel main = new JPanel();
main.setLayout( new BorderLayout() );
getContentPane().add(main);
document = new JEditorPane("text/html",
"<html><body><h1>Testing</h1><p>Testing security environment..");
main.add( new JScrollPane(document), BorderLayout.CENTER );
System.out.println("init(): entering 'try'");
try {
// set up the green 'sandboxed URL', as a precaution..
URL sandboxed = new URL(getDocumentBase(), "sandbox.html");
document.setPage( sandboxed );
// It might seem odd that a sandboxed applet can /instantiate/
// a File object, but until it goes to do anything with it, the
// JVM considers it 'OK'. Until we go to do anything with a
// 'File' object, it is really just a filename.
System.out.println("init(): instantiate file");
File f = new File(".");
System.out.println("init(): file instantiated, create file chooser");
// Everything above here is possible for a sandboxed applet
// *test* if this applet is sandboxed
final JFileChooser jfc =
new JFileChooser(f); // invokes security check
jfc.setFileSelectionMode(JFileChooser.FILES_ONLY);
jfc.setMultiSelectionEnabled(false);
System.out.println(
"init(): file chooser created, " +
"create/add 'Load Document' button");
JButton button = new JButton("Load Document");
button.addActionListener( new ActionListener(){
public void actionPerformed(ActionEvent ae) {
int result = jfc.showOpenDialog(
DocumentLoader.this);
if ( result==JFileChooser.APPROVE_OPTION ) {
File temp = jfc.getSelectedFile();
try {
URL page = temp.toURI().toURL();
document.setPage( page );
} catch(Exception e) {
e.printStackTrace();
}
}
}
} );
main.add( button, BorderLayout.SOUTH );
// the applet is trusted, change to the red 'welcome page'
URL trusted = new URL(getDocumentBase(), "trusted.html");
document.setPage(trusted);
} catch (MalformedURLException murle) {
murle.printStackTrace();
document.setText( murle.toString() );
} catch (IOException ioe) {
ioe.printStackTrace();
document.setText( ioe.toString() );
} catch (AccessControlException ace) {
ace.printStackTrace();
// document should already be showing sandbox.html
}
}
#Override
public void start() {
System.out.println("start()");
}
#Override
public void stop() {
System.out.println("stop()");
}
#Override
public void destroy() {
System.out.println("destroy()");
}
}
Here is the output on java.stderr (one half of the equivalent of the Java console - the other half is java.stdout, which is empty in your case):
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:604)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Jars not verified.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.checkTrustWithUser(JNLPClassLoader.java:467)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:410)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:168)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:575)
... 2 more
Caused by:
net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Jars not verified.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.checkTrustWithUser(JNLPClassLoader.java:467)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:410)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:168)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:575)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
java.lang.NullPointerException
at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
at sun.applet.AppletPanel.run(AppletPanel.java:380)
at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
at sun.applet.AppletPanel.run(AppletPanel.java:430)
at java.lang.Thread.run(Thread.java:636)
java.lang.Exception: Applet initialization timeout
at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:637)
at sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java:270)
at sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.java:82)
java.lang.RuntimeException: Failed to handle message: handle 60822154 for instance 2
at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:660)
at sun.applet.PluginStreamHandler.handleMessage(PluginStreamHandler.java:270)
at sun.applet.PluginMessageHandlerWorker.run(PluginMessageHandlerWorker.java:82)
Caused by: java.lang.Exception: Applet initialization timeout
at sun.applet.PluginAppletViewer.handleMessage(PluginAppletViewer.java:637)
... 2 more
So, it looks like your applet code is not even loaded if I press Cancel in the dialog box.
I think there is nothing you can do here from the Java side - maybe using another signing procedure or starting the applet by JNLP would help. Or filing a bug report on IcedTea.
To demonstrate this, I created a real simple applet by omitting everything critical from your applet:
package org.pscode.eg.docload;
import java.awt.FlowLayout;
import javax.swing.*;
public class Example extends JApplet {
JLabel label;
public void init()
{
System.out.println("init()");
SwingUtilities.invokeLater(new Runnable(){public void run() {
label = new JLabel("inited.");
getContentPane().setLayout(new FlowLayout());
getContentPane().add(label);
}});
}
#Override
public void start() {
System.out.println("start()");
label.setText("started.");
}
#Override
public void stop() {
System.out.println("stop()");
label.setText("stopped.");
}
#Override
public void destroy() {
System.out.println("destroy()");
label.setText("destroyed.");
}
}
I compiled this and modified your HTML file to use this instead, and it gives totally the same symptoms.
It seems IcedTea has redefined what to do when the user presses cancel. To be fair, the buttons in the dialog box are "Run" and "Cancel", not "Run with all permissions" and "Run sandboxed".
(In Sun's dialog there are the same buttons, but in effect they mean something else than asked.)
For reference, I can confirm #Paŭlo Ebermann's results using IcedTea 1.9.7 on Ubuntu 10.04:
$ java -version
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.7) (6b20-1.9.7-0ubuntu1~10.04.1)
OpenJDK Client VM (build 19.0-b09, mixed mode, sharing)
appletviewer shows the expected sandbox and the fllowing diagnostic output. Firefox on Ubuntu offers only Run (trusted) or Cancel (nothing).
$ appletviewer http://pscode.org/test/docload/applet-latest.html
Warning: Can't read AppletViewer properties file: … Using defaults.
init()
init(): entering 'try'
init(): instantiate file
init(): file instantiated, create file chooser
java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
at java.security.AccessController.checkPermission(AccessController.java:553)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302)
at java.lang.System.getProperty(System.java:669)
at javax.swing.filechooser.FileSystemView.getHomeDirectory(FileSystemView.java:397)
at javax.swing.plaf.metal.MetalFileChooserUI.installComponents(MetalFileChooserUI.java:282)
at javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserUI.java:153)
at javax.swing.plaf.metal.MetalFileChooserUI.installUI(MetalFileChooserUI.java:155)
at javax.swing.JComponent.setUI(JComponent.java:651)
at javax.swing.JFileChooser.updateUI(JFileChooser.java:1781)
at javax.swing.JFileChooser.setup(JFileChooser.java:374)
at javax.swing.JFileChooser.(JFileChooser.java:347)
at javax.swing.JFileChooser.(JFileChooser.java:330)
at org.pscode.eg.docload.DocumentLoader.init(DocumentLoader.java:57)
at sun.applet.AppletPanel.run(AppletPanel.java:436)
at java.lang.Thread.run(Thread.java:636)
start()
stop()
destroy()
On Mac OS X, Safari 5.05 produces the expected results; and appletviewer produces comparable, but not identical, output.
$ java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-9M3326)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)
$ appletviewer http://pscode.org/test/docload/applet-latest.html
init()
init(): entering 'try'
init(): instantiate file
init(): file instantiated, create file chooser
java.security.AccessControlException: access denied (java.io.FilePermission . read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.exists(File.java:731)
at javax.swing.JFileChooser.setCurrentDirectory(JFileChooser.java:548)
at javax.swing.JFileChooser.(JFileChooser.java:334)
at javax.swing.JFileChooser.(JFileChooser.java:316)
at org.pscode.eg.docload.DocumentLoader.init(DocumentLoader.java:57)
at sun.applet.AppletPanel.run(AppletPanel.java:424)
at java.lang.Thread.run(Thread.java:680)
start()
stop()
destroy()
Related
I am trying to develop for the NAO robot from aldebaran. Sadly it does not work when I try to execute this piece of code in Java with the following error:
I am using the following JDKs:
java-naoqi-sdk-2.5.6.5-win32-vs2013.jar
jdk1.8.0_281
import com.aldebaran.qi.Application;
import com.aldebaran.qi.helper.proxies.ALTextToSpeech;
public class Main {
public static void main(String[] args) throws Exception {
String robotUrl = "tcp://nao.local:9559";
// Create a new application
Application application = new Application(args, robotUrl);
// Start your application
application.start();
// Create an ALTextToSpeech object and link it to your current session
ALTextToSpeech tts = new ALTextToSpeech(application.session());
// Make your robot say something
tts.say("Hello World!");
}
}
Error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Users\lucas\AppData\Local\Temp\qi.dll: %1 is not a valid Win32 application
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
at java.lang.Runtime.load0(Runtime.java:810)
at java.lang.System.load(System.java:1086)
at com.aldebaran.qi.SharedLibrary.extractAndLoad(SharedLibrary.java:133)
at com.aldebaran.qi.SharedLibrary.loadLibHelper(SharedLibrary.java:72)
at com.aldebaran.qi.SharedLibrary.loadLib(SharedLibrary.java:34)
at com.aldebaran.qi.EmbeddedTools.loadEmbeddedLibraries(EmbeddedTools.java:138)
at com.aldebaran.qi.Application.<clinit>(Application.java:16)
at Main.main(Main.java:9)
Process finished with exit code 1
Does anyone know how to fix this?
It should be compiling and it should connect to the robot.
Running my Java application with this code:
if (Desktop.isDesktopSupported())
{
Desktop d = Desktop.getDesktop();
try
{
d.browse(new URI("someurl")); // someurl is just an example, I am opening real url
}
catch (IOException | URISyntaxException e)
{
logger.warn(ExceptionUtils.getStackTrace(e));
}
}
results in application not responding (probably deadlock) on Manjaro Linux KDE. While it works with no problem on Windows, I do not want to check for OS in my application and allow it just for Windows. I have not tried other platforms yet.
What i use:
Adoptium JDK 11
Manjaro kernel 5.10.83-1-MANJARO 64bit
KDE Plasma 5.23.4
Qt 5.15.2
Detailed deadlock location:
Desktop class:
public void browse(URI uri) throws IOException {
checkAWTPermission();
checkExec();
checkActionSupport(Action.BROWSE);
Objects.requireNonNull(uri);
peer.browse(uri); // <- goes here
}
Deadlock happens in XDesktopPeer class that implements DesktopPeer interface (peer) on method gnome_url_show(...):
private void launch(URI uri) throws IOException {
byte[] uriByteArray = ( uri.toString() + '\0' ).getBytes();
boolean result = false;
XToolkit.awtLock();
try {
if (!nativeLibraryLoaded) {
throw new IOException("Failed to load native libraries.");
}
result = gnome_url_show(uriByteArray); // <- deadlock / app not responding here
} finally {
XToolkit.awtUnlock();
}
if (!result) {
throw new IOException("Failed to show URI:" + uri);
}
}
So... is Desktop#browse supported on Linux platform just for Gnome desktop?
I am guessing this, because of that method name.
If yes, can I make a check for deadlock around my code, so I prevent this in my app? rather than checking for OS and distros?
There are already several questions on SO about that issue:
Desktop.getDesktop().browse Hangs
Desktop and desktop.browse are supported, but browse still hangs
Desktop browse does not work in java for Ubuntu
There is also this discussion:
https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1574879
where someone says:
gnome_url_show is actually in libgnome-2-0 package
So, if the package is missing, Desktop.browse() will fail. There are 2 solutions to fix that.
Solution 1
Install the libgnome package.
Solution 2
Execute xdg-open to open the URL, e.g.:
Runtime.getRuntime().exec(new String[]{"xdg-open", someurl});
I currently want to try to create a .jar file that pinpoints to a .bat file to start a gaming server,
the Forge Modloader for the current version switched from a server startup via jar file to .bat file, and my server provider currently has no solution for it. -Small disclaimer, I haven't touched java for 6 years, which is why I may not see the obvious
For this, I found some code from Pavan.
Though, there are two problems, where I hope you may have a solution or some other workaround.
First of all, while in Intellij, "everything" works fine. main() is running, and the "Hallo World" Test .bat is opening. After compiling it to a jar, nothing happens, even with a set File Path.
Second Problem. I've tried several spots, but System.exit(0) does not work, after
int returnCode = CommandLineUtils.executeCommandLine(commandLine, systemOut, systemErr);
The code basically stops, and the process stays inactive, which could end up bad for a gaming server where I have 0 access to the needed tools to clean this up by myself... and I don't want to explain to Customer Support why there are 1000 instances of java running in the background ;)
But regardless, Thanks for your time and hopefully help as well
import java.io.File;
import java.io.OutputStreamWriter;
import org.codehaus.plexus.util.cli.CommandLineException;
import org.codehaus.plexus.util.cli.CommandLineUtils;
import org.codehaus.plexus.util.cli.Commandline;
import org.codehaus.plexus.util.cli.WriterStreamConsumer;
public class BatRunner {
public BatRunner() {
String batfile = "run.bat";
String directory = "C:\\Users\\User\\IdeaProjects";
try {
runProcess(batfile, directory);
} catch (CommandLineException e) {
e.printStackTrace();
}
}
public void runProcess(String batfile, String directory) throws CommandLineException {
Commandline commandLine = new Commandline();
File executable = new File(directory + "/" +batfile);
commandLine.setExecutable(executable.getAbsolutePath());
WriterStreamConsumer systemOut = new WriterStreamConsumer(
new OutputStreamWriter(System.out));
WriterStreamConsumer systemErr = new WriterStreamConsumer(
new OutputStreamWriter(System.out));
int returnCode = CommandLineUtils.executeCommandLine(commandLine, systemOut, systemErr);
System.exit(0);
if (returnCode != 0) {
System.out.println("Something Bad Happened!");
} else {
System.out.println("Taaa!! ddaaaaa!!");
}
}
public static void main(String[] args) {
new BatRunner();
}
}
Source: https://www.opencodez.com/java/how-to-execute-bat-file-from-java.htm/
I've tried to run a java applet using the javascript code in Eclipse IDE as shown in the web page Embedding Java Applet into .html file. But the output page shows error. My code to use applet is
<script src="//www.java.com/js/deployJava.js"></script>
in the head section and
<script>
var attributes = {
codebase : '../src/',
code : 'transfol.Main.class',
//archive: 'my-archive.jar',
width : '800',
height : '500'
};
var parameters = {
java_arguments : '-Xmx256m'
}; // customize per your needs
var version = '1.5'; // JDK version
deployJava.runApplet(attributes, parameters, version);
</script>
in the body section.
The way I've saved them is shown in the Navigator as
Main.class inside the package transfol which is in src folder (in Eclipse) and index.jsp in the web content
where Main.class is the applet and index.jsp is the file from which applet is being called.
I'm almost sure that the problem is in the codebase or code attributes where the path has to be specified, when I click on more information on applet, I get exception as:
The folloing exception has occured. For more information, try to launch the browser from the command line and examine the output.
For even more information you can visit http://icedtea.classpath.org/wiki/IcedTea-Web and follow the steps described there on how to obtain necessary information to file bug
Additional information may be available in the console or logs. Even more information is available if debugging is enabled.
Another available info:
IcedTea-Web Plugin version: 1.5 (1.5-1ubuntu1)
26/5/15 5:56 PM
Exception was:
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button".
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:746)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908)
Caused by: java.lang.ClassNotFoundException: Can't do a codebase look up and there are no jars. Failing sooner rather than later
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:716)
... 2 more
This is the list of exceptions that occurred launching your applet. Please note, those exceptions can originate from multiple applets. For a helpful bug report, be sure to run only one applet.
1) at 26/5/15 5:47 PM
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button".
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:746)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908)
Caused by: java.lang.ClassNotFoundException: Can't do a codebase look up and there are no jars. Failing sooner rather than later
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:716)
... 2 more
Try below code
<APPLET CODE=AppletSubclass.class WIDTH=anInt HEIGHT=anInt>
</APPLET>
OR
<object width="400" height="400" data="helloworld.class"></object>
Try this
Java applet
package cdig;
import java.applet.Applet;
import java.security.AccessController;
import java.security.PrivilegedAction;
public class CDigApplet extends Applet
{
private static final long serialVersionUID = 1L;
String ret;
CDigApplet applet = this;
#SuppressWarnings({ "rawtypes", "unchecked" })
public String signFile(String fileID, String pin, String token)
{
AccessController.doPrivileged(new PrivilegedAction()
{
#Override
public Object run()
{
try
{
System.out.println("Iniciando processo de assinatura.");
}
catch (Exception e)
{
String sl = "{\"success\":false," + "\"message\":\"" + e.getMessage() + "\"}";
ret = sl;
System.out.println(sl);
}
return null;
}
});
return ret;
}
public void init(){
}
public void destroy(){
}
}
HTML
<script>
<!-- applet id can be used to get a reference to the applet object -->
var attributes = { id:'cdigApplet', code:'cdig.CDigApplet', archive:'cdig-applet-1.0.jar', width:1, height:1, classloader_cache:'false'} ;
var parameters = {persistState: false, cache_option:'no' } ;
deployJava.runApplet(attributes, parameters, '1.8');
</script>
Call via javascript
var res = document.getElementById("cdigApplet").signFile(Id, '', token);
Don't forget to sign your applet and to not run your app with a URL with underscores '_' like this.
I have a Java Applet that interacts with the Java Plugin to show a document (just a URL) in a named browser window:
public class TestApplet extends Applet {
#Override
public void init() {
super.init();
final JButton showButton = new JButton("Show Google!");
showButton.addActionListener(new AbstractAction() {
public void actionPerformed(ActionEvent e) {
try {
getAppletContext().showDocument(new URL("http://google.com"), "Some Window Title");
} catch (MalformedURLException e1) {
e1.printStackTrace();
}
}
});
add(showButton);
}
}
This has worked historically but starting with Java 7 and Java 6u27, the window fails to open in Internet Explorer (tested in IE 8). If I use _blank as the window title (target) instead of Google, the window opens correctly (albeit in a new window each time).
I've tracked down this bug that was fixed for 6u27:
Vista/IE7 further showDocument focus issue with named targeted windows
Has anybody else experienced the same behaviour? Have you found a workaround (other than using "_blank")?
Edit
Updated the example. I wasn't actually using "Google" as the target, I was using "Some Window Title" (sorry!). It seems like this problem is unique to targets with spaces in the name.
It seems like this problem is unique to targets with spaces in the name.
Two possible solutions:
Replace the " " with "%20"
Don't use a space in the name of the target! (Though I thought that would be a 'no brainer'.)
Try this code, it should work.
Desktop desktop = Desktop.getDesktop();
desktop.browse(new URI(info));