Skip to main content

The Act We Act

Posted by editor on May 29, 2008 at 6:19 AM PDT


Banishing the applet warning

The lowly Java applet is seemingly poised to make a comeback, thanks to the radically overhauled plug-in in Java SE 6 Update 10 and its many improvements (quick start, doesn't crash the browser, applets tear off and become Web Start apps, etc.), along with the growing interest in Rich Internet Applications. For some, that means it's 1996 all over again, as we go running to find our old copies of Laura Lemay's Teach Yourself Java in 21 Days and figure out the parameters for the <applet&gt tag again... or wait, do I do an <object&gt or an <embed&gt or something now? Dang, it's been a while.

And of course, once you get your applet up and running, you come up against the security restrictions meant to protect against malicious applets. No filesystem access, no network access to any host other than the one the applet came from, etc. You can get around this by signing your applet, but then the user will have to explicitly grant access permissions, which typically means tech support gets calls from people who are terrified and confused by the security dialog. Someone somewhere sighs, and asks, "are you sure we can't just do this with DHTML and CSS?"

Josh Marinacci notes that the security back door has been opened just a little bit in 6u10, as he explains in Java Doodle: crossdomain.xml Support:

Signing is great when you need access to more than what is allowed inside the sandbox, but it has two problems: the user will receive an ugly warning dialog about the applet, and the applet will have full access to the user's computer. Full access is overkill when all you want to do is talk to a webservice on another server. Surely there is some middle ground between the sandbox and full access? Well now there is.

If the server hosting a webservice has special xml file on it then the applet plugin will allow connections to that server. This special file is called a crossdomain.xml file and it must be present on the exact subdomain hosting the webservice.

To show it off, Josh offers an applet hosted on his home server that pulls photos from Flickr. Full details of the needed XML, plus a graceful degredation strategy, are provided in the blog, which he says is "the first in a series I'm going to call Java Doodles, highlighting the new features in JavaSE 6 update 10, now in beta."

Hey, Josh, I thought you were already doing a "doodles" series with JavaFX? Oh well, same basic idea, right?


Also in today's Weblogs, Kirill Grouchnikov previews
Performance improvements in Substance 5, in which he is
"addressing the user complaints on bad performance of Substance look-and-feel."

The topic-specific retrospective continues in
Eamonn McManus
JavaOne report: JMX Technology.
"This is the fourth installment in my summary of the sessions I attended at JavaOne this year. This one covers all the JMX sessions. Capsule summary: my presentation with Jeff; JMX security; JMX configuration in clusters..."


The latest Java Mobility Podcast is
Java Mobility Podcast 47: Johannesburg Town Hall,
a live recording from the Town Hall meeting at the Johannesburg Mobility Days.


In Java Today,
a new SDN article by Erik Hellman, New gaming experiences with OpenGL ES and the Mobile Sensor API, predicts a new interaction paradigm for Java ME gaming. "We have just recently started to see the use of accelerometers in applications and games, and I believe that built-in accelerometers in mobile phones will become even more common as new mobile games appear. For Java ME, we already have an API for reading these accelerometers, the Mobile Sensor API (JSR-256). This article will describe a very simple game for a Sony Ericsson w910i that uses both the OpenGL ES API for Java ME and the Mobile Sensor API."

The GlassFish Awards Program is allocating part of its $175K prize budget into a bug hunt. As Eduardo Pelegri-Llopart explains, "GAP reserves $50K for bug submissions with a target of 100 winning submissions. For those of you math-savy, that is $500; not bad for a bug report! Unfortunately, Sun employees don't qualify :-), but, the rest of you, hurry up and submit!"

Looking for a new gig or for good employees? Visit the java.net Jobs Wiki, which allows registered java.net members to post job listings or resumes. Browsing the job and resume listings is open to all, with or without a java.net login.


In today's Forums, terrencebarr explains mobile industry realities in
Re: State of SavaJE.
"You're correct that fragmentation spreads over multiple levels. Because of they way the technology and the industry is structured some aspects are harder to address than others. Working towards a consistent API and platform model is a big help as well as addressing some of the device- and carrier-specific issues (such as signing). It doesn't fix all points but these are some of the most painful ones."

wasif discusses support for a recent ME feature in
Re: Using Push Registry.
"Yes you are right terren, all phones having MIDP 2.0 are bound to have Push Registry functionality, but it depends at what extent it supports push registry, because some mobiles only support alarm based push registry and some provide the functionality of both alarm and connection based, so while testing on mobile phones you often don't get the required results as you expect it to be. but still there are large amount of mobile phones that support pushregistry to its fullest."

franknatoli is trying to go from
XML to XML using XSLT.
"Am XSLT newbie. Need to read XML file, swap the order of two complex objects, and write XML file. If I understand the XSLT capabilities correctly, this is not the kind of transformation that XSLT is designed to do. I understand that XSLT can extract the values of XML elements, and the programmer can insert those values into the output XML. But I really need to copy whole XML element declarations, meaning tags, attributes, etc., not just the values. Can XSLT do this?"


Current and upcoming Java
Events
:

Registered users can submit event listings for the href="http://www.java.net/events">java.net Events Page using our href="http://today.java.net/cs/user/create/e">events submission form.
All submissions go through an editorial review before being posted to the
site.


Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of java.net it will be
archived along with other past issues in the href="http://today.java.net/today/archive/">java.net Archive.

Banishing the applet warning

Comments

"If the server hosting a webservice has special xml file on it then the applet plugin will allow connections to that server. This special file is called a crossdomain.xml file and it must be present on the exact subdomain hosting the webservice. "

I'd call that a massive security risk. It allows any mallicious website to circumvent applet security by creating such a file and putting it on their system (not even the client's system). Inject a mallicious applet into another (innocent) server's html (would require a hole in that server of course), and you can do a lot of things on that client that that client isn't aware of.

Yet another reason not to use Java 1.6. They do keep piling up...

There's also still the Flash-works-well-on-Mac-and-Java-doesn't problem.

As already mentioned elsewhere, if Sun doesn't:
  • get rid of the tray icon (and the ridiculous "Come visit us at Java.com" balloon);
  • simplifies the installation, ditching the OpenOffice ad, and ;
  • makes the installation package as easy to find as the Flash plugin (ie, "you need Java to run this applet, click here")
I seriously doubt that applets will make a comeback. And really, this is the last chance we've got. Screw up now and give up forever.

While I'm a bit puzzled about that file, my understanding is that it's a standard de facto in the Flash world, and it has just been adopted by Java 6. I mean, it could have been widely used to break systems in the Flash world, but we don't have notice of that.