Thursday May 07, 2009

Movie Review: Star Trek

Star Trek, that name has been with us for more than four decades now and it carries with it a heavy baggage, some of it bad or even painful, but most of it good and uplifting.

I won't bore you with a long, and detailed, history of the many forms this series eventually took. I'll only point out that, except for a couple of exceptions, the movies were far from the strongest point of the brand. Even the good ones ("Wrath of Kahn" and "First contact") were hardly perfect and any movie lover would snicker at the mere concept of comparing them to real cinematic achievements (I'm not even talking about "Citizen Kane" or "The Godfather" here, but more in the line of "Raiders of the Lost Ark" or "Robocop"). Actually, the funny thing is that if you had asked me which Star Trek movie I liked the most I would probably have answered "Galaxy Quest". Which, I realize, is tantamount to blasphemous to any Star Trek fan.

All that preamble to say that when I learned they were doing a new Star Trek and that it was going to be a prequel, I shrugged and sighed. Let's face it, most prequels out there are flat out disasters. They're just a lazy way to exploit a franchise. So the idea of bringing back Kirk, Spock and the others, but younger, during a period anterior to the old series by a few years was certainly not appealing to me.

So it's fair to say that my expectations were rather low. That is until a few weeks ago when the trailer came out. I started to be intrigued. Then the early buzz from premieres and special shows was more than encouraging. All in all it managed to brink back a sparkle of anticipation in me.

So Yesterday I went to see Star Trek with two of my friends who are both familiar with, and could be considered fans  of, the Star Trek universe. We sat down, eager to be taken back to the final frontier.

We weren't disappointed. Actually, if you ask me, I think this is the best Star Trek movie of them all. Easily. That is good news for the fans, but it gets better: I do believe that even people who don't know anything about the series and previous movies will enjoy it too, they will miss many jokes and references but that should not deter from their enjoyment.

Kudos on the casting. The actors picked up to reprise the roles of the main parts are spot on. To the exception of Chris Pine who plays James T. Kirk, they all managed to bring the characters back to life. It's not that Chris Pine is doing a bad acting job. His performance is very good, it just didn't particularly remind me of William Shatner's Kirk. Not necessarly a bad thing by the way, as I never was very fond of Shatner's acting talents. It might be an issue for die hard trekkies however.

The script is rather good. Nothing earth shattering, but it works fairly well, specially considering that they manage at the same time to work around the issue of changing the canon (i.e. introducing events that were never mentioned before or even contradict previous installements of the franchise). The solution to that dilemna is hardly original, but at least it works.

This is an "origins" story. It tells how Kirk, Spock, McCoy, Scotty, Sulu, Uhura and Chekov met and ended up together on the bridge of the Enterprise. But the script manages to make this incidental to the main story arc, so the audience is never bogged down with exposition. Kudos to the screenwriters for that.

Good script: check. Good actors: check. What about the special effects? They're perfect, but nowadays this is hardly surprising. I want to commend the director and editor on the editing: for once they didn't feel like they had to edit this "MTV style" (you know, quick cuts every 3 second or so, so that you never know quite what's going on). The action sequences are well done, never overdrawn, and energetic.

If there is one aspect I felt disappointed with, it's the musical score. Obviously they made a point to stay clear of the "traditional" Star Trek music and themes. OK, we get it, this a "reboot",  but frankly, there is nothing memorable about the score. I know, I'm being picky, but to me there is nothing wrong with the old Star Trek music, and it would have worked here.

I'm guessing this will be a huge success and it's very, very likely we'll see more of this new "old" crew. And I, for one, am really looking forward to it and hope they'll manage to keep the same quality going forward.

Thursday April 09, 2009

More on cookies

As I mentioned in my previous post, JDK 6 introduced an extended cookie management API. The main class being java.net.CookieManager which extends the abstract class java.net.CookieHandler. It is supplemented by java.net.HttpCookie, java.net.CookieStore  and java.net.CookiePolicy.  Its main purpose is to provide a complete and easy to use cookie handler.

By default, for backward compatibility reasons, it is not set as the default CookieHandler but this tutorial provides a quick overview of its simplest usage: With a simple in-memory store (i.e. cookies are not kept beyond the session) and a simple policy (only accept cookies if its domain matches the one of the originating site).

What if you would like to keep the cookies between sessions or/and have a smarter filtering (with a white-list for instance)?

Well, you don't need to write your own CookieHandler for that, all you need to do is to provide your own implementations of the CookiePolicy and/or of the CookieStore.

 Implementing the CookiePolicy is really simple as all that is required is one method:

 public boolean shouldAccept(URI uri, HttpCookie cookie);

Just have it return true if you want to accept the cookie. That's where you'd check your white-list/black-list for instance.

CookieStore is a bit more complex. There are 6 methods to implement:

public void add(URI uri, HttpCookie cookie);
public List<HttpCookie> get(URI uri);
public List<HttpCookie> getCookies();
public List<URI> getURIs();
public boolean remove(URI uri, HttpCookie cookie);
public boolean removeAll();

I won't go into the details (see the javadoc for that) but most of them are pretty much self explicit and straightforward to implement. The only method worth mentioning is the second one on that list, get(), because when implementing it you are expected to enforce some rules, like not returning a cookie flagged "secure" if the URI's protocol isn't "https", or expired cookies.

If you're planning on implementing your own store, I'd recommend studying the code of the in-memory one we provide as part of the openJDK. The class is called sun.net.www.protocol.http.InMemoryCookieStore and therefore can be found in jdk/src/share/classes/sun/net/www/protocol/http.

Now that you have your own policy and/or store, all you need to do to make use of them is:

CookieHandler.setDefault(new CookieManager(myStore, myPolicy));

Because of this flexibility, the provided CookieManager should cover most needs. Only very advanced cases would require writing your own CookieHandler. One that comes to mind would be when more than one store is used, one for long persistent cookies and one for session-limited cookies, with the matching policies.

I hope you found this helpful.

Wednesday April 01, 2009

The trouble with Cookies

HTTP Cookie support was introduced in JDK 5 with the CookieHandler API, then significantly extended in JDK 6 with HttpCookie, CookieManager, CookiePolicy and CookieStore.

However a number of bugs (many due to the fact that the implementation followed the RFCs specs more closely than your average browser or server) and missing features made it less than perfect and somewhat of a pain to work with what is really out "there".

The good news is that these have been fixed in JDK 7 and I wanted to take some time to outline some of these.

First and foremost, CR 6644726 was a bucket for quite a few (7 to be exact) of these, including some domain matching problems. Also noticeable is CR 6641309 which deals with the separator used when sending multiple cookies in one header. CR 6641315 was about parsing expiration dates for Netscape style cookies. And CR 6790677 pointed out that unknown cookie attributes should be ignored instead of generating an error, while CR 6692802 added support for the HttpOnly attribute. Finally CR 6791927 complained about Locale issue when parsing expiration dates.

Now that all these bugs have been fixed, I have been able to test the Cookie API with various sites making heavy use of cookies (Google mail, Google maps, Yahoo, Amazon, etc...), so I'm confident we do have a reasonably functional cookie API in JDK 7.

In (near) future posts, I will give some code examples of its uses and go over some of tips and tricks.

Don't forget JavaOne is June 2nd - June 5th!

Monday March 16, 2009

HttpURLConnection and 100-Continue

According to RFC 2616 section 8.2.3 a client can use the 'Expect: 100-continue' request header to make sure the server will accept the 'PUT' or 'POST' operation before actually sending the request body. This is particularly useful when said body is of a significant size, like when uploading a file. Indeed, if the request is denied by the server for any reason, checking this before sending the body can save a lot of bandwidth.

Unfortunately, at the moment, the HTTP protocol handler doesn't implement this correctly. There is code that is basically here to ignore the 100-continue response if it is ever returned by the HTTP server.

CR #6726695 has been filed against this and I just wanted to post a quick note as to how we intend to fix this in JDK 7.

In a effort to limit bloat, instead of introducing a specific API (new methods typically) we're planning on using the existing setRequestProperty() method. Basically if the applications sets the "Expect: 100-Continue" header, then the protocol handler will wait for a 100-Continue response code.  When the application calls getOutputStream() it will throw a ProtocolException if the server rejected the request (i.e. returned something else than 100-Continue). A typical usage would be something like:

        URLConnection con = url.openConnection();
        HttpURLConnection http = (HttpURLConnection) con;
        http.setRequestMethod("POST");
        http.setRequestProperty("Expect", "100-Continue");
        http.setRequestProperty("Content-Type", "multipart/form-data; boundary=" + boundary);
        http.setDoOutput(true);
        int l = data.length() + (boundary.length()*2) + 14 + dispo.length() + ctype.length();
        http.setFixedLengthStreamingMode(l);
        OutputStream out = null;
        try {
            out = http.getOutputStream();
        } catch (ProtocolException e) {
            System.err.println("Server rejected the request. Code = " + http.getResponseCode());
            return;
        }

Note that getResponseCode() will provide the actual code returned.

IF 100-continue was received then the application can proceed providing the request body by writing to the OutputStream. The response code will then be updated with the one sent by the server after the POST (or PUT). Hopefully a 200-OK.

E.g (as a followup of code above):

        BufferedWriter outs = new BufferedWriter(new OutputStreamWriter(out));
        outs.write("--" + boundary + "\r\n");
        outs.write(dispo);
        outs.write(ctype);
        outs.write("\r\n");
        outs.write(data);
        outs.write("\r\n--" + boundary + "--\r\n");
        outs.flush();
        InputStream in = http.getInputStream();
        System.err.println("Response code is " + http.getResponseCode());
        BufferedReader ins = new BufferedReader(new InputStreamReader(in));
        String line = ins.readLine();
        while (line != null) {
            System.err.println(line);
            line = ins.readLine();
        }
        ins.close();
        outs.close();

Let me know what you think of this. Unless there are serious objections to this solution, I intend to push the fix into JDK 7 master in a week or two.

Thursday March 05, 2009

Movie review: Watchmen

Yesterday I went to see "Watchmen" the movie. I had been looking forward to it for quite a while. Actually, ever since I started to see some footage of it a year or so ago.

You see, I've read the graphic novel a really long time ago, back in the 80s (I know, dating myself here) and it blew me away. It was one of best comics (sorry, graphic novel) I ever had the chance to read. Not very original, I know, since it did that to millions of other readers. There have been talks of adapting it for the silver screen for years. Terry Gilliam worked on it. I followed all this closely. To me it seemed impossible to turn this into a movie and do it justice. I believed that of "V for Vendetta" (another great Alan Moore graphic novel)  and "The Lord of the Rings" as well.  As I'm sure you are aware, both of these have since been ported to the screen, one with spectacular success (I still remember how my jaw hit the floor the first time I saw "The fellowship of the ring"), and the other with mixed results.

Anyway, back to "Watchmen". Zack Snyder, the director, is a notorious fan of the books. Actually he even stated that he didn't think the movie could be done and he accepted the job only to make sure that no one would screw that one up. And it sure showed in all the early footage I saw. I got very excited waiting for the movie because every scene I saw in these previews seemed to come straight out of the book. Bottom line, I couldn't wait to see the end result, and went yesterday with fairly high expectations.

So, let's cut to the chase, was it any good? Let me put it this way: To me that movie is nothing short of a miracle! They did something I really believed to be impossible. The book is on the screen. Plain and simple. And I enjoyed every single minutes of it (all 163 of them). If you're a fan of the book, it's your dream come true, or as close to it as Hollywood could allow it. The characters and the visuals are perfect, straight out of the book despite an update of some costumes. The action scenes rock (although the level of gore here and there was a bit much, specially since it seemed rather gratuitous to me) and the dialogs are verbatim. Of course there are cuts, we knew that there is just too much material for a single movie, even a 3h one, but the core of the story is there, mostly intact.

Did I say "mostly"? Yes, because of the second fear that we all have when they make a movie out of one of our favorite books: changes! Hollywood doesn't seem to be able to leave a good story alone and always has to add its 2 cents. More often than not they do more damage than good, and the aforementioned "V for Vendetta" is a good example of that. In Watchmen there are a few minor changes and a major one. The minor ones are no big deal even if sometimes you can't help but wonder "why?". The major one affects the ending (I believe it has been the subject of many discussions already) and is a bit harder to swallow. It's not that bad in the sense that it does manage to keep the spirit and meaning intended by Alan Moore. And I vaguely understand what the film makers were trying to do. But still, I can't help but wonder why they couldn't keep the original one. Oh well, no biggie, the story still works. So if you've read and loved the book, go see that movie, and my guess is you'll be very happy you did.

But what if you don't know anything about the book? That's a toughy. Maybe you should start by reading it? Seriously, that's not a bad idea. First because it is a great graphic novel and it's really worth reading. Second, because I do believe it is very hard to understand what's going on based on the movie alone. The story is so complex, there are so many characters, most of them with 2 identities (super-hero business, you know). So many back stories, so many relationships that the movie had to skim over a lot of that and assume later that you did get everything and remember everything. I went with my girlfriend who had no prior knowledge of the book, and I had to clarify quite a few things during the movie. Also, she didn't enjoy the movie that much, in part because of the gore and overall grimness of the story, but also because of all the confusion.

There are quite a few key points and facts that are not made clear in the movie but are crucial to understanding the story. Careful, minor spoilers ahead. The Keen Act for instance is covered way too quickly, and most people won't understand why Night Owl retired and why Rorschach is wanted by the police. The fact that Dr Manahattan is named "Jon Osterman" is also not clearly established and that can make one of the key pieces of dialog at the end rather puzzling. The fact that there were 2 Night Owls and 2 Silk Spectres could have been more clearly explained, specially considering how crucial one of these facts is to the story. Most of these problems are due to the fact that there just wasn't enough time to go over all the necessary backstories in enough details. And it is my hope that there will be an extended cut on DVD/Blu-Ray in the future as they did for The Lord of the rings. I'm guessing an extra 20 minutes or so would have helped tremenduously.

I'm really curious to hear more about this from people who had no prior knowledge of the book. I have a few friends whom I know will go see it and fit the profile, but feel free to tell me your own thoughts.

One last note before the conclusion: If you're old enough to remember the 80s, there are quite a lot of references in this movie, some of which are quite clever (see if you can spot the "1984" Apple commercial for instance). Same with the soundtrack, it is a real tribute to the era this book was written and, to me, was a perfect match.

Bottom line: A near perfect translation of the graphic novel IF (and that's a big if) you had read it (and loved it). Jury's still out if you haven't, but my feeling is that you'd find it a rather good but confusing movie.

Wednesday March 04, 2009

Webrev updated to version 23.18

I've uploaded version 23.18 of the webrev script to fix a potential security issue where username/password from the hgrc file could have appeared in the generated HTML. So I strongly recommend you use that new version.

Always a good idea to check the pages before posting them anywhere by the way.

Wednesday February 11, 2009

Webrev updated to version 23.17

I've updated the 'webrev' script to include some fixes and a new option (-u) to set the user name of creator. By default, that name is extracted from your global .hgrc file now (assuming you're using mercurial of course). If that fails then the script will use the 'id' command. Using the -u command will force the value, so no 'guessing' will take place.

You can get the webrev script from the usual place, and don't forget that there is a brief documentation for it.

 Feedback more than welcome.

Friday June 13, 2008

FTP client API updated

After the first round of feedback, I've updated the draft of the API to address most of the issues raised.

Among the more significant changes are:

• Use of a static create() method instead of a constructor to allow for future factories.
• Most setXXX() methods now return 'this' to allow for chaining. e.g.:
  ftpclient.setPassiveMode().setBinaryType();
• listFiles() now returns an Iterator, which is also a Closeable, instead of a List. This will make the handling of large directory more efficient.
  
• Passwords are now char arrays instead of Strings to allow memory wiping after usage.
• FtpFile has been extended to cover data returned by RFC 3659 MLSD command.

The javadoc has been updated and can be found at the same place than last time.

Keep the feedback coming.

Friday May 23, 2008

FTP client API for JDK7

Introduction

For quite a while now I have been working on RFE 4650689 (RFE: Java needs public API for FTP) which has finally been approved for JDK 7 (don't ask).

I figured it's about time I post a draft of the API we've been working on and get some feedback from the community.

First and foremost, you have to realize that we already have an FTP API (see my earlier blog entry on that front) and that the new one has to be compatible with it. We do not want two implementations of the FTP protocol (bloat is bad, Mmmmkay?), so the proposed FTP client has to be usable by the existing protocol handler sun.net.www.protocol.ftp.FtpURLConnection. This had an impact on the design. Basically, we started from the existing code (residing in sun.net.ftp.FtpClient) and extended that.

Supported features

The goal was to support as much as possible of the existing RFCs: 959, 2228, 2389, 2428, and 4217. Some of the features in these RFCs are, however, rather obsolete so we used our best judgment as to what to actually implement. Feel free to correct us if you are convinced we are missing an important part.

The most notable features gained from the new API are:

• Multiple transfers per session which was not possible with the URL, URLConnection model.
• Resume interrupted downloads.
• 'Smart' directory listing with pluggable parser.
  
• Directory manipulation: mkdir, rmdir, cd, cdup, pwd.
• SSL/ftps support, including an FTPS protocol handler to work with URL/URLConnection.
  

API

If you want more details, check the current draft of the javadoc. Be aware that there is no guarantee that this will be the final API, or even that this feature will make the final JDK 7 cut. It still has to go through the approval process.

Feedback is not only welcome, it is very encouraged. So if you have any remarks, or requests, please drop me a note or, even better, use the openjdk networking email alias.

Wednesday May 21, 2008

Indiana Jones and the kingdom of the crystal skull

I was not at Cannes for the world premiere, but I was able to attend the first show of the new Indiana Jones movie here in Geneva. This was last night at 0:01 am. I love going to these special shows. The atmosphere is so different, mostly because the audience is entirely made of fellow movie lovers (you have to be to go to a movie theater between midnight and 2am). I'll grant you that Geneva is probably the wrong place for that. No offense, but people here are certainly not as exuberant as they can be in Paris or California for instance. And that's putting it mildly. A good proof of that was that the theater was hardly full. Still, that was a good natured audience and one guy even brought his trumpet and played the Indiana Jone themes a couple of time. He was pretty good at it and was rewarded by a big cheer.

But enough about all that, let's talk about the movie now.

 Of course, as it has been said repeatedly, there is basically no way a 4th Indiana Jones movie can meet expectations after all these years. And, unfortunately, it, indeed, doesn't. If I had to compare it to the other 3, I'd say it's not nearly as good as the first and third, but probably on par with number 2 (The temple of Doom) which I always considered to be the weakest, by a large margin, of the 3. Actually, the failings of the new movie have a lot in common with those of Temple of Doom. More on that later.

 I will not give you a summary of the plot, except to say that the action takes place in the 50s, that the Russians have replaced the Nazis, and that the Amazon has replaced Egypt. There is plenty of action and a lot of fun, but, it's rather nonsensical most of the time. Indiana Jones movies have always been a bit over the top and that is actually a major part of the fun, but this time it's way, way over the top. Surviving a nuclear blast by hiding in a fridge kind of over the top (no, I'm not making that up). One of the results is that the chase sequences are overdrawn and a lot cheesier than they should be.

The script also has a few problems. For instance, at the beginning it looks like it's trying to make a political point (against the communist-witch-hunt of the time) even if it seemed a bit forced. But then, abruptly and for no apparent reason, that plot is just dropped. Plain and simple. Gone, forgotten. I did find that annoying.

An other, and much more important, problem is the the 'quest' itself. We just don't really care about it. Looking for the Lost Ark or the Holy Grail was intriguing, exciting. It was rooted deep in our psyche. Searching for clues as to where these precious artifacts might be was a major part of the fun in the previous movies. Here, not only the plot has no echo in our minds, except for an unconvincing link to ElDorado, but there is no archeology (even fake one) going on. That's where, I think, it fails in a similar way as Temple of Doom. The historical (or pseudo historical) aspect of Indiana Jones is just missing. To make matter worse there is no 'treasure hunt' with hidden clues and so on, to speak of. All they have to do is go back to a place where one of them has already been. Which is easy, since that person is with them all along. Not very exciting.

All that aside it's still a mostly fun movie to watch. And more importantly, the movie stays true to the spirit and mythos of Indiana Jones. To me that was like going to visit an old, and dear, friend I hadn't seen in years. Sure enough the party was not as fun as before and there were a couple of awkward moments. But I was glad to see him again, in a good shape. We had fun together and I, as many, left the theater with a smile on my face.

Monday March 03, 2008

Webrev script updated

A very quick update. 

I've updated the webrev script to include the following changes:

• Fixed a bug when a whole directory was removed.
• Added automatic branch detection for mercurial.
  

It is now up to version 23.10.

Keep the feedback coming.

 

Monday February 11, 2008

webrev for OpenJDK: A code-review generator

Introduction

Webrev is a tool that has been developed internally at Sun over the years to help in the process of code-reviewing. What it does is extract information from a workspace and generate HTML pages highlighting all the changes. In short: it lists all the files that have been changed and provides several views of the changes.

So, when a developer wants to have his changes reviewed, he runs webrev, checks the output, publish it on a website then sends the link to potential reviewers. This has the advantage of providing a simple and common format for such reviews, which optimizes the time spent on them.

However it is tightly dependent on the Source Control Management System used, in our case, teamware (also known as codemanager).

With the advent of OpenJDK and the switch to Mercurial (hg) as a SCMS, it became necessary to update webrev to support the new environment. I foolishly (very foolishly) volunteered for the task.

To make a long story short, I looked at what the OpenSolaris folks were doing with webrev, since they also were on the process of switching to mercurial, but it turned out we had some divergent needs and constraints. The critical list being: OpenJDK needs a multi-platform tool and support for the mercurial forest extension. So, I forked the project and started 'fixing' webrev according to our needs. I thought it wouldn't take me too long (did I mention I was a bit foolish).

Anyway, it, of course, took much longer than any of us expected (partially thanks to a moving target), but with the help of all the hapless Sun's engineers who (sometimes unknowingly) tested the various versions for me, we now have a reasonable version of webrev. By reasonable I mean:

• Continued support for teamware (we still use it, you know)
• Support for mercurial
• Support for the forest extension
• Runs on Solaris, Linux, MacOS X and Windows (under the Cygwin environment)

So, how does it work?

The simplest way is to make changes in your workspace, cd to the top level directory and type 'webrev':

$ webrev
   SCM detected: mercurial

 No outgoing, perhaps you haven't commited.
      Workspace: /home/guest/MyWS
      Output to: /home/guest/MyWS/webrev
   Output Files:
        File1
                 patch cdiffs udiffs sdiffs frames old new
        File2
                 patch old
     index.html: Done.
Output to: /home/guest/MyWS/webrev
$

And voila! You have a subdirectory named webrev (as well as a zip file of it for easy transfer) which contains all the HTML pages needed for a code review.

Of course there are a bunch of options that let you specify, for instance, where to put the webrev, where the workspace is, which version to compare against. I've put together a small documentation page where you'll find the details on that.

Requirements

You will need a few other (rather standard) tools in your path for webrev to run:

• Korn Shell (aka ksh): this is a shell script that relies on a few Korn Shell idioms. It also expects to find it at /bin/ksh. Of course you can edit the first line of the script to change its location.
• awk (or gawk or nawk)
• perl
• jar
• zip

There is a bit of sanity checking done at the start, so it will most likely tell you if anything is missing

Grab it here

So now, just get your copy of webrev, give it a spin, and feel free to send me feedback and bug reports.

Thursday May 24, 2007

Pirates of the Caribbean: At World's End

Another day, another sequel (sequel of a sequel actually). Again it was released in Europe a few days before the US, which always make me snicker a bit (Hey, I do remember a time when I had to wait months after its US release for a movie to show up in theaters in Paris where I grew up. So I think it's fair enough).

Anyway, my expectations for that one where actually pretty low this time. The first "Pirates" took me totally by surprise (talk about low expectations when I went to see it!) and was a total blast. It was up there with Shrek when it comes to movies that surprised the heck out of me at the time. But the second installment widely reported flaws seriously dampened my enthusiasm. While there was some fun to have, most of the magic was gone. There were a number of reasons for that, and I'll come back to it later since it is relevant to the 3rd episode.

A funny thing happened while we were waiting to enter the theater (which was hardly full by the way): One of my friend who couldn't remember the previous episode asked me to refresh her memory. Turns out I failed miserably at it. The story was so confused and so uninteresting that it dragged down all my efforts to tell it (you try it! You'll see I'm not kidding). It also proved, to me at least, that I didn't really care about what would happen to the various characters of the movie. Low expectations, I'm telling you.

So, how bad is it? Let's see. The movie is about 2h45 long, and, if you ask me, that's about 1h too long. Seriously! The first 1h30 to 2h of it just drag forever. It's tedious, it's boring, it feels like it will never end! The good news is that it DOES end and the last 45' or so are fun to watch. The bad news is that it's not quite worth it.

And we have the usual suspects to blame for that misfire. First, and as way too often, the script. No real surprise since this 3rd part was shot back to back after the 2nd one, so there were very little chance the writing would have improved. The story is a confusing mess that doesn't make sense most of the time. I know it's fantasy, but come on! Is it too much to ask that the characters make sense within their world? That their motivation are believable? That their relationships seem to work? Because we have none of that here. Make us care for what what happens to them!

The second strike, for me, is Elizabeth, the character played by Kiera Knightley. It was obviously shoe-horned in there to give her a bigger part. In the first one, she was the archetypal "damsel in distress". She wasn't a very good one (missing charm and charisma if you ask me) but that didn't matter much. But now, she's been promoted to swashbuckling, ass-kicking, killing machine, and I'm sorry, but that doesn't make any sense at all. Plus she's not one bit convincing about it. To make matter worse, her relationship with Will (Orlando Bloom), which wasn't really hot stuff to begin with, is so flat, so unemotional, that when they do finally express their love to each other (they spend the first 3/4 of the movie ignoring each other) you're quite surprised. Everything about her is forced and feels fake. It doesn't help, of course, that she doesn't seem to be a very good actress either. At least not in these 3 movies, if you ask me.

Third strike, and I'll stop there, is that the humor that made the first one such a fun experience, is mostly gone. Oh, sure, Johnny Depp do have a few funny scenes and some good lines. His scene with Keith Richards, for instance, is genuinely funny and perfect for the character he created. But that doesn't save the movie.

A couple of quickies:

The special effects are worth mentioning for two reasons: they're perfect and they're probably why the movie falls apart. As is typical with Hollywood lately, too much focus on eye candy, not enough on story and characters.

There is an extra scene after the end credits. But considering they do last for a long time (8 to 9' I believe), it may not be worth waiting for it. If you don't have the patience, be assured you're not missing much.

Next sequel of a Sequel: Shrek the third, which hasn't been released in Europe yet (there is some karma for you). Somehow I suspect the trend of this summer will continue. We'll see soon enough. Not holding my breath though.

Wednesday May 09, 2007

Cross Platform Networking

So, you want to contribute to the openJDK networking library? Let me tell you: We (as in the current team working on it) are very glad you do, and I mean that. There is a lot of work to be done, and we definitely could use a little help. There are a few things you should know before heading down that road though. You see, as you probably already know, having a consistent behavior across all the supported platform is one of the main design goals of Java. But I need to let you in a little secret: cross-platform networking is hard, very hard, to achieve. Why is that so do, you ask? After all network protocols and APIs are well specified in RFCs and other standardization documents. After all, a socket is a socket, ain't it?

You wish!

And, actually, so do I! That would make my job so much easier! But there are a few problems with that assumption. First, RFCs are not always as ironclad as we would wish and can leave room to interpretation. One example of that is what happens with IPv4 multicast addresses in IPv6. The RFCs specify that an IPv6 socket has to support Ipv4 addresses for backward compatibility in the form of a special kind of IPv6 addresses (known as Ipv4-Compatible). This makes it possible to use a single IPv6 socket to talk to both world, the old Ipv4 one and the bold new IPv6 universe. Only problem with that is that the RFCs do not state clearly whether this should work for joining IPv4 multicast groups as well. So, Lo and Behold, guess what happens? On some systems it does work while on others it's not supported and, of course, they don't consider it a bug! I let you imagine the hoops we had to go through to get a consistent behavior here.

Then there are the unfortunate cases where the standard specifications are blatantly ignored for whatever reasons (don't ask, trust me on that one, you really don't want to know). An example of that would be the checksum field in the ICMP header which is supposed to be computed and set by the OS network layer before sending the packet. However some implementations of the TCP/IP stack leave that responsibility to the application layer. But, to be able to compute that checksum, the application needs to know what the source address will be in that header, which is not always readily available at that point, specially on machines with multiple network interfaces.

Another frequent issue is when we're asked to provide support for features that exist on some system and not others. A good example of these are the “Unix Domain” sockets (see RFE 4145756).

So, how do we deal with all that? We go through a succession of tough choices. For instance, the Unix Domain Sockets, while we think it does provide a somewhat valuable service, it is also a bit redundant with normal sockets, and, of course, it's not available everywhere. In that particular case, we decided that the cons were out-weighting the pros and voted against implementing it for the moment. But let's assume for a minute that we still wanted to do it at that point, we then would have to design an API that would not break if the feature was not available. And no, throwing an Exception when trying to create a Unix Domain socket on Windows, for instance, is not the right answer. So we would go to a “Service Provider Interface” (aka SPI), meaning the application would have to request the “service”, Unix Domain Sockets here, and, IF that service is available, get a reference to a “factory” in charge of creating these sockets (note: that's not the only approach to solve that kind of issue, but it's a rather common one). The end result is that it is now the responsibility of the application to deal with availability, or non-availability, of the feature, and, of course, it makes the code much more complex. What happens when the application absolutely rely on such a feature and it is not available? It has no option but to exit, stating something like “Sorry but this application can't run on your system...”. Which is a rather harsh blow against the “Run Anywhere” mantra. That's why we always think twice, or three, or four times, before going down that road. Specially when it comes to something as core as the Networking Stack.

In other, more minor,cases, like with certain socket options, we do actually word the documentation in a way that clearly states that this may be ignored, or re-interpreted, by the OS specific implementation. A perfect example of that is the documentation of Socket.setTrafficClass(int). Naturally, that approach also has its problems, and it's not rare that developers contact us, complaining about the fact that one of these methods seems to have no effect in their application.

I hope that by now you have a better idea of what kind of difficulties we have to deal with. But don't let that stop you working on your project, we'll be here to offer help and advice when you'll ask for them.

That's it for now. In a future post, I'll outline what we're currently working on.

Thursday May 03, 2007

Spider-man 3

And now for something absolutely non Java related....

Yesterday, with a few friends, we went to our local multiplex to watch the newly released Spider-Man 3 (Imagine that: it was released in Europe a few days before the US!). Quick background: As a teenager I grew up with Spidey and, like many at that time, I felt quite close to that nerdy Peter Parker. I also thoroughly, after years and years of waiting, enjoyed the first two movies. They succeeded in doing something pretty damn hard: updating a material from the 60s while staying faithful to its spirit and core appeal.

But that was then, let's see what we have now.

When the movie opens, everything is peachy in Peter Parker's life! Did I say peachy? Scratch that! He's pretty much on top of the world: He's sailing through his classes, the woman he's been dreaming about all his (admittedly short) life is absolutely crazy about him, and everybody, and I mean absolutely everybody, in town think his hooded alter-ego is the best thing that ever happened to the city that never sleeps. They're even going to give him the keys to the city, for crying out loud. The only shadow to that sunny picture is the fact that his best friend, Harry Osborne, is still mad at him because he believes Spider-Man killed his father. The nerves of some people! Meanwhile, Mary-Jane's life is going down the crapper because she got bad reviews to her latest Broadway production (yea, I know, don't get me started). At that point, if you have seen Spider-Man 2 you may think "Hey, this is the exact opposite situation as in the previous movie. How clever of them!". Well, not that clever if you ask me. You see, one of the major part of the character from the comics book and from the previous movies is that being Spider-Man is a curse to Peter. This is his cross to bear and what makes him so special. So, now, he's just another "man of steel". Booooring! The worst part is that it goes downhill from there.

There are many problems with that movie, the first one, as way too often, is the script. There is no focus whatsoever in that mess of a story. You have 3 villains, none of them remotely interesting or even developed, then you have a very poorly developed love triangle (actually 2 love triangles, a mess I'm telling you) and, to top it all, the return of the "dark side" (you know, the one that is so tempting, so easy to follow). And none of that works.

Second problem, the pace. That movie is way too slow and way too long. They could have cut 30 minutes of it without any problem. I'm quite surprised here, because until now Sam Raimi had a rather good track record on that front. Well, I guess there is a first time for everything. My 3 friends were as bored as I was during the whole movie. not good!

If all that wasn't bad enough, the acting is really sub-par here. I know, it's not a movie where you'd expect great performances, but the last two episodes provided some more than decent ones. Here, my best memory when it comes to acting, is Bruce Campbell doing an hilarious John Cleese imitation in the part of a French Maitre'D (I know it sounds ridiculous, but it works). All the main actors are going through the motions without delivering. The worst offender, to me, is Tobey Maguire during his "I'm bad!" stint. It was embarrassing to watch.

I could go on with a few minor things that annoyed the hell out of me, like the fact that the masks and hoods keep being removed and put back for no good reason and sometimes with a blatant disregard to continuity, not to mention any attempt at credibility. But I think you got the point. The 3 major flaws I mentioned above would kill any movie, so there is no real point punching more holes in that fast sinking boat.

Well, that was a disappointment. But I guess they had to adhere to the Hollywood law that says that in any trilogy, one of the episodes must be stinking bad. Mission accomplished, then.