Brennan Spies's blog

Live From JavaOne


I'm here at JavaOne this week in San Francisco sitting through the usual spiel of vendor pitches and technology presentations. As always, the conference is a bit of a zoo...long lines for popular presentations, lots of things going on.

JavaScript Debugging in Internet Explorer

For those of us who have lamented the sad state of debugging in Microsoft's Internet Explorer (and no, the Microsoft Script Debugger doesn't count), some relief is here. Complementing the IE Developer Toolbar, the Microsoft Visual Studio 2008 Web Developer Express Edition (and previously the 2005 Express Edition) gives you full JavaScript debugging ability from within the VS development environment without needing the paid version. The only drawback vis-a-vis the professional edition is that the page must be launched from with the IDE (rather than from IE itself). A small price to pay for desperately needed functionality.

Here's some quick steps to get you started:

1. Download the Web Developer Express Edition for free (though registration is required to activate it).
2. Create an empty web site, File-->Web Site...-->Empty Web Site.
3. Deposit the files you wish to debug in the web site folder, and open the file you wish to debug. Place desired break points. (Or you can skip this step if you just intend to just navigate to a URL later.)
4. Click the "Start Debugging" button. If you skipped step #3 and wish to navigate to a URL, then you may want to put at least one debugger statement in your JavaScript code so that the debugger will stop at this statement. Breakpoints can then be set within the IDE elsewhere.
5. Controls are in the Debug menu. F10 will step over, F11 will step into, etc.
6. All the expected debugging views are there: Call Stack, Locals (variables), Watch, and so forth.

Not quite as convenient as having Firebug directly in your browser, but a first-class JavaScript debugger (as JavaScript debuggers go...) nonetheless.

Java Wish List


After reading Alex Miller's predictions for what features will make it into Java 7, I couldn't help but think of my own wish list of improvements to Java (version 7 and beyond). These range from weigh-ins on the major topics of the day to minor improvements in Java's usability. Drum roll please...

1. Reification of generics. Yes, I am beating a dead horse here (it's easier when they don't talk back), but erasure sucks. Unfortunately, I think Alex is probably right when he states that reification of generics won't make it into Java 7, which means it probably won't go into any future version of Java either. Neal Gafter's explanation probably best sums it up as to why reification cannot happen while preserving compatibility. What to do? C# took the better approach to introducing generics: introduce new reified generic classes while deprecating the older non-generic ones. It is probably too late for Java to take the same approach. Quite frankly, I think that the compatibility requirement for generics in Java is far too stringent. Yes, compatibility is important, but not at the cost of the integrity of the language. Can't we admit we made a mistake and change this?

2. Improve generics verbosity. The introduction of generic type parameters, especially bounded types, makes type definitions horribly verbose. Take a look at the following example:

Map<? extends Node, ? extends Collection> map = ...;

Ouch. It would be nicer if the programmer could express bounded types in a more concise way. This might be, to borrow from C# or Scala, the use of a colon (:) to replace the extends keyword (super could use a double-colon, ::). We can now write,

Map<?:Node, ?:Collection> map = ...;

which is much better (or at least as good as it can get).

3. A more intuitive (and explicit) syntax for returns in BGGA closures. Yes, BGGA hasn't made it into the Java language (yet), but the political momentum seems to be in its favor. I dislike the use of return to mean "return from the enclosing method", as well as the use of no-semicolon expressions as kind of implicit returns. While the introduction of pure expressions may be more consistent at the compiler level (language grammar), at the syntax level it's awkward, potentially confusing, and inconsistent with Java's existing control contructs. Use of a statement form for non-local and local returns (e.g. return super and return) would be much more intuitive, though explicit non-local return syntax would be unusable outside of a closure (which complicates the life of the compiler programmer, but better him than the hordes of junior Java programmers). I'm not sure I grok Neal Gafter's explanation of why use of an expression (sans semicolon)--which is already illegal in normal Java syntax and has no meaning outside of a closure--is better than an explicit return statement. Java already has rules as to where certain keywords can be used, and the creation of closure constructs will mandate special syntax anyway.

IMHO, the simplicity of reading and writing a language trumps other concerns by a wide margin; in this view, syntactical consistency is paramount. BGGA in its current form doesn't meet this criteria. Perhaps it would just be easier if non-local returns were disallowed entirely...? I'd like to see a compelling use case for including them, at the very least.

4. Single, unified deployment mechanism for Java programs/libraries. Java has EARs, WARs, JARs, and so on. Some projects/products even include their own (e.g., SARs and MARs in Axis 2.0). It would be really nice to have a single packaging mechanism for deploying all Java programs, with appropriate variations for web applications, services, etc. Though Java modules are only intended to replace JARs, what I'd like to see is some final (and more comprehensive) form of JSR-277 (or JSR-277 integrated with OSGi) eventually replace all existing packaging formats.

5. Convention over configuration. In addition to a unified deployment mechanism, it would be nice if Java stole a few good ideas from Ruby on Rails (RoR). One of these ideas is "convention over configuration", a term coined to express the idea that one should only have to configure something if it deviates from a simple, well-defined convention. Java already has a nice example of this called the JavaBeans API. This approach could be extended to other areas of Java, especially in the way that deployment archives locate and handle various metadata files: XML Schema, WSDL, properties files, etc. There are some existing conventions regarding metadata files in Java, but they are scattered across different specifications and (in some cases) not consistently adhered to; centralization of these conventions in a specification like JSR-277 would be a good thing, as would some automatic mechanism for discovering these files without the need for system properties or other configuration.

Well, that concludes the Java Wish List, for now at least. Feel free to add your own ideas to the mix in the comments or even dispute (!) mine. Remember, not all good ideas in the Java world need to be in the form of a JSR with the attendant expert group. Let your voice be heard.

Will the Real IE Please Stand Up?


Having read Chris Wilson's (IE Platform Architect) explanation of Microsoft Internet Explorer 8's handling of compatibility modes, you just have to laugh--or cry--in exasperation. After years of almost encouraging sloppy web pages, IE 8 has gotten standards religion, almost. There will now be three (count 'em!) modes in IE:

1. "Quirks" mode. All garbage written for IE 5.5 and older is tolerated.
2. Semi-compatibility mode. Any page with a <DOCTYPE> declaration will provide the not-quite-standards-compliant mode offered in IE 6 and 7.
3. Compliance mode (Bullwinkle: "This time for sure!"). Developers who want the latest in standards compliance, at least those standards that Microsoft wants to support, can use a <meta> tag to tell IE 8 that they want as much standards compliance as they can get. You can read the gory details here.

Does this mean that we will get a new compatibility mode for each new version of IE? Mozilla fans, rejoice! By the time Microsoft gets to version 10, the IE browser is almost guaranteed to die under the weight of its own bloat; I mean Windows Vista will run faster on a 486! People will leave en masse to another browser just to get decent responsiveness. Which will, ironically, finally ensure that the Web does have a chance at becoming unified under a cohesive set of standards.

The Closures Controversy in Java


I just finished viewing Joshua Bloch's talk at JavaPolis 2007 entitled "The Closures Controversy", where he critiques one of the leading proposals for adding closures to the Java language (BGGA, named as an acronym after its authors). The presentation is eye-opening, and it is thought-provoking to see two of Java's biggest lumunaries on opposite sides of the debate. Of course, Bloch himself is one of the authors of an alternative proposal for adding closures, CICE (Concise Instance Creation Expressions).

It's not Clarence Darrow in the "Scopes Monkey Trial", but it's the closest we programmers can get. I won't go into huge detail about the two proposals except to say that BGGA adds full support for functional types whereas CICE is a more concise way of expressing anonymous inner classes in Java (there are many places on the web to go into the details). The heart of the debate really boils down to Defensive Programming VS. (for lack of a better term) "Let the programmer do whatever he/she wants (and let the language support it)". The former position being more conservative and more pragmatic, the later a more libertarian view that experts (programmers) are smart and should be allowed to do whatever they want. Ironically, these two opposites are also embodied in many ways in differing philosophies in design between Java and its antecedent language, C++. Java was, after all, "C++ --", the language that made smart decisions to remove features from C++ that were considered dangerously error-prone: pointers, explicit memory deallocation, etc.

So clearly Bloch is in the defensive programming camp whereas Neal Gafter, the main proponent of BGGA, is on the other side. And, I have to admit, I am on Bloch's side as well, for many reasons.

  • BGGA is complex. Non-local returns, continues, and breaks have a great potential to confuse the average programmer. The syntax, when viewed in even moderately complex code, looks cryptic. Even if you get past the syntax and non-local oddities you have to acknowledge, as Bloch so eloquently pointed out, that new features tend to add somewhere between quadratic and exponential complexity to a language because of their interaction with existing features. This was the *gotcha* with generics, and I have no desire to see that repeated with closures.
  • Defensive programming is at the very heart of what Java is as a language. And, by and large, it is this philosophy which has made it so successful. Trying to make it into an "experts language", as C++ is, cuts against the grain of the spirit of the language. (As an aside, it is telling to note that Gafter himself was a member of the C++ Standards Committee.)
  • The Java camp is already losing programmers to newer languages like Ruby because it is "too complex". Do we really want to add more complexity to drive away more programmers from the language? Simplicity is beauty, and (as someone once said) the most important decisions in a language have to do with what features you should leave out.
  • There are already other languages that target the JVM (and hence at least theoretically can interact with existing Java code) which handle closures in a much more natural way: JRuby, Groovy, Scala. Static typing without type inference tends to make control structures like closures much more challenging, if not downright awkward. Both Ruby and Groovy are dynamically typed and Scala uses static type inference. Perhaps one of these languages is a more suitable vehicle for those who feel they really need closures.

Whatever the result of the debate, it is likely that closures in some form will land in the Java language in the not-too-distant future. Right now, BGGA seems to have the momentum, which is unfortunate. Neal Gafter may, in a very well-intentioned way, be leading Java down a path of bloated complexity from which it will never recover; and which will ultimately result in Java yielding its leading position to a new language that is far more agile.

Java Tip of the Day: Using Interfaces


Anyone who has ever programmed in Java is intimately familiar with using the interface, Java's purely abstract class and cleaner answer to C++'s concept of multiple inheritance. It's an old idea by now, and yet new ideas can somehow breathe life into old ones. And this is what has happened recently with interfaces.

The obvious use of interfaces is in abstracting behavior (i.e., methods) of objects and allowing implementing classes to implement this behavior. For example, take an interface for returning an SQL connection from different sources:

public interface ConnectionFactory() { 
     public Connection getConnection(); 

public class JndiConnectionFactory() { 
     public Connection getConnection()  { 
          // get DataSource from JNDI, return Connection 

public class SingleConnectionFactory() {
     public Connection getConnection()  { 
          // create Connection using properties and return

Here the ConnectionFactory interface is defined using two different implementations, one for container environments (JNDI) and the other when used in a non-container (stand-alone) environment (JDBC).

OK, this is old news. But there is another, more subtle, use of interfaces if you think about them as a replacement for multiple inheritance or as being somewhat akin to "aspects" in AOP: that interfaces are a way of layering behavior onto an object. Thought of this way, the style of defining monolithic interfaces with many methods becomes less desirable than defining many interfaces that define one or a few methods that describe a single aspect of an object's behavior.

Let me give two examples of this idea, one from the core language itself and the other my own.

First, the core language. When Java 5 was introduced, a few simple one-method common interfaces were also introduced. One of these was the java.lang.Iterable interface which defined the simple method public Iterator iterator(). Combined with the introduction of generics, this allowed the addition of a new "foreach" construct that looks like:

for(T obj : Iterable<T>) {
     //...logic here...

By isolating the simple behavior of returning an iterator, Java 5 was able to have any class that implements this be used in the new "foreach" loop (not just Collections). Joshua Bloch has also proposed an addition to Java 7 of having "resource blocks" where any object that implements a Closeable interface will be automatically closed at the end of the block.

The second example has to do with defining public and private APIs. What if, in the example above, I were using the ConnectionFactory in designing a framework that would be used as a library in other Java applications, and I wanted to define an internally used Connection that I did not want exposed to the client of the library? And that I also want to use the JndiConnectionFactory and SingleConnectionFactory implementations above with this internally-used Connection?

One approach might be to create two different ConnectionFactory objects, exposing one to the client and the other hidden internally to the framework. This is a perfectly reasonable approach, but let's say (for purposes of illustration) that this is cumbersome because of the framework design and you would rather have a single, centralized ConnectionFactory that defines another method, public Connection getInternalConnection(). This presents a problem because you really don't want to expose this private API method to the client (one of Java's limitations is that there aren't a lot of options for information hiding between classes: package private or protected).

A clever solution to this issue might be to define two separate interfaces, one that exposes a public API and the other that exposes a private API. This way you can have the various implementing classes implement both the public and private API, and you only hand out a reference to the public API to the client.

public interface InternalConnectionFactory {
     public Connection getInternalConnection();

public class JndiConnectionFactory 
     implements ConnectionFactory, InternalConnectionFactory { ... }

public class ConnectionFactoryWrapper implements ConnectionFactory {
     private ConnectionFactory wrappedFactory;
     public ConnectionFactoryWrapper(ConnectionFactory wrappedFactory) {
          this.wrappedFactory = wrappedFactory;
     //delegate methods here


// This class defines the way the client gets a connection factory...
public class AppContext {
     public ConnectionFactory getConnectionFactory() { 
          return new ConnectionFactoryWrapper(connFactoryImpl);

The wrapper class here is used to protect the internal methods from being accessed by the client (could also use a dynamic proxy here). This promotes a cleaner, simpler public API without "polluting" it with methods meant to be only used internally by the framework.

OSGi and the upcoming Java Module System handle this need in a much more robust way, but using OSGi may not be practical for most programmers and use of JSR-277 may be very far away for most organizations which are just migrating to Java 5. Clever use of interfaces addresses this need in a simple and practical way.

Internet Explorer 8 Passes Acid2 Test


Well, it's time for the devil to grab a warm jacket. According to the IEBlog, IE 8 passes the Acid2 test, an important and rigorous measurement of web standards compliance. Both IE 7 and Mozilla 2.0.x fail the Acid2 test.

This is what the Acid2 test looks like on Firefox

It looks much worse on IE 7. Don't let the apparent simplicity of the Acid2 test fool you. It is a very complex page that extensively uses CSS positioning, CSS tables, overlapping content, and even illegal CSS that should be ignored. See an explanation for details.

The latest salvo in the new browser wars?

Update: Firefox 3 passed the Acid2 test as of the 12/08/2006 build (trunk).

Syndicate content