Archive for the 'Java' Category

A dream come true: AMF3 specs and BlazeDS

Friday, December 14th, 2007

This week were released:
AMF3 specification

Action Message Format (AMF) is a compact binary format that is used to
ActionScript object graphs. Once serialized an AMF encoded object graph
to persist and retrieve the public state of an application across sessions or
endpoints to communicate through the exchange of strongly typed data.

And Java-Remoting BlazeDS Beta

BlazeDS is the server-based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Adobe Flex and Adobe AIR applications for more responsive rich Internet application (RIA) experiences.

Previously available only as part of Adobe LiveCycle Data Services ES, Adobe is announcing its plans to contribute the proven BlazeDS technologies to the community under the LGPL v3. BlazeDS gives the rapidly growing Adobe developer community free access to the powerful remoting and messaging technologies developed by Adobe.

The source code will be available for download in early 2008.

In short: more AMF servers for free, other than RED5

Continuations are the new threads

Friday, June 1st, 2007

I've always thought that continuations are the right answer to many if no all the network-programming problems.

What are continuations?

A continuation represent the state of execution of a function: all the local variables and the instruction pointer (the last line executed).
(Update: At least: there can be many kind of continuations. Other than the local variables, it's possible to store the state of the entire thread/process/stack)

What are them used for?

You can interrupt the execution of a function and resume it later.
This can be useful to create "generators": iterators made simple.

A generator looks like this:

JavaScript:
  1. function next() {
  2.   for(x=0; x <arr.lenght; x++) {
  3.      yield arr[x];
  4.   }
  5. }

The function next return the next element in the arr array every time is called.

When you call the function you resume the continuation, so the execution will resume from the yield.
If you want to implement an iterator like that without generators you'll have to explicitly unroll the for loop.

The resulting code will be surely less readabe.
Like:

JavaScript:
  1. function next() {
  2.   if(this.current == null) this.current = 0;
  3.   this.current++;
  4.   if(this.current> arr.lenght) {
  5.      this.current = 0;
  6.      return null;
  7.   }
  8.   retrun arr[x];

This can get really worse for every non-trivial iterator (eg: tree traversal).

Another nice use of continuations is to generate cooperative threads.
They are different from standard threads because they can't be stopped, they should cooperatively stop.

For example you can do:

CODE:
  1. function process() {
  2.   sendConnectRequest();
  3.   yield;
  4.   if(!this.connected) return false;
  5.   sendLoginRequest();
  6.   yield;
  7.   sendMessage();
  8.   yield;
  9.   trace("msg received: " + this.response);
  10. }

The process function return the control to the calling function every time it has to do an asynchronous operation.
Without continuations you'll have to do:

CODE:
  1. function process(onComplete) {
  2.   connect(function (connected) {
  3.       sendLoginRequest( function(logged) {
  4.           sendMessage( function (response) {
  5.               trace("msg received: " + response);
  6.               onComplete();
  7.           }
  8.       }
  9.   }
  10. }

As you can see we have used closures in a Continuation Passing Style:
Every time you have to do an asynchronous operation, you'll have to pass a function (a callback) that will be called when the operation is done.

Without closures the code will look even worst, this is why recently there is a great buzz about closures in the java world.

But, what have in common continuations and threads?

A continuations-like style of programming (but without continuations) is possible only using threads.
However, threads are the heavier and most problematic way to handle the I/O waitings. (see: 10Kproblem)
You have not only to deal with concurrency problems with read/write variables, but you have to block an entire thread for every I/O operation.
A better way is to use asynchronous events, like in the last two example. But of the two, which one do you prefer?

If your answer is like mine, take a look to:

  • Jetty servlet engine, it support a limited form of one shot continuations: the function is re-executed from the beginning, what is restored is only the HTTP connection state.
  • RIFE continuations, it's a bytecode-level implementation in Java, these are real continuations
  • NarrativeJS, a precompiler that create a simple form of continuations in Javascript: using the -> operator the execution can be resumed from that point.
  • Update: Torsten Curdt suggest Javaflow, a continuation implementation that seems really interesting, he offers some tutorials on his blog too

Jetty scratched only the surface of what is possible with continuations, while with RIFE it's possible to develop highly concurrent servers using cooperative sessions instead of threads (some >10000 connections instead of 1000). See: Mina Java-NIO library, Perl POE, Mina-Mule.

A server that uses continuations, will allow the simple and linear programming style of blocking-synchronous operations while using non-blocking ones. With a huge increment in performance.

In the client side, the most interesting is NarrativeJs, that use an approach that can be adapted to every language:
it unroll loops and transform all local variables in object variables to generate his quasi-continuations.

JavaScript:
  1. function boo(){   
  2.   alert("start");
  3.   sleep->(30);
  4.   alert("end");
  5. }

became:

JavaScript:
  1. function boo(){var njf1=njen(this,arguments);nj:while(1){switch(njf1.cp){case 0:
  2. alert("start");njf1.pc(1,null,
  3. sleep,[30]);case 1:with(njf1)if((rv1=f.apply(c,a))==NJSUS){return fh;}
  4. alert("end");break nj;}}}

The code looks ugly but it is so to preserve line numbers.
With narrativeJs you can do complex animations in a simple, linear way:

JavaScript:
  1. waitForClick->(theButton);
  2. animate->(theButton, "left", 200, 1000, 20);
  3.            
  4. theButton.innerHTML = "go left";
  5.    
  6. // move the button to the left (again note the blocking operations)
  7. waitForClick->(theButton);
  8. animate->(theButton, "left", 0, 1000, 20);

or:

JavaScript:
  1. document.getElementById("myElem").innerHTML = fetch->("http://www.url.com/");

Really interesting now that Flash and Ajax are pushing asynchronous operations to the masses.
Will we say goodbye to events, and maybe to threads as we know now?

Simple java ftp upload and resize pics droplet & applet

Saturday, May 26th, 2007

Update3 (05 February 2008): now the applet doesn't upload empty folders
Update2 (04 February 2008): fixed a bug that prevented files with uppercase extension to be loaded
Update: all bug fixed, internationalized, run as as application and as an applet too

I've done a "droplet" that upload and resize pictures and folders with FTP.

Why?
Since I was looking for a simple and opensource "droplet" application, and I haven't found one.

The requisites was quite simple:

  • upload files of some Mbs
  • resize large pictures to speed upload
  • SIMPLE: use drag&drop
  • upload folders too

This is the result:
ftpApplet

Download applet/droplet + sources

To use it:

  1. Download the jar+html example
  2. open sample.html
  3. Drag image files and folders of pictures
  4. Upload

In net\madarco\lightview\UploadApplet\FtpParameters.properties (in the jar, use winrar to open it) you can configure the ftp parameters. Beware that the user&pass would be accessible in the .jar, so don't deploy this applet in a public area.
In the next releases (if there will be) I could implement an Http upload or prompt the user for the password.

This applet is released as Public Domain, use it as you will. In the jar you'll find the source. Hope you'll enjoy it.

Know bugs:

Can upload only once
Can't run as standalone application
Save always as Jpg (but accept gif and bmp too :P) Ok, we can live with that
Those bugs are easy to fix, eventually I'll do that, depending on my laziness done! :)

If you are interested in how is done, continue reading:

How to do a ftp droplet and applet that resizes images

The best(lazy) way to achieve the upload of large files and folders is to use ftp. For this I've used org.apache.commons.net.ftp classes. They are simple and well documented.

To start, see the FtpUploader class.
It basically iterate the files and folders specified in the swing tree component and upload them through the doUploadFile member

JAVA:
  1. this.ftp.connect(FtpParameters.getString("FtpUploader.host"));
  2. ... //Check if connected and authenticate
  3.  
  4. //Get all the files in the model:
  5. DefaultTreeModel model = (DefaultTreeModel)this.applet.jPhotosTree.getModel();
  6. Enumeration nodesEnum = root.children();
  7. while(nodesEnum.hasMoreElements()) {
  8.     this.doUploadFile(file);
  9. }

doUploadFile upload files from a stream, in this way we can monitor the progress:

JAVA:
  1. BufferedInputStream imgStream = this.resizer.resizeImage(file.getAbsolutePath());
  2. this.ftp.setFileType(FTP.IMAGE_FILE_TYPE);
  3. OutputStream outputStream = this.ftp.storeFileStream(file.getName());
  4. ... //Write and monitor progress

The resizeImage method of the JpgResizer class do what his name says:

JAVA:
  1. Image image = Toolkit.getDefaultToolkit().getImage(imageFile);
  2. //Wait for the image to load:
  3. MediaTracker mediaTracker = new MediaTracker(new Container());
  4. mediaTracker.addImage(image, 0);
  5. mediaTracker.waitForID(0);
  6.  
  7. ... //Calculate thumb size
  8. ... //Resize image
  9.  
  10. //Save as jpg:
  11. File file = File.createTempFile("uploadApplet", "img");
  12.                   FileOutputStream(file));
  13. JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(out);
  14. ... //Set jpg quality
  15. encoder.encode(thumbImage);
  16. out.close();
  17.  
  18. return new BufferedInputStream(new FileInputStream(file));

For the drag&drop code see DropFilesHandler class, in the drop method you can find the code that get the file name dropped.

Simple, isn't it?

To run it as an applet, you'll have to sign it. This is a good guide.
In short:

CODE:
  1. keytool.exe -genkey -storepass %jarsignerpassword -keyalg DSA -alias madarcoftpapplet -dname "CN=madarco.net, OU=Java Code, O=Madarco, L=Italy, ST=Italy, C=IT, MAILADDRESS=ftpapplet@madarco.it DC=ftpapplet, DC=com" -validity 999
  2.  
  3. keytool.exe -export  -storepass %madapass -alias madarcoftpapplet -rfc -file ftpapplet.cer
  4.  
  5. jarsigner ftpApplet.jar madarcoftpapplet

The code is really quick&dirty, however, even if there are many things that can be improved, this can be used as a base to implement your own droplet.

My two cents on Static Typing

Wednesday, May 16th, 2007

While I was wondering if using haXe or Java with my server, I've stumbled upon some discussion on Static Typing (Java) vs. Dynamic Typing (Ruby, Php).
In a really interesting blog post (read the comments too) I found this touching phrase:

"Static typing is Communist Bureaucracy".

In short: since we (should) have pervasive testing, Static Typing is only more testing. However, a comment is enlighting:

I'm finding this logic hard to follow. Testing is good, coverage is good. Static typing is, among other things, a way to have the compiler test your code for type issues. Since we like testing, this makes static typing good, right?

But Static Typing not only prevent you to do mistakes, like typos, it allows your IDE to know what you are doing:

Dynamic Static Typing speeds up development because there is physically less to type since ctrl+space and ctrl+2 write the declarations for you.

Its seems obvious to me that Dynamic Typing is worth the catch only for a quick start or for learning.
Since almost all of the dynamically typed languages (like Actionscript, Perl, Php) have migrated to some kind of Static Typing (eg: Type Inference), there should be a reason.

Periodically, a new Dynamically Typed language spawn, attracting junior/tired programmers with the mirage of the simplicity and the less-to-type-ing, riding the hype until his young audience grows and start doing large projects hoping not to call a function with the wrong arguments.

Only then they realize the big truth: Static Typing is just more informations in the source code.
And more information means less wondering-what-object-was or what-was-the-method-name-and-parameters or who-instantiate-this-object, not to mention static analysis.

And hey, they have invented Javadoc-like documentation and Annotations just to add some more information, why remove one of the most important?

Bruce Eckel on Flash

Sunday, February 18th, 2007

Here a great post of Bruce Eckel (author of "Thinking in..." books) on Java, Ajax and surprisingly: Flash.

So here’s my question. Allow for a moment the possibility that, after 10 years, Java is not going to take over the world of RIAs. Further allow that Ajax is just “how JavaScript was supposed to work in the first place,” but that the limitations imposed by browsers, HTML and CSS committees seem unlikely to let it expand beyond its current bounds. What are we going to use to build RIAs? [...] The only obvious solution is Flash.

Simon Brocklehurst pointed out that there are more ugly Flash interfaces than good ones, although I think he is talking about the old do-all-by-yourself hackery of Flash 7-8 since there isn't many Flex 2 web apps out there yet. I wonder if he saw Picnik.

Eckel highlight a really interesting point: to use Flash as a domain specific language. Do in Flash the interface for your Java/Python/C application. We are waiting for you, Apollo.

RICOH European Contest

Wednesday, July 13th, 2005

I've participated at this contest organized by Ricoh Europe. It was the first european contest in the embed market. The goal was to develop an embedded application for one of Ricoh's Printer/Copier/Fax. It wasn't MIDP, but a CDC+FP profile with some extra. I've won the university contest in the "Business" category with my application MadaPrint.
It is a document repository that run on a Aficio Java-Enabled printer. With MadaPrint is possible to share documents and print other's. It is managed by a web interface that run on tomcat 3 (the machine has an ethernet interface) and a java Xlet that run on the printer's LCD.
This experience in the embed world was really interesting, hope will be another contest next year.

You can download the source code and jar here and the presentation document of MadaPrint.
Oh, it is released under the GPL.

Server side:

Xlet: