2 Replies Latest reply: Oct 20, 2008 5:40 AM by 843851 RSS

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

    843851
      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.
        • 1. Re: xletview: why not use sun's javaTV source code directly ?
          843851
          The main reason is that XleTView is released under a GPL licence. This is not compatible with the license for Sun's reference implementation for JavaTV, if I remember correctly.

          Rewriting the JavaTV code avoids any issues around licensing.

          Regards,

          Steve.
          • 2. Re: xletview: why not use sun's javaTV source code directly ?
            843851
            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