Each panelist speaking about what they believe the future of Java development will look like

Ryan Slobojan: We'll let each of the panelists talk for a minute or two about what they believe the future of Java development will look like, and then from there we can take it into a discussion forum.

Erik Meijer: I think that the whole thing of languages is very unimportant. We put too much emphasis on the importance of languages. If you look at the whole development process, the language part is a very minor detail of the whole process - it's more about the libraries, the tools, the IDEs, version control, all of that, and languages come and go. So I think what we should do is not concentrate on the languages, but on the ecosystem - or here, in this context, I would say on the virtual machine. The Java Virtual Machine (and, for that reason, the CLR) is in some sense not a very good virtual machine as a basis for that because it puts a lot of constraints on the languages that you target to the virtual machine. I think if you talk about the future of programming languages, you should talk about the future of virtual machines instead.

Joshua Bloch: I'm Josh Bloch, I pretty much agree with that. Furthermore, I think that Java is a mature language, it is entering middle age, and I think we owe it a dignified middle age. I don't think we want to see it running around in a pink miniskirt with a pierced navel. That says something about how it should evolve from here on out. I think there are many important little things that should be done to it, and in fact Google will soon be announcing a JSR which contains a bunch of them, including for example improved type inference - you don't have to say: Map<String, List<String>> anagrams = new HashMap<String, List<String>>(); -- well gosh, most of that is repeated twice, so you want the type inference to do the second half for you. Little things like that, great, but I don't think that we should be doing major things to Java at this point. Java is beginning to show its age in a number of ways -- for example, you can only use 31 bits to access an array, and that's true all the way down into the VM. I think it's time to hit the reset button. I think that we're going to need a new language soon. On the other hand, as Erik said, we should think in terms of the platform: The VM, the tools, and these days a huge amount of investment went into those things. We can't throw that out. We have to leverage off of the existing investment to the extent that we can.

Rod Johnson: I'm Rod Johnson, I'm not sure I have a great deal to add, frankly. I agree with everything that both Erik and Josh have said. I think that, really, languages are important, but they're not necessarily the most important thing. I think Erik expressed it rather well when talking about tooling, talking about ecosystem, talking about all the things that sit above the language. The language is one point, it sits above the operating system and the hardware, but above the language, as we move on in computer science we move inevitably to higher levels of abstraction. There now are many things above the language that are probably more important in many ways to our daily work. An example of that is the .Net Framework. If you think about what the most important thing about that is, it's not necessarily C#, although C# is quite like IL - it's the fact that you have all the assumptions about the runtime, about assemblies, all of these things that are above language. Similarly, for most people who are working with Java, it may well be that particular models like Java EE, or other models are more significant to them in many ways than the language. So I think that it's just one theme in terms of a very big picture. I would agree with Josh that Java is a mature language and we should regard it as such; I also think Java is a pretty good language. And I think, although it's fashionable to take pot shots at Java these days, I think that is not altogether fair because especially if you look at some of the things that were done in Java 5, Java is a much better language than it was 3 or 4 years ago, and I think we should be very thankful for that.

Charles Nutter: Well, hello. I'm Charlie Nutter from JRuby. I'm not going to say that I agree with everything that the 3 people before me said. I think that languages are very important but not for the purposes that a lot of people may think. What languages are important for is giving us new ways to look at particular problems. If we did not have Ruby we would not have Rails, and we would not have a massive change in the way people look at web development these days. And I think what that actually drives us towards is what's really most important for the future of Java is moving away from the ivory tower model of deciding what's best for you all and letting you help us in the Java ivory tower, or the folks that had been making the decisions for you in the past; work with us to find the way these things actually work out. Opening up the JDK, fostering more open source community projects, finding ways for the community to actually decide what the future of the platform is supposed to be, that's where it's going to go. And I'm not going to try and tell you where the platform is supposed to go from here, because it's in your hands at this point.

Chet Haase: I'm Chet Haase from Sun. I guess I have to agree that the future is not necessarily about the language, but mostly because I'm not really a language person so that's not the way I think. I think of the whole platform instead and the characteristics of, what are the functionalities that we deliver through the libraries, or what's the deployment step. What I would like to see change about Java the platform, the solution, is fixing some of the existing problems and making it easier to deploy these things and make Java the platform appeal to a larger segment of the population, so sort of taking it out of the enterprise and making it appeal to the consumer developer or the consumer user as well. As well as exposing some features that either enable new functionality or make a lot of the existing functionality a lot easier. You can do some really cool, whizzy stuff with the Java platform today but it's not necessarily straightforward or easy to understand how to do that. You can write a Swing application that looks really fantastic but you have to be a fairly sophisticated programmer in order to do that. Where we're trying to take the platform, I believe, is in making it easier to accomplish these things either through new languages that sit on top or changes to the libraries or new APIs that simply make the development model a lot easier. That's my view.

How do you see the APIs growing in the future?

Rod Johnson: The question was, "How do you see the APIs growing?" My answer to that would be, personally, I would actually like to see some negative growth in terms of the APIs. For example, take the AWT packages - who recently used AWT? Who would like AWT kept? I think we really need to take some hard decisions because, frankly, the size of the JDK is getting to be problematic. This hurts the platform. Certainly, it is going to be something, if we do pruning, that there is going to be a degree of pain around, but I think that it's naïve to think that there isn't pain at present from the fact that successive versions of Java do get bigger and bigger, and people use that - as I mentioned, people like to take pot shots at Java, and we're giving them a pretty damn big target these days. So, I really would like to second Charlie's point that we need to get out of the ivory tower. I really don't like the idea of us and you - well, I'm certainly not part of the 'us' in terms of not working at Sun anyways - but I think that we're all one community and we want this language and platform to prosper and, frankly, I think that we really need to try to start a wider discussion in the community about, for example, whether we're always adding things, whether we really want to be serious about deprecation and pruning.

Joshua Bloch: With all due respect, I think Rod's attitude on this one is naïve. I would love to drop deprecated APIs - there are entire classes, hell, packages that I would love to drop. How many of you have used CORBA recently? Any hands there? Oh, one - well you have my sympathies, to the one of you who's actually used it. And to the rest of you, sure I've love to drop it, but you know what? There are banks and insurance companies that have invested tens of millions of dollars in systems that use this, and if you stop supporting it all you're doing is ensuring that they will not progress forward, ever, beyond the last release that used it. There's this company called Microsoft, and my buddy Erik here works for them, and they got really big over the years, really really successful, and the way they did that was upward compatibility. I can still take programs that I bought - in fact, I did this the other day, a wonderful game called The Neverhood, it's out of print so you should basically steal a copy from your friend, burn a CD, it's a lot of fun to play, the whole thing is done in clay-mation - but anyway, it was written back when a state of the art system was a 75 MhZ Pentium, that was the best you could get. I put it on my son's Vista machine the other day, plays like a charm, better than it ever did. That is amazing.

Rod Johnson: Just briefly, I think that we should actually ask the users rather than making assumptions - I spent an awful lot of time talking to large companies like banks and insurance companies, and take for example, my area of interest is principally EE rather than SE. I'm certainly not going to claim I'm an SE expert, but I know for example how those people think about platforms, like in the EE expert group we tend to assume that they're all desperately keen to have their EJB 1.1 entity beans still supported. If we decided to actually deprecate that and provide a transitional way to get it out of EE they'd be out there cheering. I think that we shouldn't assume that people don't actually want to make some effort when they see that it's worthwhile in the end.

Charles Nutter: I'd probably say, if you want a little bit more concrete idea of what needs to be done to APIs, we need to start looking at the different APIs we use in terms of not just the Java of 5 years ago, but the Java of the future and in terms of all the other languages that are coming up on the platform and how to make it fit best into all of those different languages and those different ways of solving problems. In the JRuby world, one of the most popular uses of JRuby now, probably a close second to Rails, is using JRuby for GUI development with Swing. People that originally hated using Swing have now started building multiple different frameworks, shipping production apps, all sorts of stuff because they suddenly realized that these APIs are a lot easier to use when you look at them with a different eye, from a different language, from a different perspective. And, taking that and feeding it back into the system and finding how we can make it more approachable and more accessible to those different ways of doing things and those different languages would probably be the biggest improvement we could make to the APIs we have today.

Erik Meijer: To tie back the APIs and the languages, one think that I think that's very fruitful is to look at API usage - are there patterns where you always use APIs in the same ways? And that's often an indication where you can extend the language because then you absorb those patterns into the language and then you make programming with these APIs easier. I think that we don't really do that a lot. Another thing I think, what we did in C# and Visual Basic with LINQ is that we make that user extensible so there's language syntax that is translated into certain API calls, and now users themselves can write other implementations of these APIS and then still have that nice syntax. So I think there is still a lot of leverage in the interplay between languages and APIs.

Joshua Bloch: I don't have a lot to add, so I won't add anything, actually! Go ahead with the next question.

Can we modify the Java platform to utilize a core library with pluggable modules?

Chet Haase: I assume you're talking about download size? [response from audience] So, to try to repeat those 75 questions, so basically could we take the JRE platform and define some core subset that continued on and then have these other pieces, these modules that could be optionally added, is that a nice summary of that? So, it's certainly possible - it's software, anything's possible. The problem that we run into that already came up is we have defined Java as a platform that you can depend upon having certain functionality. If we start stripping out that functionality, applications that depend upon it will suddenly break, and we can't go and ask all of the customers what they want to do because we don't know where the applications are, right? Most of the Swing applications are probably on the intranet. What are they using of Swing? I don't know. They downloaded the JDK, they wrote their application, they never asked us, we don't know the functionality that they're using. It's a little hard now to simply break their app and then find out, right? So, certainly we could define a new model, but that is in contrast to the current working plan of "Java has all the current capabilities, and we encourage you to upgrade and get more functionality without breaking your existing applications". Maybe there is a new platform that we could work toward that has a core set of functionality and optional pieces you could add in, that is not Java in the current model because that would break stuff, right? That's the core constraint here and the core conflict. Bob had a question...

Does the Java Kernel/Java 6 Update N project create this core/plugins architecture for Java?

Chet Haase: The Java Kernel? Right, so can I keep addressing? So, Java Kernel is basically a workaround given the current constraint - the JRE is this thing, right? There is no other way around that in the current model. Java Kernel is a workaround for that situation where you can specify, "I need this subset of functionality" which is going to be VM, security, networking, classloader, plus these additional chunks of the JRE, wrap it up, bundle it for me, ship it down, run my application, and while you're running, install the rest of Java so that the next application that executes will grab everything else that it needs, right? So the platform, the Java platform, will still be there, eventually after the install completes. This is basically the best that we can do in the current model where we have to have Java as this thing, but really any application probably only needs 30 or 40 percent of it.

Do we ever want to remove code from the Java APIs, or create a new modular platform within Java?

Rod Johnson: I have two questions, I think - one is quite important... One is, and I think this is pretty important to the future of the Java platform, do we ever want to do this pruning? Maybe the answer is we do keep adding things and not taking things away forever, but I think that's a pretty profound decision about the future of the platform. And the other question is, I think the idea of an additional platform within the Java brand would be very interesting, and I think it would be very very interesting since we have a Java Community Process to try to focus on the community part of that and have some discussion with people outside to see what they actually wanted and if they thought that was an interesting idea.

Charles Nutter: Well one thought that occurs to me immediately is the fact that the JDK for example is open sourced, and I've thought a couple of times about going in and making my own build that doesn't have CORBA and doesn't have AWT and doesn't have these other pieces. And I can do that - I can take those out. It won't be Java, but I'll be able to strip it down to what's needed for, say, a JRuby user who wants at least a comparable footprint to the existing Ruby implementation. If it works, then that's a community vote - that's a bunch of community votes saying that this is what we need to do and we need to find a way to strip down this kernel. There's nothing to stop anybody from going in there and making their own version of the OpenJDK, playing with it, taking stuff out and trying to mix and match parts to fit whatever their purpose is. And, as we start to see more and more of that, as that becomes a more common thing, what it's actually going to do is feed back into the process and we'll know whether that works and whether people actually want us to be pulling pieces out. So, I think we'll see that pretty soon.

Erik Meijer: So I think you can never take anything out. I agree with Josh. And the thing is, you have to know that when you put things in. So we have to be more careful putting things in, but once it's in, you can never take it out.

Is the download size of Java really that big of an issue?

Joshua Bloch: Ok, the question was, "Does size matter?" And the answer is, Doctor Ruth was dead wrong here. Let me tell you, size matters, the smaller the better. When in doubt, leave it out. [audience comment] No, size really really matters, actually for the reasons that Rod was alluding to. The idea is that there's this notion of conceptual surface area - when you want to learn a platform, you need a book about maybe, ideally this thick, like the Modula 3 manual, maybe this thick, but any thicker than that and the platform isn't learnable, and you've got these big bricks, and you can't really program a thing until you've read your way through the brick, you're dead. So, I believe that it's very very important, even if a system does have a whole bunch of snap-on bits that can make it do fancy things, that you have a core that is complete, that defines the platform, and that that is small. Whenever you see a specification grow beyond a certain size that means you really are in trouble.

Are there plans to add core/plugin-type modularity to Java?

Joshua Bloch: There is an existing JSR that is attempting at least in part to address this problem, it's 277, is that right?

Chet Haase: I think that that addresses the problem of having infrastructure to allow versioning and modules that can specify what you need to run your application and what you depend upon and it'll go out and grab all the things, but that doesn't address the core constraint that I was talking about, about still having the core platform being this one thing, right? Simply having 277 functionality in there doesn't mean that we'll have the ability to automatically reach out on the web and grab CORBA when an application demands it, right? The core platform is still the core platform.

Aren't there existing examples of Java platforms with varying APIs and functionality? Why can't we add more?

Chet Haase: So the lack of a question was, "that there are examples of Java platforms out there having different sets of functionality". Certainly in the ME space and in the profiles that exist there. I'm not sure that I would take the profiles problem on in the SE space, but it's certainly worth considering having a new platform, but that is the decision - do we want a new platform for Java or for whatever we would call this thing, right? We can't simply automatically start subsetting and profiling and assume that all the applications out there that are already deployed and running happily on the desktop are going to be happy with this. I think the equation is very different in these other spaces that you brought up though. If you're running in a server environment where you know that your application server is never going to need AWT, then you're probably more likely to want to install something that doesn't have AWT or other functionality that you know you'll never need in that environment. And you can very closely control what gets deployed there, when and who the users are of the system, but on the desktop when we deploy Java we need it to be, in the current model, we need it to be a particular thing so that any application that was ever written depending on that functionality will continue to work for any future versions of the platform. And it's a different world on the desktop and it's also a different world for the mobile devices you mentioned as well.

Joshua Bloch: And if we do define a new platform, there's a lot of effort involved, so my question is, do we want to apply that effort to subsetting Java, or perhaps to writing a new platform atop the JVM in which the 97 problems described in "Puzzlers" have been eliminated? I would far prefer going that route, rather than just subsetting the one that we have. And by the way, maybe we could also address arrays with 64 bit integers, wouldn't that be great?

Chet Haase: Where would your book revenue come from?

Joshua Bloch: Oh, where would my book revenue come from! You're assuming I have any.

Do you think the Java platform is already too complex?

Charles Nutter: Actually, before we move on, there's a question - I just want to see a show of hands. How many people think that there's too much for you to know or use in the Java SE platform as it stands today? Everybody! Of course! So, what do you want us to do about it? That's the next step. What do you guys want to do? I mean, we can guess, but that's not going to do anything, that's not going to accomplish anything. What do you guys think that we want to do? So, after we're done telling you what you should think, you can come up and talk to any one of us, in the hall, and tell us what you think we ought to actually be doing. So, you can go on.

With dynamic typing, do you lose information that would otherwise allow development tools to help you with e.g. refactoring?

Joshua Bloch: It's a wonderful question, and it's a divisive question. There are, as you know, religious wars fought over this issue. I happen to love strong static typing, and people will take it away from me out of my cold dead body, cold dead hand, whatever they say. However, there are some people who like the ease of programming without it, and certainly there should be languages for those people. I think that there's nothing wrong with supporting multiple languages, and in fact you can even have one language with an optional typing system - Gilad Bracha has written on this, I know Neal Gafter has also thought a lot about it, where if you want... The thing about static typing is it's just one little kind of static analysis, and static analysis is proving it's worth every day. It was something that people used to talk about 10 years ago, but now they really do it - you can find bugs in your program before you ship it using static analysis. The first successful application of that is strong, static type checking - you can guarantee that you're never going to get a ClassCastException at runtime because the type checker has told you so, that's a wonderful thing, and in fact with tools like FindBugs you can also make other, even better guarantees than that. So I think, in one direction we're adding more information to programs with annotations and so forth, to improve the quality of the static analysis we can do, and in the other direction, we're saying "Hey, let's make it really really easy to write a program by not specifying any of this stuff, and just letting the language do whatever happens to work". I think that we should continue to support both of those things - there will be a need for the two of them, the two aren't mutually exclusive, there are many different kinds of systems that you build. If you're building a guidance system for the space shuttle, your demands are very different then if you're figuring out what the next game is going to look like.

Rod Johnson: I would actually like to come back to the original question which started off with trolling. So to me, one of the fundamental issues is "have you lost the information that you would need to perform analysis in your tooling", to, say, support refactoring. Take, for example, the Java Persistence API. Take the XML configuration syntax for that API. That does not lose type information. I can perfectly easily write a tool, and such tools exist, that will fully support refactoring, browsing... there is no loss of information. I think when you get into the interesting questions, and not so much whether you go out of the language, because so long as you haven't lost information you can go and support XML or whatever in tooling...

Joshua Bloch: But Rod, in dynamic languages you do lose information. If you say "var i = f(x)", what's the type of i? Who knows?

Rod Johnson: I think you basically completed my sentence for me, Josh. That was what I was about to go on to say. So, the question is, whether there is loss of information, and I've given an example where there is no loss, and there are many examples, like in frameworks, where there is no loss. Obviously, dynamic languages are completely different, and they say "hey, loss is a good thing" - loss gives you other benefits. And I think, as Josh has said, this is a religious war. Frankly, I'm fairly pragmatic, I try to avoid getting embroiled in religious wars, it's very dangerous to one's health. So, I wouldn't presume to know the answer. But I think it's important to know that you can go out of a strongly typed language into other syntaxes without necessarily losing type information.

What are the pros and cons of static versus dynamic languages?

Charles Nutter: I suppose another way to phrase the problem is, "is the definition of 'type' that we use in the Java world the only definition we should be looking at?" In the Ruby world, we are not talking about things that are untyped - we are talking about things that are typed in terms of particular operations that they support, and that information is all still available by looking at the code. We expect that a particular value will come in and be able to respond to a 'toS' method. And we basically can find the exact same sorts of refactorings by being able to trace through and figure out which operations are expected on which types of variables.

Joshua Bloch: Assuming you have all the code in the universe.

Charles Nutter: You only need your code.

Joshua Bloch: No! You need all the code that's going to be dynamically absorbed by your code. It really is true that static typing allows for more checking up-front, and it's also true that it's more of a pain in the butt to program because you've got to get it right although the tools can help you get it right.

Charles Nutter: Absolutely. Well how many people have worked on a Java application that was absolutely impossible to refactor and clean up? It should be basically everybody because everyone's been in that position, right? Static typing does not mean that you have an application that you can evolve easily and that you can refactor easily, and that you can evolve to new problems and new domains in the future, and the problems are just different depending on which sorts of languages you use. You end up using a lot less code if you have a dynamic language, but you lose some information. You need to be closer to your code, you need to be running more tests, you need to be paying attention to what more people are doing with your application, whereas on the Java side, you need to make sure that people are not trying to work around the static typing and not trying to find new ways to do dynamic programming in a statically typed language, and as a result making the application far more complicated than it ever needs to be. So, we have different problems on both sides of the fence, and actually I tend to agree that the answer may be somewhere in the middle with type inference languages where we actually do have a lot of the more relaxed syntax of a dynamically typed language but we do have the information we need to pass typing through the system. So, I think in the long run that's going to be where a lot of development actually starts to settle.

[audience question] Joshua Bloch: Any code. Especially when you are writing frameworks, you're often passing stuff in. Virtual calls, you name it. You write modules. The whole idea, as far as I'm concerned, behind modern programming is that you want to be able to test, develop, optimize modules in isolation and then put them together into a fully functioning computer system and know that they're not going to blow apart. But, if the only type information that you have comes from the totality of the code, you can't do that whereas if you know that in order to invoke a method the only thing that you can pass in here is an instance of the Foo interface, then you know darn well that all of the calls supported by Foo will be supported by the thing that you pass in. So, that's basically what I'm saying, and I actually believe in it fairly strongly.

Erik Meijer: So maybe I can say something here... So I think that it's a little bit of a pity that there's usually such a religious war between static and dynamic typing because really, I think, static typing is just one dimension. As Josh already said, it's about static analysis. I would like my tools to know as much as possible about my programs to help me prevent things, and I want them to do it automatically - I don't want to write it myself. Everything that the tools can do is good, right? Because I'm lazy, so that's good. The thing is that, I think the problem is that we are a little bit too obsessed with the fact that sometimes this information must be there, so I think if you read Gilad's papers he says that it must be layered and optional, and I think the problem that we now have is that we push this static type information too far down to the virtual machine, and that's why we need things like the Dynamic Language Runtime or JRuby where you have an interpretive layer on top because you cannot implement all the things directly in the VM. So, I think, to me, this is like... I don't want to say, "Let's start from scratch", because I'll just contradict myself, but I think here, looking at this from this fresh perspective, where you say, "Let's see if we can have a unified view of what types mean" or what static information means and let's not push that all the way down to the bottom because that puts too much restrictions in there, that might be a way forward.

Charles Nutter: That's actually one way that we've looked at possibly doing optimizations in JRuby, is that we want to be able to specify in at least the definitions, the bindings of methods on the Java side that we expect certain types you're going to have or certain operations so that we can do some of that checking for you ahead of time and avoid every piece of code having to say "Ok, does it have a toS method, is it a String, is it a fixnum..." We could do a little bit of that ahead of time, and as the program runs we can also do some analysis to determine what types are actually coming in. If we can start feeding that back into the development process and saving some of that information as we go, we also can get that back out there again because we know what the application actually does when it does finally run.

Should we add features like closures and XML literals to Java?

Joshua Bloch: That takes you right back to my opening statement. And here, this is my personal opinion, I am not speaking for Google or the Java Community Process or anything else, but I believe that Java is a mature language, and I believe it would be a mistake to jam many of these things in. Some of them are just syntactic sugar, like XML literals. I have nothing against syntactic sugar so long as it's sweet, so long as it tastes good. I think XML literals are a horrid idea, and I think the community actually agrees with me on this, so I think they're dead, thankfully. I think there are a number of other pieces of syntactic sugar that would be actually good -- for example, when I was doing JSR 201, I just neglected to write that you could use the comparison operators on Enum constants. They all implement Comparable - you can use ==, but unfortunately < and > don't work. So there's a little bit of syntactic sugar that's utterly harmless to add. I support the addition of good, useful syntactic sugar that does not appreciably increase the conceptual surface area of the language, but I don't support anything that does appreciably increase it.

Shouldn't programmers be able to understand and utilize new language features? Aren't we supposed to be intelligent?

Joshua Bloch: Ok, the question was, "Aren't we programmers meant to be smart and have the brain capacity to learn a whole rich set of features?" And yes, yes you are, and I hope that the next language you learn has some of these good features, but you don't want a language that has many ways to do the same thing, I think - once again, this is totally my view. I am not a huge fan of C++. I think it was somewhat impressive when it was new, as something that was upward compatible with C and added some useful stuff although I think there were some horrid ideas even back then. I shouldn't say that in public, strike that from the record. But at least there were some uses whose taste was questionable, right? Like using the << and >> operators to do character input and output - you must admit that that's a little iffy, right? But the thing is, here we have a language that has many many different ways of doing each thing, it is a multi-paradigm language, and I don't want to see Java go that route. For example, there already is a way to represent the function object in Java, and there are a whole bunch of APIs that make use of that way to represent the function object. Do we want to turn all of those old APIs into second class citizens? Do we want to have a new set of libraries which use the new kind of functions? That really really scares me. So, yes, you're a very smart programmer, like the rest of the programmers out there, but that doesn't mean that we can't make a language so complex that you can't use it any more. I think everyone who programs C++ for a living either programs a subset or revels in complexity.

Erik Meijer: I don't agree that programmers have big brains. You should read Djikstra's "The Humble Programmer."

Does this mean that we will have to move to languages like Ruby to get the latest language features, and that changes to Java will eventually stop?

Charles Nutter: I don't know how unfortunate it is, but I think I understand what you're saying and I think one key point that Josh actually mentioned was "the next language you use", and I think one of two things has to happen. We either need to look at continuing to evolve Java, to solve the pain points of developers that are using it, and doing it in a measured way, not like, and this again is my opinion, not in the C# way where you throw just about everything in that you possibly can, or in the Perl 6 way, where it's the "every language." But, we either need to do that to Java in a measured way, and do things that are right for Java the language, or, and maybe these need to happen together, or we need to be doing more to support languages that present those features in the way they were meant to be presented, or in a good way of presenting them. And, I think the two of those together is probably going to be the best for the platform itself, rather than saying "Ok, we need to have an 'every language', and then we can have all these others." I think we have lots of tools that we can use and we need to figure out the right ways to support those tools and the right way to evolve them for the problems we're trying to solve.

Joshua Bloch: I agree with that, and I absolutely do want -- to the extent that I'm still involved with the Java language, which is actually quite a bit, I do what I can - I want to address the pain points, and when people come and tell me they have pain points, or when I feel a pain point, I think to myself "what is the minimal change that I can make to this language to address that pain point?" And those are the sorts of proposals that I will put my full weight behind. And, as I say, there were a bunch that I'm working on now. You will see Google releasing a JSR pretty soon that has a bunch of little language proposals which I think solve real pain points. Another one was the ability to catch multiple exception types in a single catch clause - how many times have you had to catch this, do something, catch this, do the same thing, and you should be able to just say "catch(this or that e) { doIt(e); }", so that's part of the proposal and we know how to do it, and basically I do want to solve your problems, but in some cases, it seems to me that the power to weight ratio is wrong. For example, you wanted named as well as positional parameters. I actually think it's a little bit of a mess when you mix them, I know that C# does this in places, but I'm still...

Erik Meijer: No no no, Visual Basic does it.

Joshua Bloch: No, there's one place where C# does it.

Erik Meijer: Oh, yeah - in attributes.

Joshua Bloch: Attributes. I know, because we ripped off the design. That's a joke, by the way, for any lawyers out there. So, the thing is that you can do something very similar in Java right now, and in fact one of the little features in our proposal that's going to come out next week helps address this. And the way you do it is you basically have methods that return the "this" object and then you can chain them and have the effect of named parameters. So let's say you have a builder, and you create a new FooBuilder, and then you can say ".height(15).length(45).weight(56)", so you're just going from a keyword - well, not really a word, but it's the name of the method - to the value of that parameter, so to speak, and then when you're all done you say ".build();" So that feels an awful lot like named arguments, but it doesn't change the language much. [audience question] No it isn't! It's got the same number of characters, and it doesn't add anything new to the language, it achieves the same level of expressiveness with features that already exist with one exception, and the exception is minor and technical. The exception basically is that if you extend a type you want the return value of this expression to be the subtype, and you don't want to have to override all those methods, and we actually have a very simple and very sleazy solution to it, which is: void returning methods can be used as if they returned the receiver. There you have it.

Erik Meijer: I have to say one thing here, that I think in C# we are actually very very careful not to put everything in there so we look at everything a hundred times, because as I said, once you put something in you cannot take it out and I think that's maybe the answer. We started out by saying "aren't the class libraries too big?" The same happens to the language if you're not careful, right? So you have to be extremely prudent in what you put into the language, and it's so easy to throw in new features. Once you have them in there you can never take them out.

Joshua Bloch: So if you're going to pick on a language, pick on C++.

Does the average developer have any say in how Java evolves?

Rod Johnson: I agree with Erik's point that clearly if you throw in new things there's a danger, but I would like to come back to my initial point about needing more community involvement here, because listening to this exchange, basically what I'm coming away with is the sense that, for example, if Chris Richardson has a view, that's not going to change anything. If Google has a view, that's probably going to change things. And I think that it would be very to have some way of having greater community involvement, and I think the JCP is a good start but I don't think it is perfect.

Joshua Bloch: So, I think that's utter hogwash. The point is that there is tons of community involvement. Just because you hear it from Google doesn't mean it came from Google. A lot of the good ideas I get come from community members who send me email, whom I meet at conferences such as this one, and just whom I have known over the years, and in fact if you look at the composition of the previous Expert Groups, language Expert Groups that I've worked on, which means principally JSR 201 and JSR 175, you'll find independent programmers like Tim Peierls who runs his own little company out on Long Island, you'll find people who work for big industrial mega-giants like IBM, you'll find tools vendors like Borland, you'll pretty much find community members of every stripe. We are not exclusive. If you want to contribute, please do.

Is C# evolving too quickly?

Charles Nutter: To tie together with Erik's comments and with the community angle, I guess the concern that I would have, for example about a C#, is not the features that are going in, or the number of features, it's the rate. A lot of people complain that the Java platform evolves too slowly, and I think that is a damn good thing, because that has allowed us to see whether these features actually work over time, and what the next incremental, small incremental change we should make ought to be. With C#, it seems to be an extremely rapid process. The features are coming in extremely fast, and 1, 2, 3 - folks are just starting to pick up stuff from 1.1 and 2.0 now with 3.0 coming out very soon, or is out? And it's just the rate and the inability for community, even smart developers like yourselves, to keep up with that process and to be able to feed back into the system in some measurable way.

How can the community help to determine the features that go into Java?

Chet Haase: We just had to be forward compatible with 1958 languages. So, actually I wanted to address the community thing as well. I completely agree the community needs to be involved. I would say that I think we've gone a long way in the last couple years in doing that. A lot of the features that were sort of tossed out randomly here this evening have actually been debated in the community, right? This is not just Sun saying, "gee would this be a good idea?" This is people in Sun and Google and wherever maybe tossing ideas out there and people taking them and running with them, right? People with their influential blogs, or chatting to their friends, or posting on forums or websites, actually going to the OpenJDK project or the Kitchen Sink project and hacking with code and seeing how things work and posting it and actually having a dialogue in the community. I think specifically in the language feature area this is happening pretty awesomely in the last year or two, right? So a lot of this stuff that we've talked about here tonight - I think properties is a great example that was sort of, some simple suggestions at first like "oh would it be nice to have simple property declarations", and this flurry of blogs came out and said "well you know, that's totally inappropriate because I need to do this and here's an alternative proposal" and if nothing else it convinced everyone in the community that the problem was actually a lot more complex than it was initially thought. So I think the dialog is actually very good right now - it'd be great if it got even better, but there is actually a dialogue taking place already.

Erik Meijer: I fully agree with that, that often somebody proposes, they look at it from a very narrow perspective and they say "oh, it's easy!" But it's always more difficult than you think - take continuations. You say "Oh, well how difficult can continuations be?" If you look at the literature there's like 50 versions of continuations, right? Delimited continuations, one shot continuations, shift-reset - there's no one design, so it's easy to say "we should add continuations" but then, which of the 50, right? And then you put one in and then it doesn't support some other language that is on the platform that wants to use continuations. And then with these things we say "we cannot add it" because why add something that's very particular for one language? I think you have to take these things, and it's a very subtle balance and you have to walk that.

How does adding features affect the complexity of a language?

Joshua Bloch: One thing I would like to add to that also is that the complexity of a language is not linear in the number of features. It is either polynomial or exponential depending on how you look at it. If you only consider interactions pair-wise or trio-wise, it's polynomial. If you think arbitrary groupings of language features can cause strange corner cases -- and believe me, they can, buy "Java Puzzlers" if you don't believe me - then really, when you have a language that has already reached a certain size, adding the next feature can be the straw that breaks the camel's back. [audience question] Let me give you what I see as early warning signs that the camel's back may have been broken. If a language was chosen by the college board as the official language to teach advanced, AP Computer Science, and 2 years later was kicked out for another language, that's a good sign that the first language might have grown a little bit too complex.

We're talking about history, by the way. And yes, I see this as potentially happening to Java, I have lots of friends who are professors teaching CS 101 and they're basically worried that it isn't this nice, simple little fuzzy round thing that it used to be in 1995. So that's 1 way in which I see it happen. If it stops being popular as an education language, and if programmers frown, if they come to work cursing because it's a pain, that's also a really bad sign. One reason they come to work happy is the tools - I've heard that said many times here. There's this lovely set of tools, some of which are free, that make programming Java very pleasant. So, it isn't all bad, but I do see, if we make the language too complex, I see the incidence of bugs going up as you have all these unintended interactions of features, I see it no longer being used in academia, not being the de facto research language when you want to take a language and write a very simple calculus for it so you can do tight theoretic work, basically all of these things were done because Java was a reasonably small, reasonably simple language and I think that if it ceases to be so, then Java will lose that stature.

Rod Johnson: One quick comment I can't resist making - in 1995 Java was a very small language, was very easy to understand, and was also completely useless for any purpose whatsoever. At that time C++ was infinitely more useful in actually doing practical things, and I do think that the purity has to be balanced versus the pragmatism of actually getting things done.

If you have to use a rich IDE or some other tool in order to be able to program in a language, isn't that a bad sign?

Joshua Bloch: Good question. If you have to use a tool to program in a language for it to be pleasant, isn't that a warning sign? And, you know, it's an interesting question. That would have been so certainly some number of years ago. These days, honestly, I think if I were designing a new language I would put expert toolsmiths on board from day 1 and I would design it with tools in mind. People do program using tools and we're not going to go back to the days where they don't. That said, I am still, and I hate to admit this in public, but I am still more comfortable programming in Emacs than I am in IntelliJ. I do both, but Java is still definitely a language that you can program in Emacs and just use the command-line tools to run it. I do it all the time when I'm doing something small, that's easier for me.

[audience comment] Joshua Bloch: I should point out, by the way - I'm not running this thing, but just so you know - technically, it ends now, and in 15 minutes Dick Gabriel's going to be talking, right? So, I think we're all happy to chat longer but on the other hand everybody wants to get out in time to see Dick, so tell us when to get off the stage.

How will the next programming language change the way we look at programming?

Erik Meijer: For me that's easy to answer. I think a lot of the kind of languages, and somebody that here, you can still read a program, somebody from 1958 can still read our current programs because Java and C# and VB, it's just Fortran with different syntax, right? There's no conceptual difference between them.

Joshua Bloch: That's not quite fair!

Erik Meijer: So I think if you really want to go to a different language you have to go to a completely different paradigm, so if you want to really think differently you have to look at, say, logic programming or pure functional programming or something like that where the computational model is radically different, and that really changes your perspective.

Joshua Bloch: So I'm going to take the complete opposite tack and I'm going to say that Java changed the way the world thought. It's a really marvelous language. For the first time, the common programmer leaned that "yeah, I can write a module and prove it correct to myself in isolation and know that, no matter what my caller does, no matter what the rest of the system does, this type is not going to be compromised, the invariants on the components of my type are going to be preserved forever". It was the first popular safe language. Now when I use the word "safe language" I'm using it in the technical sense that Benjamin Pierce would approve of. So, Java did change the way you think, it changed it in other ways as well - garbage collection, and yes I know Java didn't invent any of these things, Gosling said as much, he basically said "we just took a whole bunch of good ideas, put them together, maybe threw in one or two little new ones", but for the most part it was a language that composed good ideas and did change the way the world thinks about programming. So how is the next language going to change the way I think about programming? I would hope that, all of a sudden, I won't think of my programming language and the system surrounding it as a thicket with all these thorns that I have to avoid that tear my skin off when I get near them. Basically, I feel like programming is still too hazardous an activity and I think we know enough now to write a language with far fewer hazards so long as we resist the temptation to innovate. I think if what we do has to be new and have all these great ideas we haven't tried before, then there are still going to be thorns and we're still going to get our skin torn off.

Rod Johnson: I wonder whether or not the answer -- I assume that we're not talking about another version of any existing language in the next couple of years, I'm assuming we're talking farther out - I don't think that the answer is necessarily that there will be "the" programming language. I think that we are going to see increasing use of DSLs, I think we write programs in different domains, we write programs in different environments. There fundamentally is a difference between, say, writing an enterprise program that accesses relational data and writing a thick client program that's interacting purely with GUI elements. So I'm not sure that the answer is necessarily that we're going to see other big languages that are necessarily general-purpose languages.

Charles Nutter: Well I don't have a whole lot to contribute on what the answer to this question is, how we want the next language to change the way we think about programming because honestly I don't think we'd know that until we actually saw it happening or felt it happening to us. I think what we need to do, though, is we need to realize that we're not going to find that answer just looking at Java and constantly looking introspectively at "what did we do wrong here? What can we do to change this?" We need to look at how people are solving problems in other domains, with other languages, with other tools, APIs, etc. and then see how we can apply that to Java or apply that to whatever this next language is supposed to be, or whatever the next languages are supposed to be. I doubt that it's ever going to settle on one, so we need to look outside and we need to not ask how the future of Java is going to be determined by Java's past, we need to figure out how the future of Java is going to be determined by the present state of the languages that we have available to us.

Joshua Bloch: So I agree with all of that, and especially the part about "there should always be more than one language", I hate monopolies of every sort. [laughter] I didn't mean anything personal by that to anyone in this room, I promise.

Chet Haase: So always two languages, Java and Basic. It's a little tough for me to answer because it's sort of like the flatland thing that Charlie mentioned - how are we supposed to imagine what the outside of the box actually looks like if we're part of a square. I don't know... I've had my mind changed, I'm working within the Java context, I'm pretty happy with that. I would say, one of the things that I would like to see evolve, and this lies somewhere between the language and the platform and the class libraries, is simplifying all the boilerplate stuff that we tend to do over and over again so we can think more about the problems that we're trying to solve instead of the syntactic way that we need to go about solving them. I'm from the GUI side of things, so in creating the GUI you think of all the code that you need to create the menu and the actions and all that stuff... Wouldn't it be nice if you could just think in terms of what the menu needed to do instead of all the syntactic stuff that you need to get from the beginning to the end, and I think that can be addressed, not just in the GUI space, but in a lot of different areas and I think that's been one of the evolutions in the platform in general.