Java and front end - day to day work

05 novembre 2009

Slaping Sun microsystem's face : a good relief

Sun_slap


Today I had a job interview.
Those kind of meeting where you just must be good.

After half an hour, I felt the interview was going allright.
I was a front-end good java guy and the 2 women in front of me, were kind of ready to take this for granted.
And then they asked me to show some work I did on the Internet.

- No problem I type the url http://free-visit.net on one of their computer. This page where I have my wonderfull 3D visit demo that I had tested last week on 20 different computers and that would run fine in any window XP or Vista.
In short an very well tested Applet.

- First thing .... It asks to install a more recent java.... Oups shoot I think : No luck, she's got an old one.
Ok, she installs the java jvm (1.6 update 17 I think). The install operation is still quite ugly (it's sun software) but it was surprisingly quick. Releaf.
- After this I just keep looking at her screen to see my nice Applet show up. My heart was going nuts.
- Arg !!!!!!! Error : I got this awfull small red cross on the upper left side of the applet space.
I could feell my swet over my back.

- So I just pressed the F5 button to refresh the web page ... hoping everything would go nice again with my applet.
- Error again : Still this fucked red cross.
My Applet never made it on her PC.

Sun people sometimes I just hate you. Really.
Ok perhaps she had a "special" windows XP version.
Perhaps I had no luck because this "happens only in 0.00001% of the tested environments".

But damit, why Adobe-flash Player just runs almost anywhere in any windows PC's.

When I think you Sun microsystem people have been working on improving the JVM experience since 2 years and this awfull things still happen to an heavylly tested Applet, I just feel I have a right slap your face.

Virtually of course, but boy do some people at Sun do deserve this slap.

Posté par tmilard à 01:57 - Commentaires [1] - Permalien [#]


28 octobre 2009

I have spend so, many days trying to have my applet work on all windows.
I don't even dare trying to make it work on Mac.
But the least I can say is that the JNLP really debugging process is really not a pleasure.
JNLP debugging messages really looks like the debugging tool of the 90's begining).
Want I see all those engeneers at Sun-Oracle trying to (badly) copycat the iphone Application shop, while no-one is even working on improving JNLP publishing I just get really angry.

Nevertheless I won't talkToday about this because I am not qualified. I will talk about something I lost my morningon. Is it a bug ? I don't know but it should be from my point of Vue.

Ok let's start. You have a wonderfull Applet. Very pround if. For sure you made it !
Now suppose you have two parts in your JNLP file:
1) One part is "special" I mean my applet can have different "personnalities". For each there is a specific jar to be loaded.

2) One part is constant. Allways the same.
It Just calls :
- others JNLP from sun
- or others and others local jars
- and the java with 10 parameters.

So I made 2 jnlps. the main one is suppose to be short and containing specific things. there can be hundred of those. the other is buried on my server and has only one instance.

1) The main jnlp : Berlin_HH.jnlp containing specific things and is <applet-desc>.
It calls the jnlp thath is always the same : free-visit.jnlp

Berlin_HH.jnlp :
<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="Berlin_HH.jnlp">
  <information>       ........   </information>
  <resources>
       <extension href="http://www.free-visit.net/fv_exec/player/free-visit.jnlp"/>
  </resources>

  <applet-desc name="BerlinHH" main-class="player3d.LaVisitePlayerApplet" width="1" height="1">
    <param name="dataPath" value="http://www.free-visit.com/users/tmilard/vis/Hackesche_Hofe.vis"/>
  </jnlp>


2) The constant one : free-visit.jnlp containing the list of jars and java parameters  is a <component-desc /> JNLP.

It calls the jnlp thath is always the same : free-visit.jnlp

free-visit.jnlp :
<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="free-visit.jnlp">
  <information> ...  </information>
    <!-- =========================== --> 
  <resources>
    <java version="1.6.0_12+" href="http://java.sun.com/products/autodl/j2se" java-vm-args="-Djava.security.manager -Xms350m -Xmx1024m -Dj3d.rend=d3d -Dj3d.optimizeForSpace=true -Dsun.java2d.d3d=false -Dsun.java2d.ddoffscreen=false -Dsun.java2d.noddraw=true -Dj3d.audiodevice=org.jdesktop.j3d.audioengines.joal.JOALMixer"/>

    <!--  a) free-visit player -->
    <jar href="http://www.free-visit.net/fv_exec/player/LaVisPlayer-signed.jar" main="true" download="eager"/>
    <!--  b) java3D API -->
    <jar href="http://www.xxxx/xxxx/xx.jar" download="eager"/>
    <jar href="http://www.yyyy/yyyy/yy.jar" download="eager"/>
    <jar href="http://www.zzz/zzzzz/zz.jar" download="eager"/>
    <!--  and 15 others -->
    <jar href="http://kakaka.cpm/kakakakakka/ka.jar" download="eager"/>      
xec/player/starfireExt-signed.jar" download="eager"-->
  </resources>
    <!-- =========================== --> 
<component-desc />
  </jnlp>

  • - Smart programming ! No ?

The main jnlp tells free-visit.jnlp to bring him the jars and also the java+jvl-parameters.
I calls this a cool simplification of my application : This way,
Berlin_HH.jnlp my main jnlp file stays simple.

  • - So what is wrong with this ?

- For the jar, cool. I can really put in the second jnlp file (  ) all the jars.
- The problem concern the java-and-jvm-parameters. It seems it is forbuden. It looks like Sun engeneers have build the JNLP potato-jam that forbid this line in a <component-desc /> JNLP file.

This line cannot be put in free-visit.jnlp :
<java version="1.6.0_12+" href="http://java.sun.com/products/autodl/j2se" java-vm-args="-Djava.security.manager -Xms350m -Xmx1024m -Dj3d.rend=d3d -Dj3d.optimizeForSpace=true -Dsun.java2d.d3d=false -Dsun.java2d.ddoffscreen=false -Dsun.java2d.noddraw=true -Dj3d.audiodevice=org.jdesktop.j3d.audioengines.joal.JOALMixer"/>

Therefore I have to put this line back in may Berlin_HH.jnlp (main file, with <applet-desc> tag ).
Therefore doubling the lengh of my main JNLP file. And this is an issue for me as I wanted to keep is as small-and-simple as I could.

Is it a problem ?

Sun  engenneers I think your decision to have delegates JNLP files is good. <applet-desc> callings <component-desc /> is brilliant.
Looks a bit like cascade procedural programming I did using Pascal langage (I loved this langage by the way).
This works for jar files. Good.
So why on earth did you forbid it for java-and-jvm-parameters ?
Maybe there is somethong I do not know. Please do tell me.

Posté par tmilard à 17:31 - Commentaires [0] - Permalien [#]
Tags :

28 juillet 2009

JNLP debugging is more than painfull

   

If you want to be part of the Front end web story you can do 3 things:
- javascript
- Flash (AS3)
- java as an Applet

The issue I will be talking here is to go from :

° point A [your program runs well on your development tool]

to

° point B [your program runs inside a cool web page].

And what I thought would be easy can be quite long and painfull task.


Of course I won't be talking about javascript and flash experience but on the java experience.

Java on the web : Doing it the "java Web Start" (JWS) way :

http://www.kabatology.com/wp-content/uploads/2008/09/MozSwing.png

- Sun has a "invented" a few years back a XML file with "JNLP" script that do only one thing :
describing your program and the jar you are using.
When you have published a JNLP file, of course things never goes right on the first shot. And this is just normal since you do not use JNLP file on a daily basic.

So here you go you have a jnlp file like this and you call it from a html file.
Of course badaboooooom ! Nothing works at first.

JNLP interpretor output you have to guess a lot: .

If you think you would look into the console and find easeally the line where you blow it up, you just have it wrong.
For example here my JNLP file has a commentary that is false.


The only line that is false is this one :

// a) java files of java3D API

I should have written this : <!-- a) java files of java3D API -->

Now, when you run this jnlp/ JWS file one would think the "Sun JNLP interpretor" would just say someting like : "Error this line (line n° nn) is not a JNLP correct line : // a) java files of java3D API"

No no no, what I always get from sun JNLP interpretor output is just nonsense.

  • A) the ouput is 4 pages long but 99% is just reapeatating my JNLP file 3 times at least.
  • B) the interpretor just never says "Hey guy there is mistake in your JNLP file". No it would be too simple just to say that. No, Sun people just suppose your wishdom will foresee you made a mistake. Thanks guys !
  • C) The only things you get is that when sun runs the java Applet ... that there is a class missing :

basic: JNLP2ClassLoader.findClass: javax.media.j3d.Node: try again ..
basic: exception : null.
java.lang.NullPointerException
    at sun.plugin2.applet.Plugin2Manager.findAppletJDKLevel(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Exception : java.lang.NullPointerException

How many minutes  hours days have you got to understand this simple simple jnlp line is wrong ?

I recall the line :

// a) java files of java3D API

It took me 7 full evenings. I am not ashame, I say sun did a really bad unpolish job here. First you have to figure out yourself that if you get this java bug ... it is because one java3d jar is not availlable (but which one by the way ? Perhaps Sun guys when you use a bunch of jars you are not aware where exactly each java class are ...  ). And then when you suppose there is a missing jar (the interpretor I recall do not say that) , you read the line importing the jar .... and you find everything is correct.

Then it took me perhaps 2 more evening to understand that it was the line just "BEFORE" that was wrong.

Let's just take a look at my 4 lines of JNLP :

     // a) java files of java3D API
    <jar href="http://www.free-visit.com/exec/player/j3d-1_5_2-windows-i586/j3dutils-signed.jar" download="eager"/>
    <jar href="http://www.free-visit.com/exec/player/j3d-1_5_2-windows-i586/vecmath-signed.jar" download="eager"/>
    <jar href="http://www.free-visit.com/exec/player/j3d-1_5_2-windows-i586/j3dcore-signed.jar" download="eager"/>

The Sun superbe jnlp interpretor reads from up to bottom. So it reads this line:

// a) java files of java3D API

And it just fails. So the JNLP interpretor stops : I won't go to the lines below. So of course  none of the j3dutils-signed.jar , vecmath-signed.jar and j3dcore-signed.jar are loaded. Ah if only there were a line in the console saying

"Line number NN :'// a) java files of java3D API'   is incorrect : Stoping HERE JNLP loading.


This leeds to a  few simple things Sun-Oracle could improve  I think  :

1) Sun-Oracle ingeneers, if your JNLP parser sees a mistake in the jnlp file, why not just write it in the console ?

2) Sun-Oracle ingeneers, if your JNLP interpretor decides no to go further in the parsing process, why not write it down also ? A message like "jnlp interpretor stopped at line number nn" would be nice.

3) If your JWS/NLP interpretor has brutally stopped (because there is an error in jnlp file I recall) is it wyse to start the java program ? Let's just think 1 minute : the interpretor has only half loaded the jars .... so is there a point at running the programm with only half of the java classes loaded ? I think not. And even if it what a good decision, why not say "Starting java program, but some jars where not imported" or "Warning : Starting java but jnlp parser was not 100% done".



Conclusion :
So voila, I wrote it down. If the java web start parser was better polished it would be a matter of minutes or hours to debug JNLP files. Because the JNLP parser and error message cycle has never been really done (to my point of vue of course) I always end up when I web-publish my java program to needing days of horrible guessings.
Sun people could think "JNLP writing is not done everyday because you write it only once your java program is done". Good catch ! And this is indeed why this "Java Web Start" JWS/JNLP process must be SIMPLIFIED at the maximum :
Because as a developper I only use JNLP file twice a year, I will never ever ever really master all the specificity JNLP tags. And I believe no one on this planet does JNLP file as a daily basic.
This is perhaps why the JNLP debug process must be simplefied to its maximum.

I beleive to be a popular programing tool the tool has to be easy to use nice and simple. Sun guys are perhaps good at imaging many java developers are super-intelligent people. Alas, this thinking will never make a tool widelly use.
Let's think of it  this way : The super-intelligent developers are at sun. the rest are idiot like me that need simple tools that are good are simplefing my task. If Only Sun masterminds guys could understand this  ... simple facts I would win my day. and I could save my job by the way.

Posté par tmilard à 09:48 - Commentaires [0] - Permalien [#]

My first post --> java must be simpler

It is my first post. I just created the blog 5 minutes ago.

- Why did I created this blog on the first place ?

- Well .... Because I just things could be better in java front end development for Internet. a lot better.

Yes ! I know : Most people do Internet-front-end eather with Flash (so good looking !) or javascript (getting better but .... long way to go men).

When I tell Internet guys I do "java applet" they just stop and look at me as if I was a strange guy coming out of a rock cave.

- So yesn, let's say it : I want to write this blog for you guys. Hey Man, many things can be built in java. Perhaps it is a bit harder then javascript but man you can go much further then with javaScript.

- Second, I have a few griefs agaisnt Sun. I don't mean to harm those guys. Afterall java Front end have never had the audiance it should have had. But whose fault is it ? Java Swing, java2d Sound, 2D, 3D, applet deployement you name it are often too complicated. I sometime feel many things a 'Front end java developer" has to do on a standrd day basis are a bit too complicated. So many time I also feel it would be not such a great deal to improve it. Sun people need to polish things. They fail to gain developers heart because they just do not polish things enough. Polishing and simplifying the developer's task is the key to success.

Some improvment have been done recently (java update 10, 11, 14). Some huge mistakes also (not integrating javaFx script easelly into Swing ... ).

I want here, in this blog, to show some issues I have. Mosty of those issues can be summurized in just ONE word : simplicity. Yes Sun-Oracle people : Why do you think Adobe-flash-flex has gained Internet-front-end dev a huge part of the cake ? Because they wake up in the morning to SIMPLiFY the task of the average developper (or designer). Wich I am also.

What if Sun product could also take this into account .... I am sure the success in front end java/javaFx could rise up again very fast. why ? Because there are so many java API in this world. Some are great some superb. Most of them are just waiting for the java/javaFx tide to move up again.

So here in theis blog I will try to show some ugly things I think Sun-Oracle should improve. and also some good things. Depending on my mood.

So voila.

Posté par tmilard à 01:09 - Commentaires [3] - Permalien [#]