Java Community News - Bill Venners on the Future of Java

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Java Community News
Bill Venners on the Future of Java

16 replies on 2 pages. Most recent reply: Mar 5, 2007 8:24 AM by Paul Gresham

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 16 replies on 2 pages [ 1 2 | » ]

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Bill Venners on the Future of Java

Posted: Feb 21, 2007 1:19 PM

Summary
At the 2006 JavaPolis conference, Ted Neward interviewed Artima president Bill Venners. The interview, which was recently made available as an online video, focuses on Java's evolution into the future, and discusses how Java can evolve without breaking backwards compatibility and without cluttering up the language.

Bill Venners, Artima's founder and president, was interviewed by Ted Neward at the 2006 JavaPolis conference. The video of the interview was recently made available online. In the interview, Venners focuses on a range of topics related to Java's evolution, including the question of how to evolve the language without adding more clutter to it:

The natural law of programming language design is that as time goes by, it becomes harder and harder to enhance the language, because as the language grows, there’s more stuff to be backwards compatible with. To what extent are people going to break backwards compatibility?

[Breaking backwards compatibility] costs money, and I don’t like that. I used an API [from an ISV]... and they cleaned up method names in a new API version, but didn’t deprecate the old methods... Those methods were just gone. So they broke code [that I wrote against that API]. It was painful, it cost money.

The Java community is so vast, and it’s such an important language in commerce, that it’s not easy to break backwards compatibility. Backwards compatibility is very important.

But there is a cost to not breaking it—which is added clutter. If you can just delete deprecated things, that makes the language smaller... Of if you could put clone() in Cloneable. That would make things cleaner and more slick, but you can’t [do that].

So what can we do? I’m very heavily invested in the Java platform, and I’m going to stay there. But how can I do better?

I stumbled onto this language called Scala... Scala is completely incompatible with Java source code, but it’s compatible with Java class files. So that made me think: Should we keep Java stable so that it’s easier for other languages to proliferate? [Those languages] would have to map to existing features of Java, and not keep up with new features of Java, which may not be very easy. And [then we could] start using other languages...

What do you think of Venners' comments on the tension between adding new features to Java and keeping clutter in the language at bay? What is your prediction for the future of Java?

Posts: 55
Nickname: lazydaze
Registered: Feb, 2006

Re: Bill Venners on the Future of Java

Posted: Feb 21, 2007 4:02 PM

If cluttering the language was bad news, breaking backwards compatibility would be an unmitigated disaster.

No one thinks of changing the syntax or standard libraries in C. It's a fine language that's that's been left alone because people moved on to newer languages when the paradigm shifted. But it's nice to know it's still there for OS's, embedded systems etc.

Same with Java. For what it does, it's great exactly as it is. Leave it alone.

The real question for me is: what is it about Java that people can't let go of?

It's like some ancient Chevy we're still driving around, convinced that if we keep patching it up it'll be as good as this year's model. We're kidding ourselves.

Andreas Andreakis

Posts: 3
Nickname: andreasa
Registered: Feb, 2007

Re: Bill Venners on the Future of Java

Posted: Feb 21, 2007 11:47 PM

I agree with Bill. Enterprises which have already invested in Java cannot or dont want to effort backward compat ibility issues, when upgrading to a new Java Version.

So even if future Java Versions break backward compat a lot of folks will simply not upgrade.

Instead JVM Languages such as Groovy, Scala, etc. will be used, which can coop with existing Java Classes.

Also, Sun is trying hard to push the "JVM Plattform". invokedynamic,Groovy, JRuby and BeanShell are some related keywords.

Jürgen Rose

Posts: 3
Nickname: mauli
Registered: Dec, 2005

Re: Bill Venners on the Future of Java

Posted: Feb 22, 2007 1:06 AM

I'm not sure if the language itself is a problem. Any decent programmer can pick up the syntax of a new programming languages in a few days or weeks and can start coding. But the investment in the libraries is much bigger then in the language itself. The question is more of like "Do we want to be able to compile our old code?" or is it just a matter of using the existing libraries which will be fine as long as with the new language it is possible to use them. Best example is .NET where there is a multitude of languages which share the same libraries. One could actually imagine to have, say a Java 7 and a Java 8 where 8 is not syntax compatible with the version before, but you could have tools which transforms the code from one version to another.

But if the API itself changes, it is much more painful. Maybe it would be a good idea to separate the API completely from the language itself? One release of an API could get new features (with new versions of the API), but never brake anything existing ones. If over the time, new ideas about the design of the standard library will accumulate, then a new API could be released. I would imagine that those release cycles would be much longer, maybe something around 5-10 years. So everybody has enough time to choose and decide which path to go. Maybe those API releases would be in sync with backwards incompatible changes in the bytecode format?

I think the most difficult changes are in the area of very widely used, standard datatypes like Date for instance. I just hate the java implementation and handling of it. But it is not so easy to just replace it. Even if something new is developed (JSR 310) then the old classes will still be around and used. A new API release could only include the new classes and leave the clutter behind.

Kevin Wright

Posts: 1
Nickname: kwright
Registered: Jan, 2007

Re: Bill Venners on the Future of Java

Posted: Feb 22, 2007 4:55 AM

Deprecation in the API is not the big problem, deprecated classes/packages could simply be moved to a deprecated.jar or backcompat.jar library that can be used only when necessary (clutter by opt-in).

I think the main issue is at the JVM level. Many people I know would *love* to see .net style attributes/generics in java (instead of stripping them out at compilation), but this is simply not possible at an API level, not if you want to keep such facilities available across multiple languages running against the same VM.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Separating the API from the language

Posted: Feb 22, 2007 6:04 AM

@Jurgen

>Maybe it would be a good idea to separate the API completely from the language itself?

That's an interesting idea, I think Java began with it, and it is slowly moving away from it.

Think about features like the new for loop. In order for the compiler to handle the new for loop it has to grok the Iterable interface. Likewise with autoboxing. The compiler must be aware of the wrapper object types.

Doing this changes the coupling from being unidirectional between from the library to the language to being bidirectional.

Is this bad? I personally like the for loop and autoboxing. It makes me type less. But we all know increased coupling makes change harder.

I think dynamic languages are more likely to have coupling between the language a the standard library. It can make basic programming tasks much easier. But it has a cost.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Separating the API from the language

Posted: Feb 22, 2007 6:53 AM

> >Maybe it would be a good idea to separate the API
> completely from the language itself?
>
> That's an interesting idea, I think Java began with it,
> and it is slowly moving away from it.

Really? I don't know the primordial history of Java (I started with 1.1) but basically the entire language is built around the Object class and literal string support is built around the String class. You can't create a running Java program without referring to both of these classes in one way or another. Then we have the Class class and that's completely tied into the JLS.

Personally I think Java jumped the shark with version 1.5 when it started coupling so much syntax to the JDK. I like generics in general but the Java implementation adds too much complexity for what we get from it. For me, Java 1.4 was the sweet spot in terms of syntax. The only thing that I would want to add to that version would be function pointers.

I think if people really realized how well languages can integrate with Java they would be less worried about fixing Java and more about finding a better language for their needs.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Separating the API from the language

Posted: Feb 22, 2007 9:15 AM

>Personally I think Java jumped the shark with version 1.5
>when it started coupling so much syntax to the JDK.

Ok, that probably is a more accurate characterization, albeit with negative connotations that are not universally shared.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: Bill Venners on the Future of Java

Posted: Feb 22, 2007 10:58 AM

I don't think that changing syntax and API for a new version would be such a big problem - users who want to stay with a previous version don't have to upgrade. I've seen this with C++.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Bill Venners on the Future of Java

Posted: Feb 22, 2007 5:04 PM

1 - back around 1983, while COBOL/85 was being specified, there was a CIO (not sure what title was used then) at one of the big insurance companies who scuttled some (may be all that mattered, don't know) of the modernization of the language. He insisted that it should stay as '68. Backwards compatibility was the cry.

2 - java 1.1 brought inner classes. But only sort of. To immunize the JVM, inner classes are a compiler fiction done by manipulating visibility. Backwards compatibility was the cry.

3 - all the noise about closures follows from 2.

4 - the folks in 1 are the same ones who still use 1.2.2 and 1.3.1 and refuse to upgrade. The coders are voting with their feet in that melieu, reasonably not wanting to be stuck being a COBOL programmer in lower case. "Enterprise java" is now COBOL. I said it before Bruce Tate, he just had a publisher.

5 - both my editor, SlickEdit, and debugger, jSwat require 1.6. go figure.

6 - -bootclasspath is a required skill in the EE arena. I got bit by the StringBuffer.append in 1.4. I didn't then, or now, feel that we need to any more than -source -target on javac. It could figure out how to generate 1.3.1 code for 1.5/.6 syntax. Might be a messy and slow to compile and run I suppose; spur the clients to upgrade. But, no. OTOH, if you keep old jars around, you can get away with it. Just write 1.3 code. Or 1.2.2

7 - the notion that any HL language can run on any machine (real or virtual) is only true by mandate. Intel may get away with it on real, and Sun on virtual. M$ found that making VB "compatible" with the Cs wasn't feasible at the syntax level. Still a lot of VB5/6 code being written. May be others can shoehorn other types of languages into the JVM, but I have my doubts.

8 - the killer issue is multi-processor. For commercial apps, this may be a blessing for database vendors. These things really already know how to play with such machines; they've been doing it for years. The paradigm of putting all logic (of record; replicated elsewhere mayhaps) in the database, and just presentation on the client; could be the winner.

9 - if 8 turns out to be true, then spinning presentation code out of the datastore (MDA on steroids) looks yummy. If so, then the source language really doesn't matter. What matters is the declarative syntax. Prolog, anyone?

Arthuro Toscano

Posts: 11
Nickname: arthuroz
Registered: Oct, 2006

Re: Bill Venners on the Future of Java

Posted: Feb 22, 2007 10:45 PM

There are lots of languages for .NET. Are they used by MSFT-developers? Not at all. > 99% of all MSFT-developers are using C# or VB.NET. There is no such thing like language-diversity in the .NET-community. I don't know the exact reason why but there's much more interest in the Java-community for language-diversity. Why is it? Do you have an idea?

Posts: 55
Nickname: lazydaze
Registered: Feb, 2006

Re: Bill Venners on the Future of Java

Posted: Feb 23, 2007 5:03 AM

Bill also mentioned that he thought the marketplace should be left to determine which languages emerge as an alternative to Java.

I think that one of the good things about Java is that, because it was 'annointed' by Sun, its popularity has spawned a huge amount of knowledge and libraries based around one language, which has big advantages. If I've got a problem, someone else has had that problem before and I can google a solution or pull in a jar quickly. And of course every programmer knows Java, making it easier for companies to resource staff.

Of course I'm not averse to the idea that the best languages should naturally rise to the top, and I love the idea of self organizing chaos, but in practice there's so much investment and inertia that that kind of fluid adoption doesn't happen easily. At the risk of getting lost in metaphors, the cream doesn't rise to the top if the milk is frozen. I think sometimes it needs a major player to make a bold move that allows programmers and companies to have confidence to invest time and effort committing to a new language. Languages like Scala point the way technically, but being good technically, altho necessary, is not sufficient.

In any case, something big's gonna happen in the next few years. My bet's are on Sun announcing 'Functional Java', based on Scala's excellent work, with binary compatibility but not source compatibility with Java. I'll probably lose my money, but it'd take the world by storm.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Langauge Diversity on JVM

Posted: Feb 23, 2007 1:33 PM

/* There is no such thing like language-diversity in the .NET-community. I don't know the exact reason why but there's much more interest in the Java-community for language-diversity. Why is it? Do you have an idea?
*/

I would bet that more Java programmers come from a UNIX background (and are comfortable writing in more than one language) than can be said for C# programmers. Not that many more, but more.

Microsoft has declared C# the best langauge for Windows development, VB.Net the best blub language for Windows development ( http://www.paulgraham.com/avg.html defines "blub language") and ASP.Net is the best language for Web development on Windows servers. Again, I'm not saying this, Microsoft's marketing department has, and .Net programmers believe them.

Sun's marketing department has done something similar, but a few more Java programmers use Linux or Mac OS X or Windows than use Solaris, so they don't buy the *whole* story.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Bill Venners on the Future of Java

Posted: Feb 28, 2007 12:10 AM

I have proposed an extension to Java that I think will help allow the language to be extended without breaking old code:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519124

The idea is to add a source statement that informs the compiler which version of java the source is written in. That way new keywords can be added for new features and the code can still be compiled because the compiler knows what version of code it is dealing with and hence what is a keyword and what isn't.

E.G. Scala like features like self typing could be added with the new keyword self. Say this happens in 7, then a source 7; or above would recognise self as a keyword and older code without a source statement could still use self for identifiers.

Calum MacLean

Posts: 9
Nickname: calummacle
Registered: Feb, 2003

Re: Bill Venners on the Future of Java

Posted: Mar 1, 2007 4:01 PM

I haven't got any deep thoughts on this. But I sometimes wonder if a goal of language design should explicitly be to allow for the language to evolve - for new features to be added while old clients can still use the old version alongside the new version.

But, as I say, I don't know how this would be done in practice.

Flat View: This topic has 16 replies on 2 pages [ 1 2 | » ]

Previous Topic

Next Topic