Monday Oct 16, 2006

And Now For Something Completely Different

This is the last entry on this blog. After almost ten years with Sun and Java, it’s time to do something new. Today is my last day at Sun.

There are of course, plenty of potentially important things still going on in Javaland, like modules, dynamic language support and closures, but I know how long and painful a process it is to get any such initiative to fruition; so I leave that joyful task to others.

In particular, Alex Buckley ( will be taking over the responsibility for the JLS and JVMS. He will have a blog at, and I’m sure he’ll have wonderful tales to tell. Alex is young, enthusiastic, very knowledgeable - and polite as well. You’re in for a radical change.

Feel free to send me mail about Java at; I am safe in the knowledge that it will bounce; as of 5pm Pacific time today, will cease to be. If, on the other and you want an answer, send your queries, or comments, or suggestions for wonderful new features, to Alex.

I have a new, private blog. However since I won’t be responsible for Java anymore, you won’t want to read it.

Enough said. Good luck to you all - you’ll need it.

Gilad Bracha, Computational Theologist Emeritus

Monday Sep 11, 2006

Strongtalk VM

First, let me be very clear: this post has absolutely nothing to do with the Java programming language, the Java platform or Java VMs. Instead, it's about Smalltalk.

Now that I've lost 99% of my audience, I can speak freely.

I am very happy to announce that Sun has released the source code for the Strongtalk virtual machine. You can find out all about Strongtalk here.

If you don't know about Strongtalk but have an interest in programming languages, environments and implementations, it is worth checking out. Strongtalk was the fastest ever implementation of Smalltalk. Apart from speed, it had support for mixins inside the VM, flyweight glyph based UI, optional type system and mirror based reflection, to name a few of the major innovations.

Strongtalk runs on Windows. I hope we will see ports to other operating systems. In the meantime, I can run it on my mac using Crossover. Here is a screen shot off of my mac and here's another.

If you're serious about building Strongtalk you'll need considerable expertise, and you are likely to encounter a lot of issues. Don't hesitate to contact me about Strongtalk. If I can't help you (quite likely) I may be able to point you at others who can.

Once again, I'd like to thank all those who made this release possible - at Sun and elsewhere. Above all, I want to thank my colleagues from the Strongtalk team. Working on Strongtalk was the most enjoyable project in my career.

Friday Aug 18, 2006

Achieving Closure

Neal Gafter and Peter Ahe have both blogged about the new proposal for adding closures to the Java programming language.
One question that naturally arises is "what took you so long?".
I personally argued for adding closures since 1997/98. My blood pressure still rises measurably when I recall the response I got at the time: "Our customers aren't asking for it, so why add it?". Explaining that people usually ask for minor increments to what they know (e.g., they never asked for Java or for garbage collection) availed me naught.
I've learned that moving the world forward is an agonizingly slow process. Like the giant rat of sumatra, closures seemed to be a story for which the world was not yet prepared.
In the intervening decade, the widespread adoption of scripting languages has exposed a lot of people to the idea of first class functions. It has also shown that another argument used against closures - that they are too abstract for ordinary programmers - is just as imbecilic as the one about customer demand.
The fact that C# is moving in the same direction also helps create awareness of closure. We don't necessarily want to emulate C#, but I believe the case for closures stands on its own merits. The fact that C# is doing something is not an argument why we shouldn't.
Since the late 90s, I've brought the topic up now and again. At times, even I have reluctantly been convinced that it is too late, because we've done so many things that would have been easy with closures in different ways. This means the benefits aren't as high as in a language like Scheme, or Self, or Smalltalk. The cost is non-trivial, to be sure. There are still some who argue his point right now.
However, the need for closures keeps coming up. Nothing has been decided yet - we're starting a discussion here - but I am optimistic.

Friday May 19, 2006

Continuations, continued

First, let me correct an important omission in my previous post. The example I gave is closely based on one I was shown by Shriram Krishnamurthi. Shriram is part of the PLT Scheme group. They have done a lot of good work in this area, and in programming languages in general. They even have their own continuation-based web server.

The history of ideas is very important, especially in academia. I'd encourage anyone interested in the topic to look at the above sites, read the papers, and trace back through the citations to understand it all better. As far as I know, the first realization of such a web server was by Paul Graham, but this is not an academic paper and I haven't done a literature search.

As for the substance of the comments on the last post. It seems that most people who responded are comfortable with us not supporting continuations on the JVM. For those who aren't, I have to stress that any feature we add comes at the expense of something else. Resources are finite. If we add X, we cannot do a good job on Y. So we prioritize. We do this based on input from the community, and on our own technical understanding of the cost/benefit ratio of a given feature. Your priorities may differ.

There are still some smart people that don't buy my view continuation based web servers are a temporary expedient. That's fine. Time will tell.

Thursday May 18, 2006

Will Continuations continue?

I spoke about dynamic language support and JSR292 at JavaOne today. I was quite disappointed that no one asked about continuations.

There are a variety of reasons why we haven’t implemented continuations in the JVM. High on the list: continuations are costly to implement, and they might reek havoc with Java SE security model. These arguments are pragmatic and a tad unsatisfying. If a feature is really important, shouldn’t we just bite the bullet?

I’ve thought about this a bit, and here’s my take on why we really shouldn’t add continuations to the JVM. It’s bound to stir up controversy and annoy people, which is a good reason to post it. By far he most compelling use case for continuations are continuation-based web servers.

A couple of weeks ago I was embroiled in a rather passionate argument about the relevance of continuation-based web servers at an academic retreat at Dagstuhl, Germany. This is an opportunity for me to write down my thoughts on that topic, as the two are closely linked.

The use case for coninuation-based web servers is simple. I want to book a hotel via the web. The web server asks: where? I say Alaska. I love polar bear rides. The server shows me a list of hotels in Alaska. I pick one, it shows me the details. I decide that maybe Alaska in December is too cold, so I clone the browser window, press back a couple of times, until I’m back to the question: where do you want to go today? This time I answer: Hawaii. I get a list of hotels in Hawaii, and pick one. Now I can compare the two destinations side by side.

Upon reflection, I decide to go to Alaska after all. When will I ever get a chance to go Polar Bear Back riding again? I press the button that says “Book hotel and tickets Now!”. I go to the airport on the designated day. As I walk off the plane into the Honolulu sunshine, I find that my parka is uncomfortably warm.

What happened? The server booked my hotel and tickets, based on the last page I visited - which, as far as it knows, was the Hawaii hotel page. It knows nothing of cloned browser windows and back buttons. When I started asking about Hawaii, it literally forgot about Alaska.

The reason the servers tend to forget in this way is because they only keep one call stack per session. This in turn stems from the fact that HTTP and web browsers were designed for browsing stateless hypertext documents, not for dealing with stateful applications.

Continuations can help here, because they can give us handles for multiple stacks, and allow us to return to different ones at will. This is wonderful, but it’s important to realize that this use case only matters if you’ve designed your UI to follow the he-said/she-said style typical of traditional web apps designed around HTML. This UI is a regression to the days of time sharing, before the advent of the personal computer and GUIs. It’s forced upon you by HTTP; you’d never design a true GUI application to behave this way.

The other important point is that the future of web apps is going to be different. Ajax is a sign of things to come (though it’s only a symptom, not a real solution - but that is another story). In time, entire applications will be downloaded and provide a full GUI in the context of a single page. The primitive dialog we see today will return to the ash heap of history where it belongs.

Such an application would use a modern GUI to open multiple windows on multiple hotels. It would maintain the state that the server “forgot” in our example in objects in the heap. Rather than relying on the server’s stack to keep track of what location we’re looking at, the window showing us the Alaska hotel will be a view on a model object that represents the hotel being viewed. When you pressed “Buy”, it would pass all the information necessary to complete the transaction onto the server. Consequently, we’ll have no more of a pressing need for continuations than traditional applications have today.

Summary: In the short term, continuation based web servers are very nice. Seaside is the nicest one I’ve seen. But ultimately they are just a phase, and we can already see how we will outgrow that phase. Since continuation-based servers won’t be all that significant in the long term, and given the huge lead times and costs of adding continuations to the JVM, it makes little sense to support them.

Tuesday Apr 04, 2006

Developing Modules for Development

I can’t control my masochistic tendencies, so I’m about to start yet another JSR. This time, the topic is modularity. Specifically, some notion of modules for development of Java programming language source code.

The upcoming JSR should not be confused with JSR 277, which deals with deployment modules - you know, JAR files and packaging, run time name space issues in support of side-by-side deployment and the class loading issues. They have the hard problem, and I’ve been quite involved in their discussions and in the design of a reflective module API that looks like it will end up being a key component of their solution.

No, the new language modules JSR deals with relatively simple issues.

The most important of these is information hiding. Currently, the only module-like mechanism available in the Java programming language is the package. As a namespace mechanism, packages have been very successful: the inverted internet domain convention has worked very well, and has been an important contributing factor in the success of the Java platform.

Alas, as a modularity mechanism, packages leave a lot to be desired. Here is the basic problem: suppose you are building a software application. Your system consists of several parts/subsystems.

These subsystems are typically more tightly coupled to each other than to the outside world. So you’d like to each to expose an internal API available to the other subsystems but not to external clients. To do this, you find that you have to place all the subsystems in one big package. The internal API is then package-private. This approach has problems. Your system is all in one giant, unwieldy package. You cannot protect elements of a subsystem from other subsystems.

The obvious alternative is to place each subsystem in its own package. Now the package structure nicely mirrors the design of your application. Each subsystem can protect its internals from the rest of the system. However, you cannot provide that privileged internal API you wanted. You can make things public so that other subsystems can get at them - but now you’ve gone and exposed them to the whole universe.

Here is a strawman solution: we introduce superpackages (The name was NOT my idea). A superpackage lists a series of member packages. Public members of member packages are accessible in all other member packages - but not to the wider world. Only members explicitly exported by the superpackage are available outside the superpackage. This might look something like this:

super package com.sun.myModule {
export com.sun.myModule.myStuff.\*;
export com.sun.myModule.yourStuff.Interface;

Don’t fuss over the syntax. It is bound to change.

Tangent: Not that syntax doesn’t matter - but semantics are a much deeper issue. That is in fact why most people focus on syntax. It doesn’t require much expertise or understanding, so everyone can have an opinion. This phenomenon is closely related to Parkinson’s law of Triviality:

The time spent on any item of the agenda will be in inverse proportion to the sum involved.

So, repeat after me: fussing over syntax is for the language-design challenged, and for marketing to the illiterati.

Another, less critical issue we’d like to deal with is separate compilation. Today, if you import code from another package, you need to have that code available - either as source or as binary. In principle, all you really need are the declarations of the public members you are using. You can get around this fairly easily by constructing dummy declarations - but it is an ugly nuisance.

Here is an example:

package interface fully.qualified.packageName;
// implicitly public types and members
class C implements fully.qualified.interface {
String someMethod();
C(int i);
protected Object aFieldName;

Remember, this is a strawman; there should be a JSR dealing with this soon, and the expert group will resolve all of these issues. For example, it will have to decide whether superpackages nest, and what the exact VM access rules are, what the source syntax and binary formats are etc. And very importantly, all of this stuff will have to play well with JSR 277, which is why the two EGs are certain to have several members in common.

Friday Mar 17, 2006

JSR292 and Hotswapping

JSR292 is now officially underway, chartered to extend JVM support for dynamically typed languages. We’ll define the new invokedynamic bytecode and explore what else we can do to encourage efficient implementations of such languages. High on the list of extra stuff is hotswapping.

Hotswapping means the ability to change code on the fly, while it is running. Ideally, anything can be changed - methods can be added, removed or modified, fields and be added or dropped, names of types can be changed and their superclasses and superinterfaces can be altered.

Now before you get all excited, I need to be very clear: we are not making any promises with respect to hotswapping. Full hotswapping support in a system with mandatory static typing remains an active research topic. We really don’t know how far we can go.

This reluctance to commit doesn’t stem from a lack of support for hotswapping, or a lack of appreciation of its value. As an old Smalltalker, I know what we’re missing here. Once you’ve used a system with these dynamic capabilities, you’re hooked for life.

I’ve been agitating for hotswapping support in the JVM since I started working for Sun in 1997. Currently, JVMTI provides limited hotswapping support in some JVMs. That support has its roots in a Sun Labs project that Randy Smith and I helped start back in the late 90s. Misha Dmitriev did all the work on that project, and then helped Janet Koenig’s serviceability team (Robert Field, Jim Holmlund) transfer it to production use.

However, it’s been up to vendors to decide if and how much to support, and nobody support anything close to full hotswapping. Fortunately, the culture is changing, and many more people have started to grasp what APLers, Lispers and Smalltakers have known for decades: hotswapping is incredibly powerful and useful. We owe this change in perception largely to the current crop of scripting languages, which we seek to support in JSR292.

The goal now is to see how much hotswapping can be done for the platform as a whole, and if we can’t (as I suspect) deliver full hotswapping, whether we can at least support full hotswapping for dynamically typed languages, where the issues are simpler. Whatever support we come up with should be a guaranteed part of the JRE, so developers can rely on it everywhere.

If we can get both invokedynamic and full hotswapping for dynamically typed languages working, implementations of languages like Python or Ruby could use the JVM object model directly, and really take advantage of the great performance of JVMs. That’s the holy grail of JSR292. I certainly won’t promise we’ll get all the way. I’ve seen how hard it is to turn ideas like this into a reality for the Java community. There are technical problems, resource problems, political problems .... Still, we’re about to get started (still forming the expert group) so wish us luck.

Friday Feb 17, 2006

Pluggable Types on Lambda-the-Ultimate

Interestingly, Erik Meijer had an interesting post on optional/pluggable types on Lambda-The-Ultimate. It’s provoked quite a response, which is fun to read. Besides, it has the nicest title I've ever seen.

Erik has roots in the Haskell community, but he’s been very open minded on typing issues (certainly more open-minded than me!), has changed his views on the subject over time, and says so publicly. He deserves a lot of credit for that.

One point I'd like to add is that the pluggable types hypothesis has two elements to it. The more controversial one is that mandatory typing should be avoided altogether. The second is that one should be able to plug in additional type systems. This latter point applies even to when one does have a mandatory type system, as is the case in Java. Even hard core type theorists have some interest in this point, since it means that new and valuable type systems can get used in practice, without the huge hurdle of getting them to be part of a language definition.

Thursday Feb 16, 2006

Annotations: Toward Pluggable Types

One of the new language constructs introduced in Java 5 was annotations. The potential of this feature is larger than many people realize. At the same time, like any construct, it is open to abuse. Hence this blog entry.

One of the more interesting things one can do is define annotations that support optional static analyses. For example, consider an annotation like @NonNull, that signifies that a variable should never hold null. If this annotation is used consistently, a tool can check that such variables indeed never become null at run time. You could say good bye to null pointer exceptions!

This is just one example (albeit, perhaps the most important one) of annotations being used to define an optional type system. It is very important to understand what one can and cannot accomplish in this way.

Since I like being negative, let me start by saying what you cannot do:

You cannot change the run-time behavior of the program

You cannot prevent an otherwise legal program form compiling or executing

Annotations can never be used to change the semantics of a program, or to cause compilation to fail. All annotations do is attach information (metadata) to parts of the program. Tools can then interpret the metadata as they see fit; however, the meaning of a program is fixed by the Java language specification, and cannot be altered.

Occasionally I get asked where in the specs is this stated. The answer, of course, is that the specs don’t have to state any such thing. They already give a definition of what any piece of source code means, and a conformant Java compiler must abide by that specification, and cannot change that meaning.

The fact that a program means the same thing everywhere is at the core of the value proposition of the Java platform. Everyone can read a program and understand what it is going to do; the meaning doesn’t change because of a given installations preferences, local libraries or configurations. That is what helps the Java programming language be such a valuable lingua franca across the industry.

Now, on the positive side, you can plug in a wide variety of semantic analyses or type systems, and get reports on potential errors in your programs. Optional type systems are type systems where the type annotations are syntactically optional, and (more important) the types never influence run-time semantics. Optional types are a perfect fit with annotations.

By definition, one can’t dynamically test for an optional type property of an object. While this may seem to be a limitation, the fact that optional types don’t effect the run time means that different optional type disciplines can co-exist without interacting with each other. That means you can plug in multiple, distinct analyzers/tools//typecheckers. This has the potential to enable pluggable types.

The annotation system may need a bit of a boost in some cases, because an analyzer may need annotations not just on declarations, but on additional language constructs. For example, the Javari research project at MIT, which allows you to distinguish between ordinary and read-only references, would require annotations wherever types can appear (including casts and type parameters, which are not currently supported).

In principle, it would be nice if you could attach annotations to every node in the abstract syntax tree. Indeed, even comments could be viewed as annotations. As Michael Van de Vanter has noted, if comments are treated as meaningful metadata belonging to well defined nodes in the AST, refactoring tools can preserve them reliably. However, adding annotations at essentially arbitrary program points poses significant syntactic challenges, so don’t expect that anytime soon.

Sunday Oct 30, 2005

Typechecking JVML

In Java 6 (Mustang) we will be releasing a new version of the byte code verifier. For those of you living in blessed ignorance, the verifier is in essence a typechecker for machine language of the JVM, which I will refer to as JVML below.  

So why are we doing this? To make verification faster, simpler and more adaptable. The existing verifier performs type inference (more precisely,  type reconstruction). In JVML, types are declared for fields, formal parameters of methods and method return types - but not for local variables or the operand stack.  Hence, the verifier must infer the types of local variables and the operand stack based on how they are used. This is slow, memory intensive and very complicated.

The new scheme is rooted in research done by Eva Rose for her master's thesis a few years back.

The new verifier requires additional type declarations for local variables and the operand stack in JVML. As a consequence of this and other detailed changes, it doesn't need to infer them, and is about twice as fast, uses a fraction of the memory and is vastly simpler than the old verifier.

So increased speed and reduced space are obviously good. Simplicity is also obviously good, but looking at the software industry, it's clear that it worships complexity. An appreciation of simplicity for its own sake is sorely lacking. Most people need very concrete examples before they are willing to invest any effort for the sake of simplicity.

Here is one example of why this simplification might be useful. Let's imagine that at some point in time, it might be plausible (in terms of compatibility) to reify generics. Among many other issues, this entails verification of generics. It will be relatively straightforward to extend the new verifier to typecheck generics. Anyone who would seek to get the old verifier to do this is probably in need of clinical assistance.

In Mustang, javac will generate the necessary type information in the class files it produces. It won't generate code using jsr and ret either (nor will other tools Sun releases). Other vendors may need more time to catch up, which is why we will fall back to the old verifier for a while.

The spec for all this is being worked out as part of JSR202 where you can get a draft spec. You can also get more detail on practicalities in  Wei Tao's article on the typechecking verifier. Obviously, the verifier is critical to the security and integrity ofthe Java platform. Because of this, we'd like to get the community involved in banging on both the spec and the implementation. If there are any holes, we want to find them before the release.

To that end, Sun is asking for knowledgable people to have a go at cracking the new verification scheme. If you find a hole in the spec, you'll get recognized at the JavaOne 2006 conference. Honorable mention for finding holes in the implementation. Details should be available soon at the  Crack the Verifier Initiative   web page.

Wednesday Oct 26, 2005

In the Clutches of the Venue

I was at OOPSLA last week. While the conference venue left someting to be desired, I thought the conference was more interesting than it has been in a few years.  There was a very interesting presentation about Croquet (a framework for building and interacting in distributed 3D virtual worlds).

A lot of programming language work. My favorite was the paper on Scala , Martin Odersky’s programming language. Scala is one of the nicest and most powerful languages around, and runs on a JVM as well. It has a lot of really nice features - purely object oriented, closures, mixins, a powerful type system, a powerful notion of modularity, and it interoperates well with the Java platform.

I also gave a presentation on bit rot at the dynamic languages symposium.

Friday Oct 07, 2005

You Can't Educate Pork

... but we tried anyway!

The picture above shows me and Azul CTO Gil Tene  explaining subtleties of object orientation to some pigs in Aarhus, Denmark.  We were in Aarhus for JAOO, which is one of the  best industrial conferences around. Check it out.

I gave a talk about the invokedynamic bytecode - here are the slides.

My previous entry about invokedynamic prompted a bunch of comments, most of which I cannot address.

Someone was upset that I didn't mention Ruby. No slight intended.  On the contrary, I'm a great Smalltalk fan, and as I've mentioned in previous posts,  Ruby is pretty much like Smalltalk, with a few minor differences. So clearly, Ruby is a fine scripting language, and a Ruby implementation on a JVM could benefit considerably from the invokedynamic instruction.

The same applies to E.  I apologize for mischaracterizing its inheritance semantics. One might need to create new classes on the fly, but the basic lookup process should still follow a linear path up the inheritance chain - much like in mixin based inheritance.

In all these cases, supporting mixins in the JVM, a la Strongtalk,  would really help as well - but though I first suggested that back in 1997, I don't expect that to happen. It is a far more radical change to  JVMs than adding the invokedynamic instruction.

The other big change that would be very helpful would be support for more extensive reflective changes to existing classes. Discussing such "Hotswapping" deserves  another post, and will have to wait.

Wednesday Sep 28, 2005


We’re looking to improve support for dynamically typed languages on the Java platform.

  Tangent : that’s dynamically typed languages - not the increasingly common horrible misnomer dynamic languages (as opposed to static languages, where nothing moves, like hieroglyphics, perhaps?).

A lot of hype has been generated over the .Net VM’s support for multiple programming languages.

Another tangent: I always refer to the .Net VM and not the the CLR. It’s a VM, such things have always been called VMs, and the only reason I can think of for giving it a different name is to confuse people. Confusing people might be useful if you wanted to convince them that you’ve invented something when you actually copied it from somebody else.

More generally, jargon has been used throughout the ages to intimidate and exclude. This is a tradition in every profession: don’t say parameterized type when you can say parametric polymorphism .  

Introducing non-standard terminology is popular in industry, as it prevents people from easily comparing your product to others, so that they aren’t tempted to defect. It’s a common trick used by many large companies throughout the history of computing. For extra credit - what’s a long, complicated term for a B-tree?

The fact is, the .Net VM provides support for all manner of statically-typed, single-inheritance imperative object-oriented languages. It could potentially host C#, or Java, or Oberon or Ada or Modula-3 just fine. In other words, you can program in whatever you want, as long as it is basically C#.

Despite the hype, languages with fundamentally different models won’t work all that well. For example, if you don’t have static type information, you cannot use the VM’s highly tuned dynamic dispatch for method calls, and end up doing your own emulation in software. This is tiresome for the implementor, and more importantly, really slow.

The JVM is not really that different. In fact, a study done by some folks at Aarhus University, part of the culture that invented object-orientation, found that there was no significant difference in difficulty between porting Beta to the JVM or the .Net VM.

So what can we really do to make dynamically typed languages easy to port, and port so they run well, to the JVM?

Last winter we had a meeting with various people who work on such languages - things like Groovy, Perl, Python/Jython.  Our conclusion was that the most practicable thing was to support dynamically typed method invocation at the byte code level.

The new byte code, invokedynamic , is coming to a JSR near  you very soon. I’m forming an expert group which I will chair (because of my deep fondness for standards, committees, meetings and process). This group will get to argue over various fine details of how this instruction should work.

Basically, it will be a lot like invokevirtual (if you don’t know what that is, either open a JVM spec and find out, or stop reading). The big difference is that the verifier won’t insist that the type of the target of the method invocation (the receiver, in Smalltalk speak) be known to support the method being invoked, or that the types of the arguments be known to match the signature of that method. Instead, these checks will be done dynamically.

There will probably be a mechanism for trapping failures (a bit like messageNotUnderstood in Smalltalk).

Does this do everything everyone wants? No, but that is not the point. It isn’t really feasible to accommodate the exact needs of a wide variety of disparate languages. Instead, one should provide a good general purpose primitive, that all these languages can build on.

Some might like the new byte code to support multiple inheritance - but each language has its own multiple inheritance rules, and supporting all of them is hopeless. In most cases, the lookup process for multiple inheritance can be benefit from this primitive.

Dynamic languages with a clean single inheritance semantics like E will be able to use this primitive directly for most calls.

Another problem is calling methods written in Java from a dynamically typed language. Static overloading makes this tedious. Languages may have varying mechanisms for dealing with this, often reminiscent of multiple dispatch. This is way too complicated to put into the VM, but the trap mechanism mentioned above should help implementors deal with that problem relatively efficiently.

All of this should eventually make it the use of dynamically typed languages on the Java platform easy, efficient and common place. That’s a good thing. I’ve long been a fan of such languages (well, not the popular ones; rather, languages like APL, Scheme, Smalltalk and Self; face it, I’m a snob and proud of it).

Why does this matter: I’m convinced these languages have a growing role to play in the practice of computing in the coming years. The extra flexibility of dynamic typing will become more and more important as software evolves.

This is not to say that static type checking is to be avoided. As I indicated in my prior posting about pluggable types, the static-vs-dynamic typechecking wars are pointless; one can eat one’s cake and have (most of it) too.   Invokedynamic is a modest, pragmatic yet very important step that helps the JVM become a hospitable environment for such cake-eating and having.

Saturday Sep 10, 2005

Pluggable Types

A few ideas on type systems have been proposed by people who commented on my last entry.

The way to handle these issues is through the notion of pluggable types. Briefly, the idea is that the language is dynamically typed, and various type systems/static analyses can be added as plug-ins.

I wrote a brief position paper on this for a workshop last year. My website contains a presentation on the topic as well.

I'll go over the basics here. Most people are familiar with two approaches to types in programming:

  • Dynamically typed languages, like Lisp, APL, Smalltalk and (much more popular these days), scripting languages like Perl, Python, Ruby (that's basically Smalltalk with a Perl style syntax) and Javascript.
  • Statically typed languages, like Java, C, C++, C#, Fortran etc. Note that statically typed doesn't imply that the type system is sound, or gives any guarantees of any sort. What it really means is that there is a mandatory type system. Your program isn't legal unless it passes the type checker (however broken that type checker may be).
  • There are endless religious arguments over the merits of one approach or the other. These debates are often pointless, because the split between the mandatory and dynamic type religions is a false dichotomy.

    An alternative is to view typechecking as an optional tool, like lint. Now, I define an optional type system very strictly. There are two requirements:

    1. The dynamic semantics must not depend on the type system.

    2. Type annotations are syntactically optional.

    The first requirement is the really important one. The second requirement is obvious to many people, but in fact it's not that significant. People often get hung up on things like type inference to address (2), when in fact that is exactly the wrong thing to focus on.

    A few optional type systems have been built, but less than you think. The definition above excludes quite a few efforts. I built such as a system for Smalltalk. Phil Wadler did some work on Erlang.

    If your language doesn't depend on the type system, you can in principle have multiple type systems that can check different properties; you can evolve these systems independently, as tools. The type systems can be viewed as plug-ins, hence the notion of pluggable types.

    At this point, all the good or bad type checking ideas anyone cares to come up with are up to them to implement. People would not need to appeal to the keepers of the language to consider their favorite idea.

    How to actually do pluggable types in a clean way is still subject to some research. I'm sure it can be done with good IDE support.

    Read the position paper if you're interested.

    Friday Sep 02, 2005

    The madness begins

    Welcome to my weblog, said the spider to the fly ...

    I have a long list of issues that I might expound upon here, on the egotistical and satisfying assumption that you, gentle reader, have nothing better to do with your time than read this (or, more realistically, that you find that reading blogs beats working).

    Expect postings on closures, tuples, dynamic language support, generics, verification etc. However, I might as well start off with the sexiest issue on my list.

    People that know me are aware that I don’t regard the Java programming language as the be-all and end-all of programming languages.

    In fact, several people at Sun, past and present, would love to spend their time on a new language, free from the shackles of compatibility. So while much of this blog will be about the existing language (and VM), why it is the way it is, and ideas for where it is going, some of it will be about some semi-mythical future language. Graham Hamilton already gave it a name: Kenya.

    We would like to hear ideas for the next-big-thing in programming languages. Maybe, just maybe, the company will even start giving grants to academics to study these ideas. I, for one, welcome brutal critiques of mainstream programming languages. Brutal critiques that make sense are even better.

    Now, don’t expect me to actually respond to any comments on this blog. I almost certainly won’t; I may be too busy, or I may think you’re too stupid, crazy, evil or all of the above for me to spend time on your rantings. Nevertheless, do try to be articulate, polite (yes, brutal and polite - no contradiction there) and above all, intelligent. I don’t tolerate fools gladly, as that only creates a feedback loop that breeds more fools.




    • Java
    « July 2016