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.

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.

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.

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.

Tuesday March 27, 2007

Spring cleaning and FTP

With OpenJDK upon us I figured it's about time I dusted my blog and start posting again since I intend for it to be one of the sources of information and discussion concerning the evolution of the networking stack (more on that later).

Anyway, since it's a question that comes up quite often these days, it occurred to me that the state of FTP support in J2SE would be a good subject for jump starting my writing efforts. So, without further ado:

FTP support in J2SE

Let's get something out of the way first: Yes I'm fully (dare I say painfully) aware that the current FTP API is somewhat lacking, to say the least. There is an RFE filed against it, 4650689 to be exact . It has rather high vote count (119 last time I checked and is on the top 25 RFEs), and, believe me, it hasn't gone unnoticed. I have been pushing for that RFE for a long time now and I have hopes that it will finally get approved soon. When that happens (fingers crossed) I'll post here the details of what we intend to do. And I'd like to personally thank all and everyone of you who voted for it and/or posted comments. It does help. A lot. So thanks again.

Meanwhile, let's have a look at we already have.

FTP is one of the protocol handlers mandated for the URL API. Which means that, for the time being, the only public FTP API in J2SE is through the URL and URLConnection API. In short, it means that to access a file on an FTP server you create a URL as specified in RFC 1738, get a URLConnection out of it, then use getInputStream() or getOutputStream() to get or put, respectively, the document. Did I say 'put'? Yep, I sure did! How many of you did know that you can do puts as well as gets? <counting...> Really, that many? I'm surprised. So, how many now knew that you can also provide a user name and password? An absolute file path? Or a type (binary for instance) of transfer?

Yes you can do all that. Let's look at a quick example:

URL url = new URL(“ftp://user:password@host.dom/%2Fetc/motd;type=a”);
URLConnection conn = url.openConnection();
PrintWriter out = new PrintWriter(conn.getOutputStream());
out.println(“Message of the day”);
out.close();

And voila! You just logged to an FTP server using a user name and password, then wrote to the /etc/motd file by doing a PUT in ASCII mode.

The important things to notice here are:

• Calling getOutputStream() instead of getInputStream() will trigger a PUT operation instead of a GET.

• If you need to authenticate when logging onto the server, prefix the hostname with user:password@

• If you need to use an absolute path use %2F (code for a slash) at the start of the file path.

• If you need to specify a type of transfer (default is binary) add ';type=<a,i,d>' at the end of the URL. 'a' means ASCII, 'i' Image (or binary) and 'd' means directory.

I'd like to add that the FTP protocol handler will also automatically try to use passive mode when possible, knows about IPv6 extensions and will, if the URL points to a directory, give you a listing of its content.

So, I hope you can see now that you can do many FTP operations through the URL API.

Like I said earlier, I know that many features are missing, like being able to do more than one operation per session, or rename a file, or use FTP over SSL and so on and so forth. But hopefully, not for much longer.

Sunday July 11, 2004

java.net API & proxies

I got some interesting feedback from my last entry, and I may post an update, but I'd rather sleep on it a few more days, at least. Thanks to all those who took the time to comment. I appreciate it.

It is my intent to have technical entries in my blog, not just rants or movie reviews. So I figure it's about time I get to it. One thing that bugs me is how badly documented the Java Networking API is. A lot of the bug reports, or requests for new features, we are getting prove that. Many times the answer is "You can already do that using this API" or "This is not a bug, it is supposed to do that". Of course we, the Networking Team, are to blame for that, but as all developers know, documentation is hard to do and very time consuming. The good news is that we've taken steps to remedy that situation. In particular you'll see that, in J2SE 5.0, we've improved the javadoc entries quite a bit. But we're also working on some other means, like white papers and articles that, hopefuly, will end up on the web site.

And that's precisely what I want to discuss here, I have written such a white paper, on proxy management in the Java networking API and I'd like you to review my most recent draft and let me know what you think of it, particularly whether it's clear or complete enough.

Here is a quick overview of its content:

• System Properties: We first discuss all the system properties related to proxy settings, there a quite a lot of them, and how they affect each other.
• New APIs in 1.5.0:
  • java.net.Proxy class: We present the newly introduced Proxy class and how to use it in new methods for Socket and URLConnection
  • java.net.ProxySelector: We go deep into the new mechanism to let applications dynamically assign proxies to the different protocols. The class is described, and using a practical example, we do show how to implement such a selector.

So, if you are interested you can get the PDF file, read it and, I hope, send me feedback, either through this blog or directly via Email.

Also, there are two other subjects I'd like to solicit feedback: What part of the java networking API would like to see described next? (some possible candidates are: Cookie management, IPv6 support, timeouts, etc.). And, what is the networking feature/bug that you think should be implemented/fixed in the next release, and why is it so important to you?

Thanks in advance. (2004-07-11 07:49:33.0) Permalink

Thursday July 08, 2004

Sun and OpenSource: Old but estranged friends?

Something that really ticks me off lately is the whole "Sun vs OpenSource community" thing!

Really, it's ridiculous! It's like watching two very old friends having bitter arguments, while forgetting how much they owe each other, and how much they need each other. Both party are guilty here, if you ask me (and if you didn't ask, or don't care,then stop reading now).

Let's start with full disclosure: I have been involved with the Open Source Community long before it was even called that, back when it was still called "Free Software". Heck, I was one of the main contributors to one of the most notorious, and most enduring (17 years and counting), project. I also co-founded a small not-for-profit organization dedicated to Free Software, which later, much later, became the French branch of the Free Software Foundation. Although I have to admit, my participation was minimal, specially compared to the main guy behind it, Loic Dachary (Hi Loic, how you doing?). But I still ended having that guy as a guest in my place for 10 days, which was quite an experience, as those of you who ever met him may imagine, but that is another story (maybe another blog entry, who knows). Ever since, I have been, and continue to be, a vocal proponent of Free Software and Open Source.

On the other hand, I joined Sun Microsystems almost 10 years ago and I have been invovled with Java, one way or the other, since the beginning (1995 and JDK 1.0.2 if you can believe it). And for the past 4 years, I have been integral part of the Java Engineering team, here at Sun.

So, why this rather long, and I apologize for that, disclosure, to the risk of looking like I'm bragging? Because it shows pretty clearly where I come from and where I stand: I have one foot firmly on each side of the fence (and we all know how uncomfortable it can be, specially when said fence is getting taller with each passing day. Ouch!). The being said, it doesn't mean I'm not bragging too.

Now, back to the main point: Sun and the Open Source community. You know, I remember a time when Sun was so completely synonymous of Free Software that almost all Free Software, including the GNU project, the X11 project, and hundreds of others, were developed primarly on Sun's platform. It used to be that the default configuation to these softwares was for SunOS. There were a number of reasons for that, but more importantly, it benefited both sides. And that special relationship is one of the reasons I joined this company in the first place. Then things started to change, and that relationship got looser. If I do remember well, the first release of Solaris (or SunOS 5) was the trigger, for 2 main reasons: First, it was based on a commercial Unix (System V.4 to be exact) instead of BSD. Second, Sun stopped providing compilers for free with the OS (which, to this day, I still think was a major mistake, but that's just me). Since then, both parties have drifted even more apart. And nowadays, most Open Source projects are developed on Linux, to the point where, more and more often, I actually do have to do dome porting (and I do mean the "messing around with the source code" kind of porting) when I want to run some OSS applications on my Solaris box. The horror, the horror! Specially to a guy who fondly remembers the days when he just had to type 'make' and wait for the build to finish.

Now, when Scott McNealy claims, on stage at JavaOne last week, that no other company contributed as much as Sun to the Open Source idea, he is absolutely right! And I wish the community would remember that. After all, aren't they the same people who are big on giving credit when credit is due?

Of course, Sun, as a company, should also remember that it did benefit quite a lot from all the contributions to Open Source. For instance, the main user interface of Sun's products is based on X11, right? And all these sales to academia, among many institutions, were without any doubt helped by the knowledge that there was this huge pool of free software just asking to be run on Sun's hardware! It was, and still is, a two way street. Both side should have realized that a long time ago, don't you think?

Let's talk about OpenSourcing Java, which seems to be the main point of dissension these days. I, for one, would love to get some of the benefits of the Open Source modus operandi when it comes to Java. Particularly as one the developers working on it. I have wished so many times that we could use the "release early, release often" model, and I would love to get direct, or indirect, help (in the form of code, suggestions or discussions) from all these talented developers out there. Also, considering my background, I would love that out of principle

But you know what? It's not going to happen. And it's almost certainly better that way! I won't go over all the arguments again, as you're probably tired of hearing, or reading, about them. Except for the main one: Write Once Run Anywhere is the obvious decisive factor here. I have turned this all over my head many, many times, and I can't figure a way to keep that without a tight control. It's that simple.

Let me also state again, as many have before me, that nothing stops you from creating an fully OpenSource version of Java. At least, nothing in theory, since all specifications are completely open. But I do know that it is incredibly hard! Almost impossibly hard, because there is more to binary compatibility than following the specifications. A lot more. And Sun should acknowledge that.

Which brings me to this question: What can we do to bridge the gap between Sun and the OSS community? How can we get these two, somewhat, estranged friends to be in good terms again?

To the Open Source Community, I'd say: lay off Sun's back a little! And remember to give credit when credit is due for crying out loud!

To Sun, I'd suggest to find ways to make life easier to the OSS developers and distributors. Why can't we have a license that makes it possible to easily redistribute the JDK with every Linux distribution? Why can't we find a way to make it easier for the developers of Kaffe or GNU Classpath, for example, to test the conformity of their implementation? And overall to play nice and fair with the community.

To me it doesn't seem like it would take a lot of efforts to make all this happen. But I have been known, at least to my friends and relatives, to be somewhat of an utopian. But, you know, sometime utopies do happen.

So what do you say? How about being friends again?

Monday June 28, 2004

Java: your magic ticket to IPv6

A couple of weeks ago I was in L.A. attending the IPv6 Summit where I was scheduled to make a presentation about Java's support of IPv6. while there, listening to the other presenters I realized something. There is a gap, a disconnect, between application developers and the network infrastructure people. You see, very few attendees were developers, or ISVs, so it felt a bit like most presentations were "preaching to choir" so to speak. Most people in the room were convinced that not only IPv6 was important, but it was also inevitable. It will happen, and, actually it is happening. Many of them were actively involved in making it happen. So how come, when I talk to application developers, they don't seem to care one bit about IPv6 support? Even when their application is heavily networked.

I've been pondering that question for the past 2 weeks and I've come up with a few elements of answer.

First, and foremost, most developers don't know what IPv6 is all about, and when they do know a bit about it they seem to believe that we don't really need it, what with NAT (that's Network Address Translation in case you didn't know) and similar technologies. Second, to most of them, supporting IPv6 means "porting your application", like supporting a new platform that almost nobody is using. In today's market, it's like a death sentence. But it's also a catch 22 situation. You see, many ISPs says they're not deploying IPv6 because there is no demand for it (at least in the US), and there is no demand for it because there are no application for it either. We got a bit of a deadlock here. I'll get back to that later. First I want to address the first point.

Why do we need IPv6? I won't bore you here with all the technical reasons, you can read about it from a number of sources, including at the IPv6 summit website, in particular in the tutorial section, I'll just mention the main 4 ones:

• Address space
• auto-configuration
• end to end security
• mobility

The first one, of course, is the real kicker: with address length of 128 bits instead of 32, IPv6 makes it possible to assign an address to about any device ever conceived and still not run out of addresses. Couple that with auto-configuration and you won't have to worry about IP addresses ever again.

Now, I know what you're thinking: "NAT solved that problem already". Not quite so, for one thing NAT creates a lot of problems when it comes to end to end communication (think P2P for example), and already some organizations are running out of "private addresses" as defined in RFC 1918. Also, it is has been estimated that if the developing countries (China, India, etc...) get to the point where a mere 20% of their population has Internet access, then we would need 4 times more addresses than are left available, and that's taking NAT into account! So, we don't know when we're going to run out of addresses, but it could happen almost overnight! That's why Asian countries and the European community are pushing IPv6 very hard. On top of that the U.S. Department of Defense (DoD) as announced that they will switch their whole network infrastructure to IPv6 by 2008 and they issued a mandate that, since Oct. 2003, all IT equipment they will purchase, be it hardware or software, has to be IPv6 enabled or have a clear roadmap proving it will be in time. So, if the DoD is one of your customers you probably should worry about IPv6. Same thing is true when it comes to mobile devices, like cellphones or PDA.

So IPv6 is not only needed, it is happening, big time! And, you, developers, should get on the ball!

But, what does it mean to port an application to IPv6? Well, herein lies the "bad news, good news" cliche. The bad news is for applications written in C or C++ (or even C#) the porting can range from simple, for client applications on Unix, to total nightmare, for server applications on Windows (you see Microsoft didn't deem necessary to provide a proper dual stack implementation therefore their IPv6 is the only one I know that is not compatible with IPv4). In any case it means source code changes, new binary relying on new libraries, and, of course, new bugs! Bottom line a lot of work. So what is the good news, you ask? The good news is if you were smart enough to write your application in Java, then you don't have to do anything! You're done. I mean, your code is already IPv6 enabled, you don't even have to recompile. That's right: that application you wrote, and compiled, with JDK 1.1 in 1996 will work just fine on an IPv6 system if you run it with the proper VM (1.4+ for Unixes, 1.5+ for Windows). Let me rephrase that: Any java application (as in the exact same bytecode) will run on any platform whether it's IPv4 or IPv6, Linux, Solaris or Windows! You got IPv6 for free! Remember that the next time you have to convince your management that you should use J2EE instead of .Net for instance!

If you'd like more details about IPv6 and Java, I'd point you to the presentation I made at the IPv6 summit.

In any case, I'll be at JavaOne, so don't hesitate to look me out and ask me any question.

You can catch me at the "ask the experts" booth (don't laugh I didn't pick the name) on Tuesday from 10:30am to 1pm, then at the Technical session TS-2476 on Tuesday from 2:45pm to 3:45pm, and finally we'll have a BOF for Java networking Tuesday at 10:30pm (Esplanade 304/306, Moscone center). I hope to see you there.