If-None-Match give you the benefit of not having to send unmodified content repeatedly (HTTP 304). IE6 handles this well.
gzip gives you the benefit of compressing the content that you send. IE6 handles this well as well.
If-None-Match should give you the combined benefit of sending compressed content when you must and not sending content at all if it's not modified. Well, as you might have already guessed, IE6 does not handle this well. If your content is gzipped and you send an
ETag header as well, IE6 does not send an
If-None-Match on subsequent requests. Which of course means that you can't leverage HTTP 304.
So if you are servicing IE6 clients beware that it supports either compression or
ETags but not both.
Thankfully, this has been fixed in IE7. Firefox of course just works.
Friday, May 25, 2007
Friday, May 18, 2007
Link: Sam Ruby on Google Maps
Of course, the rest of the iceberg was that Google had simply tiled the Earth. In so doing, they converted a single web service (call me with a bunch of information, and I will provide you with a custom result) into a large number of individually addressable, cacheable, and scalable web resources.That's it. More the resources more is the opportunity to use Cache-Control headers, to use ETags, to distribute and load-balance the system.
In the same article, Sam also talks about how the web is not a service but a space. And in today's world adding more "space" will scale your system manifold than implementing a state-of-the-art service with the most optimal algorithm. Processor speeds have flattened. Today it's about dual-cores, quad-cores, (your-budget)-cores. The more cores your program can use to get the job done, the more scalable will your system be.
As Brian Goetz puts it: "Tasks must be amenable to parallelization". Parallelization comes for free with every resource you add. So add more resources and see your system scale.
Sunday, May 13, 2007
Day 1 was primarily scripting, day 2 hardcore java. Days 3 and 4 saw sessions on the entire gamut of Java technologies - from garbage collection to mashups. I discuss some of them here.
Blueprints for Mashups
This was arguably the most informative session for me by far at this year's JavaOne. Kudos to Greg, Mark and Sean for putting together a to-the-point, practical and readily-usable session together. Personally, this session validated the REST and JSON concepts I had gathered over the past few months. I'll recommend this session to anybody interested in building mashups, REST services, AJAX and a whole lot more. (No, they haven't paid me to say this.)
- Server-side proxy: Clients always send requests to the server that is hosting the page. The server in turn acts as a proxy, sends your request to the (remote) mashup service and returns the data it gets from the mashup service to you.
- Dynamic script tags: Browsers allow script tags to communicate with cross domain servers. This opens up the opportunity for you to issue requests to any mashup service by generating dynamic script tags.
Various options are available for securing your REST services:
- User tokens
- Session based hash
- URL based API key
- Authentication headers
- Use namespaces
- Use CSS for applying styles
- Setting the
innerHTMLproperty is easier / better than DOM manipulation
- A server-side service
- A client-side CSS for applying styles
- Document the API
- Create simple examples enabling a simple cut-and-paste approach to learning your API
If there was one objective of this session, it was to clear the GC myths out there. Some of the finest Java minds were refuting the urban legends out there and when they talk you listen:
- Object allocation is cheap. Reclaiming young objects is also cheap.
- Small, short-lived immutable objects are good. Large, long-lived mutable objects are bad.
- Nulling references rarely helps - except when it comes to arrays.
- Avoid finalizers - in most cases there are better alternatives possible.
System.gc()- except between well-defined application phases and when the load on your system is low.
- Object pooling is not required in today's VMs. It is a legacy of older VMs. Exceptions are objects that are expensive to allocate / initialize or objects that represent scarce resources.
- Consider using reference-objects for limited interactivity with the garbage collector.
Certain memory-leak pitfalls:
- Objects in wrong scope
- Lapsed listeners
- Metadata mismanagement
They strongly advocated FindBugs for finding such pitfalls as well as other potential bugs.
Generics and Collections
Generics have been around for a while and most Java programmers have some understanding of it. There have been many criticisms against the erasure based implementation of generics - since parameter types are not reified, constructs that require type information at runtime don't work well. However erasures allow 2 most important benefits - migration compatibility and piecewise generification of existing code. Just these benefits make erasures a necessary bane.
Huge additions have been made to the Collections framework in Java 5 and 6. So much so that many recommend programmers to never use arrays - Collections all the way!
The concurrency classes introduced in Java 5 are a great new toolset for the Java programmer. New concurrency related annotations such as
@GuardedBy, etc. are being considered. One important aspect to keep in mind - imposing locking requirements on external code is asking for trouble. Ensure that you make your code threadsafe yourself. Performance penalties incurred by
synchronized constructs are overblown.
Immutable objects are your friends -
final is the new
private! They are automatically threadsafe. Object creation is cheap. Aim for less and less mutable state.
Performance is now a function of parallelization - write code such that it can use more cores to get the job done faster. So to improve scalability find serialization in your code and break it up:
- Hold locks for less time
- Use more than one lock
- Consider using
ThreadLocalfor heavyweight mutable objects that don't need to be shared
Builder pattern allows you to construct objects cleanly in a valid state with both required and optional parameters. The basic premise can be expressed in code as such:
MyObject myobj = new MyObject.Builder(requiredParam1,requiredParam2).optionalParam1(opt1).optionalParam2(opt2).build();
Generics - avoid raw types in new code. Don't ignore compiler warnings. Annotate local variables with
@SuppressWarningsrather than the entire method / class. Use bounded wildcards to increase applicability of APIs. 3 take home points for paramterized methods:
- Parameterize using
<? extends T>for reading from a Collection
- Parameterize using
<? super T>for writing to a Collection
- Parameterize using
<T>for methods that both read and write
Java EE 5 Blueprints
Filter.doFilter()may run in a different thread than the
Servlet.service()method. The Servlet API does not use NIO, however it is possible to implement it yourself. New annotations may make
The JSP and JSF EL have been unified.
#is now reserved in JSP 2.1. The
javax.faces.ViewStatehidden field (for client side state) will be standardized. Include this field in your AJAX postback. Application-wide configuration of JSF resource bundles will be possible in
<f:verbatim>tag is no longer needed to interleave HTML and JSF content.
@PreDestroyannotations will be supported for JSF managed beans.
WADL - Web Application Description Language. As a colleague of mine put it - it's WSDL for REST! And IMO that's almost what it is. It's all in good intent to introduce WADL - a formal definition of your REST resources, allows you to automatically stub out code in your favorite language, aids testing. However WADL has many rough edges and I don't see myself using it anytime soon until those have been addressed - overloaded / loosely typed query parameters, security, non-standard content negotiation, et al.
Tuesday, May 8, 2007
Nothing to "Wow!"
If you like showtime, there was none. No big announcements, no new features, no gennext projects. But IMO that was a good thing. Java has seen many evolutions, many innovations. It's time to make it just a little better, a little more robust, a little more performant. Java is a mature technology now and any radical change might actually be shaky news for the massive Java community.
Oh so Groovy
As I mentioned - scripting languages were the talk of the day. And Groovy is one of them. It has been around for a while and the rich set of features it offers are testimony to that - Java-like syntax, pre-compiled or runtime compilation, "duck typing", annotation support and a whole pageful of other features.
I wonder what has lead to this sudden wave of dynamic languages? Wasn't it only yesterday when everything-should-be-strongly-typed was the hallowed rule of programming. Maybe it's the advent of mashups. Maybe the uptake in AJAX. Or maybe we just need something new to keep us interested!
Web as a platform
"Integrated rich clients" - or what we know as mashups - are the killer apps of the day. Things (technologies, techniques, hacks) that allow for mashups to be assembled with minimal code will be on the victory parade. More code is executed on the client but most of that code is still sent to the client by the server. No wonder scripting is big today and getting bigger. But what I do wonder is where does that leave EJBs / ESBs?
JSR 311 - Java REST API
I had questioned the need for frameworks to build RESTful services earlier. And after having sat thru a session explaining the new Java REST API spec I am no more close to getting an answer to that. Ok so they showed a few annotations which got rid of a few lines of code. But does the same simplicity work if I have even a slightly complicated URI pattern? Or will it work if I don't use the "Accepts" header for conent negiotiation and use query params or path extensions? And from what I saw it seemed they were generating XML and JSON from Java code. Aren't JSPs (or any template technology) a whole lot easier to do that?
I got Closure
Neal Gafter gave a presentation on Closures in Java. Very well done, no gimmicks, to the point. A great presentation for a potentially very powerful feature in the Java language. If Neal needs more voices to move this up the JCP and into Sun's plans for Java SE 7, count me at +1.
Take home point
Like 'em or hate 'em - scripting is in town.