Xletview: why not use sun's javaTV source code directly ?

Question

xletview : one emulator for viewing MHP Xlets on a PC;
I see many difference from sun's code about the part of javaTV.
Why the author Martin Sveden need to rewrite them and not use sun's javaTV source code directly ?
Thank you for your any answer.
Sorry for my horrible english.

Answer 1

XleView is a fine effort, but it has its limitations. I tried using it for the GunBunny demo available in the JavaME SDK 3.0 Eary Access available in
http://java.sun.com/javame/downloads/sdk30ea.jsp
and I encountered some of thost limitations. What Sveden does it several tricky manipulations in a classloader for the Xlet. In particular, he translates bytecode as he loads the Xlet's classes, changing some class names, such as changing
java.awt.Toolkit
tto
xjava.awt.Toolkit
This works up to a point. This version of Toolkit usually just turns around calls java.awt.Toolkit's corresponding routine, but he deliberately he does not implement the ubiquitous
public Image createImage(URL url)
When I downloaded his source and tried adding ths into his code, I then encountered at runtime
Uncaught error fetching image:
java.lang.NullPointerException
at sun.awt.image.URLImageSource.getConnection(URLImageSource.java:97)
at sun.awt.image.URLImageSource.getDecoder(URLImageSource.java:107)
at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:240)
at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:172)
at sun.awt.image.ImageFetcher.run(ImageFetcher.java:136)
I think that this is some optimization within J2SE where they do not wait for the image to load and do the fetching in a separate thread. I do not know if there is some way to force the Sun's JVM to disable this optimization and I have not investigated furher, but I did email Svenden. I noticed that the current version of XleTView is 0.3.6 which is dated June 2004 and the web site http://www.xletview.org/ has had not news since 2005 .
I note that Svenden provides an elegant user interface but I advise you not try to learn the API's from his classes: he makes no effort to keep his implementation separate from the API standards so, for instance, his version of HScene is
package org.havi.ui;
public class HScene extends Container
implements HComponentOrdering, ImageObserver, MenuContainer, Serializable {
whereas the real standard is
public class HScene extends Container
implements HComponentOrdering {
I hate to critize such a fine effort, but it is best to keep an imlementation separate from the public API.
I agree that having a lightweight, simple and Java feature-complete Xlet viewer running would be very helpful, especially if BD-J gains much popularity. I have found trying to work with the vendor players described at
http://wiki.java.net/bin/view/Mobileandembedded/Blu-RayDiscHelloWorld
to be frustrating. I tried all four mentioned and I have gotten none of them to work for me yet. These are huge downloads and the "Intro Version" of Arcsoft pointed to at the SDK 3.0 Early Access page
http://www.arcsoft.com/products/totalmediatheatre/
just gives a "File not found" HTML page. This forum post mentions that perhaps it was recently taken down?
http://www.arcsoft.com/forum/forum_posts.asp?TID=1084
I have already emailed Michael Downs of Arcsoft since he is mentioned here:
http://wiki.java.net/bin/view/Mobileandembedded/BDJPCPlayers
What did work for me was to take Sun's JavaTV 1.1 Reference Implementation and PowerDVD's BDJ.jar and hack/fix a few classes to get GunBunny to work within the RI's RunXlet program. This is not trivial but I will will describe:
Download the JavaME 3.0 SDK EA and then download the correct version of PowerDVD that the SDK page points to:
http://www.brothersoft.com/powerdvd-download-50794.html
Download the RI binary and source of Java TV API 1.1
http://java.sun.com/javame/technology/javatv/index.jsp
Since I am too lazy to use anything but the latest 1.6 JRE as a runtime, I have to fix
com.sun.tv.media.util.MediaThread
to comment out its stop() method. This is becase stop() was deprecated and made final in J2SE 1.5
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#stop()
http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
Next, I had to mae a change to Sun's JavaTV implementation to keep the GunBunny demo happy by providing a ServiceContext. The RunXlet program calls SIEmulator, but that environment does not provide a ServiceContex, so I added one back in:
com.sun.tv.receiver.SIEmulator
private static ServiceContext svcctx = null;
Add before every call to new AppSignalEvent() and add the svcctx as the second-to-last argument:
if(svcctx == null){ try { svcctx = new com.sun.tv.ServiceContextImpl(); }catch (Exception e){ e.printStackTrace(); } }
I then had to hack a few PowerDVD classes, which is evil of me. First, I had to build an empty class by the name of
sun.util.BDJPlugin
becuase some PowerDVD class extends it but it is not in its BDJ.jar and then I had to reverse-compile (evil!) and modify one of their internal classes to avoid a dependency on their native methods. What I ended up with was a hacked version of com.cl.bdj.helper.CUtil to avoid the native methods which access the registry where they query for registry settings but also provide a default value (which I return).
com.cl.bdj.helper.CUtil
private static String pGetRegistryString(long i ,String string ,String string3) {
return string3;
private static int pGetRegistryInt(long i ,String string ,int j) {
return j;
The last thing I had to do was to change com.hdccookbook.gunbunny.BaseXlet, to use the JavaTV container rather than the org.havi one:
import javax.tv.graphics.TVContainer;
import java.awt.Container;
change
// protected HScene scene;
protected Container scene;
public final void run() {
// waitForPresenting();
// scene = HSceneFactory.getInstance().getDefaultHScene();
scene = TVContainer.getRootContainer(xletContext);
In order to having working keys, I had to add the KeyListener interface to BaseXet and
run(){
addKeyListener(this);
and then add a near duplicate of the org.dvb.event.UserEvent* stuff that is already there:
public void keyPressed(KeyEvent e){
switch(e.getKeyCode()){
case KeyEvent.VK_0:
case KeyEvent.VK_1:
case KeyEvent.VK_2:
case KeyEvent.VK_3:
case KeyEvent.VK_4:
case KeyEvent.VK_5:
case KeyEvent.VK_6:
case KeyEvent.VK_7:
case KeyEvent.VK_8:
case KeyEvent.VK_9:
numberKeyPressed(e.getKeyCode() - KeyEvent.VK_0);
break;
case KeyEvent.VK_ENTER:
enterKeyPressed();
break;
case KeyEvent.VK_LEFT:
arrowLeftKeyPressed();
break;
case KeyEvent.VK_RIGHT:
arrowRightPressed();
break;
case KeyEvent.VK_UP:
arrowUpPressed();
break;
case KeyEvent.VK_DOWN:
arrowDownPressed();
break;
public void keyReleased(KeyEvent e){
// System.out.println("Released: e="+e+" code="+e.getKeyCode());
public void keyTyped(KeyEvent e) {
// System.out.println("Typed: e="+e+" code="+e.getKeyCode());
It then comes up and functions, but the rendering is not very good. Again, this is complete hack. Running the Java TV 1.1 RI in a JRE 1.6 is not supported. If you try to run any of the other examples, you will discover that the XML parsing is broken in JRE 1.6 with this message:
Parsing failed: com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequence
Exception: Invalid byte 1 of 1-byte UTF-8 sequence., file: lib\JavaTVSampleFile01.xml
and you have to go and change the lines in
lib\JavaTV.properties
from
ServiceFileHandler=com.sun.tv.receiver.ReceiverFile
# ServiceFileHandler=SampleData_01
to
# ServiceFileHandler=com.sun.tv.receiver.ReceiverFile
ServiceFileHandler=SampleData_01
and build samples\db\SampleData_01.java and put it in your classpath along with all these other hacks.
Nonetheless, if you want to develop a somewhat generic Xlet that uses some BD-J features, that is how you might do it. But the moment you exercise anything else in the vendor's BDJ.jar that simply doe snot work outside of their environment or invokes one of their native methods, you are again stuck.
It would be nice if Sun would at least bother to update the JavaTV RI with the fixes I hae mentioned. Their "jmflite" implementation does not render perfecly but at least it would give the programmer something to work with without having to deal with an older JRE, etc.
Andrew
Edited by: AndrewMorrow on Oct 20, 2008 2:48 AM