Home

javax: Suggestion for Including New Language Features

Submitted by Roland Carlsson on Fri, 2009/03/20 - 4:42am
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Technorati
Tags:

We Recommend These Resources

Tutorial: Event Processing with GlassFish ESB

Transactions, Clustering, OSGi and ServiceMix, the Open Source ESB

Six Steps to Signing your Java Code

How Java Developers Can Write Great SQL

For a while now, a lot of people have expressed a lot of opinions about how to keep the Java language up to date with other languages like C#, Groovy, Ruby etc etc. Some want features that they belive would make their life a lot simpler. Others see the same features as a problem that would make their life more complicated. The problem is simple, one solution can't never make everyone happy. Some people hate to type and therefore would like the shortest syntax possible, while other would focus on other problems that in their eyes dwarfs the gains with a short syntax.

The only solution that I can find for this problem is not to make everyone using the same solution but to allow programmers to choose if they would like the Java-language to work. In java (the libraries) we already have a solution for this. Packages that starts with Java are standard, while other packages that could be considerd more experimental are are named javax. I would therefore suggest a simular solution for the Java language. Files named .java are using the same old (slowly evolving) java as usual while those who like to live on the edge using files named .javax. .javax files could have a kind of import-statement for language-features that would tell the compiler what to expect in the file. 

 There are ofcourse several problems that must be solved. The most important is of political nature. Why should any company allow their programmers to use these new language-features? One solution could be that Sun packages some of these .javax features with the JDK as extensions that they would recomend of think could be close to inclusion to the standard java language. 

 The main point of the suggestion is to find a way to allow Java to evolve quickly without getting a bloated language.

Article Type: 
Opinion/Editorial
0
Average: 2 (1 vote)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ricky Clarkson replied on Fri, 2009/03/20 - 5:23am

"Some people hate to type and therefore would like the shortest syntax possible"

Actually, it's more that we hate to read irrelevant code.  Compare Java:

Runnable runFoo = new Runnable() { public void run() { foo(); } };

to C#:

Action runFoo = foo;

If there were people who actually wanted the shortest syntax possible, there'd be requests to get J syntax into Java.  There aren't, so it's not that.

Jeroen Wenting replied on Fri, 2009/03/20 - 7:31am

And what are you going to do when some idiot uses those 'features' (they're not, they're design flaws) like 'closures' and 'properties' and dumping the code on you afterwards? Because that's what's going to happen sooner rather than later. That's precisely why people are opposed to such idiotic language 'enhancements', you have to use them whether you want to or not. The feature addicts have been using your argument that 'you don't have to use it if you don't want to' for years and it just isn't true.

Tracy Nelson replied on Fri, 2009/03/20 - 8:16am

And what are you going to do when some idiot uses those 'features' ... and dumping [sic] the code on you afterwards?

 What's the difference between that and someone deciding to use Spring or Hibernate or JPA or XML or any other "foreign" technology?  I'm sure at one time or another everybody's gotten stuck maintaining someone else's toy "research project" (like a web service implemented as a JSP that just forwards requests to a CGI script written in Perl, just to flog a personal horror story). Language extensions are rarely as bad as what people can come up with to emulate them if they're not there.

Brian Diekelman replied on Fri, 2009/03/20 - 8:22am in response to: jwenting

Did you seriously just call closures a design flaw?

Mario Cormier replied on Fri, 2009/03/20 - 9:35am in response to: d3ik

I had the same reaction.  Maybe the design flaw was that they were dropped from the language early on for external reasons.

Mathias Ricken replied on Fri, 2009/03/20 - 1:37pm

I really can't stand the "but someone will abuse that feature, and you will have to maintain the code, so don't include the feature" argument. There will always be bad programmers and bad code. We should focus on good to average programmers, and most of the language change proposals improve the code these programmers can write.

Werner Keil replied on Sat, 2009/03/21 - 12:16pm

Compared to C#, Delphi and a couple of other (dynamic, domain-based) languages, Java has a great lack of Business support due to missing true Money or Currency support. One might say java.util.Currecy does the job, but it did it about as well as the previous US president ;-/ Even people who once worked on some of those features at Sun or the JCP agree, this could be solved better and should have been ever since. After all, people like Erich Gamma introduced a more complete set of monetary classes with JUnit. Unfortunately even they kept this "Pattern" in JUnit, but nobody ever used it properly in the JDK. Thus Thousands of more of less mature implementations of the same problem exist out there. And probably 75% of those must have died following the recent banking crisis (not to say some caused it ?;-|)

Artur Biesiadowski replied on Mon, 2009/03/23 - 4:14am in response to: catmedia

Don't worry, investment banking is generally not interested in money class. Most of the work is done on doubles, some of fixed point offsets with integers/longs, some on strings and very very few on BigDecimal/Money-like classes. It is probably (I hope) different in private banking, back office accounting etc. But stay with javax.money.MoneyBloat objects out of derivatives.

 

As far as original poster is concerned - there is an idea of adding source/encoding keywords on top of files to allow extensibility of language

http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000249.html

Anyway, I don't think it makes much sense. If you allow something, you have to be prepared to deal with it, so you can as well add it to main language. If you don't want to add it to main language, use .scala or something similar :)

 

Brian Sayatovic replied on Mon, 2009/03/23 - 5:55pm in response to: htowninsomniac

Good point.  No matter how fool-proof you make it, there's always a better fool.  I've been amazed at the output of so called "bad programmers", even back in the Java 1.1 days.  The only way to stop them from making bad code is to remove their keyboards.

Robin Bygrave replied on Mon, 2009/03/23 - 7:48pm in response to: abies

This makes a lot of sense to me.

This means that you can add a lot of new features (new keywords/syntax) without backward compatibility worries (or at least hugely reduced backward compatibility worries).

My understanding is that it is going to be rather difficult to add new keywords without doing something like this.

I think it would be different if scala say, was a lot more similar to java than it is... I think scala is almost a different mindset... and I think we need to keep the java language developing/evolving.

 

Ibrahim replied on Wed, 2009/03/25 - 6:21am

I strongly oppose any Java language branch in any way. I worriedly watch new Java versions that every feature request dangers language stability. I am on the side that believes most of new features are "syntactic sugar". Especially, the fear to compete with dynamic languages would lead Java to lose its identiy and nature. There are numerous lines of code out there and please consider migration cost with every new Java version. I want Java to be long-standing not trendy.

Tom van Breukelen replied on Wed, 2009/03/25 - 7:32am

I fully agree with Ibrahim. Also, the idea that we should extend the Java syntax rules, just because other programming languages have them is IMHO a waste of time and resources. Today I looked f.e. at the Java 7 specs and noticed with great "awe" that in Java 7 you'd no longer have to type: HashMap map = new HashMap (); but can use HashMap map = new HashMap(); instead Fantastic, isn't it? Now I can replace the old declaration to the new declaration in all my existing Java code. What a brilliant idea and how much time I will save (I only need to check 5 million lines of code)! Maybe in Java 8 we'll be able to use the following syntax: HashMap map = new HashMap(); Just kiddin'. I like the Java language and there might some features that could be really worthwhile to add, but I really wish that they'd focus on more important issues, like spending time on improving Swing instead of JavaFX.

hookfi replied on Sun, 2009/05/31 - 7:50am

ED Hardy Cheap ED Hardy ED Hardy Clothes

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.