The Artima Developer Community
Articles | News | Weblogs | Books | Forums
Artima Forums | Articles | Weblogs | Java Answers | News
Sponsored Link •

Weblogs Forum
Java: Evolutionary Dead End

92 replies on 7 pages. Most recent reply: Jan 3, 2008 9:06 AM by Bruce Eckel

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 92 replies on 7 pages [ « | 1 2 3 4 5 6 7 | » ]
Gili T.

Posts: 6
Nickname: cowwoc
Registered: Jul, 2007

Re: Java: Evolutionary Dead End Posted: Jan 4, 2008 7:59 AM
Reply to this message Reply
Advertisement
Jörn Zaefferer brings up a good point: how about breaking compatibility (when reasonable) every major release but offer tools like Retrotranslator to offer backwards or forwards compatibility?

As others have pointed out, big enterprises already takes years before upgrading to a new JDK (many still using 1.4) even though we have backwards compatibility. We might as well break backwards compatibility, provide migration tools, and let them handle this as part of their migration process.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Java: Evolutionary Dead End Posted: Jan 4, 2008 8:16 AM
Reply to this message Reply
Migration when you have the source is one thing, migration when you use third party libraries and do not have source (or for support reasons can't modify it) is rather more difficult.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Java: Evolutionary Dead End Posted: Jan 4, 2008 3:41 PM
Reply to this message Reply
One option that I have proposed:

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

is to add a source statement that you put as the first line of a file, E.G.:
source 7;
 
package ...;
 
...

This identifies the Java version and allows the language to migrate and doesn't break backwards compatibility, it all still runs on the JVM and old code can still be used and modified. A file without a source statement is by default Java 6.

A second aspect of the source proposal is that it mangles keywords so that a library from another language (that has a different set of keywords) can be used even if that library uses a Java keyword for say a method name.

Jörn Zaefferer

Posts: 22
Nickname: jzaefferer
Registered: Jul, 2007

Re: Java: Evolutionary Dead End Posted: Jan 4, 2008 5:55 PM
Reply to this message Reply
> Migration when you have the source is one thing, migration
> when you use third party libraries and do not have source
> (or for support reasons can't modify it) is rather more
> difficult.

True, though at least Retrotranslator does its work only on bytecode (class files), so as long as you can modify those, you could do without the source.

I wonder if Retrotranslator would actually work if 1.5 would've broke backwards compability to 1.4.

Could someone provide an example how 1.7 could actually break compability, on a bytecode level? From what I understand, compability would be broken when 1.6 Code couldn't run on 1.7 without recompiling, right?

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Java: Evolutionary Dead End Posted: Jan 4, 2008 6:39 PM
Reply to this message Reply
@Jörn,

> Could someone provide an example how 1.7 could actually
> break compability, on a bytecode level? From what I
> understand, compability would be broken when 1.6 Code
> couldn't run on 1.7 without recompiling, right?

In addition to compiled code compatibility they want source compatibility. In particular the new compiler will compile old source code, hence my suggestion of a source statement to allow changes to syntax.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: Java: Evolutionary Dead End Posted: Jan 4, 2008 9:31 PM
Reply to this message Reply
Taylor Cowan wrote: "When I press ctrl- and mouse over language elements, my eclipse ruby cannot figure out where to go, often landing on a method with the same name but in the wrong module. And I have empathy for the ruby IDE, as I have the same trouble, it's all so vague and mysterious..."

I've never used Eclipse, but I'm not surprised it's confused by Ruby, what with its "open" classes and modules plus the community encouraging monkey patching. But back to the topic at hand: Java...

Roger Voss

Posts: 27
Nickname: rogerv
Registered: Aug, 2005

Re: Java: Evolutionary Dead End Posted: Jan 5, 2008 2:53 PM
Reply to this message Reply
Is Java a "Dead End"? Bruce Eckel proposes locking it down and solidifying what we have - then move onto a better "next generation" language to run on the JVM.

I'm somewhat rather compelled by Bruce's proposal. But first, Bruce, before we close the lid on Java and weld it shut, could we get a few innocuous tweaks in?

strings:

I want a way to paste in multi-line text (say some SQL, XML snippets, etc) and not have to go thru gyrations to reformat it and convert it into a valid Java string literal.

In conjunction to this, I want to be able to paste in a regular expression that I've crafted using perl and not have to go through and escape all my escapes all over the place. Java should make it easy to quote regular expressions in their literal, as-is form.

Now this would be nice, but I'll cave on it if is deemed going too far:
Would like to reference Java variables from within strings, such as ${donkey}, and have the variable get interpolated and expanded to a string value when the statement containing the string is executed.

maps:
I'd like to be able to declare and initialize a map in a single statement with a list of name-value pairs.

method calls:
I'd like to pass arguments to a method and bind them to respective parameters by associating to the name of the parameter instead of being order dependent.

exceptions:
I love that proposal that would enable consolidating the catching of several exception types into one catch block.

closures:
Ah, could we just add the CICE proposal, as is very minimalistic over current anonymous inner classes?
Concise Instance Creation Expressions: Closures without Complexity
http://docs.google.com/View?docid=k73_1ggr36h

generics:
Okay, I'll say it - can we reify generics?
Reified Generics for Java
http://gafter.blogspot.com/2006/11/reified-generics-for-java.html

Alex Naanou

Posts: 2
Nickname: alexnanou
Registered: Aug, 2007

Re: Java: Evolutionary Dead End Posted: Jan 5, 2008 3:02 PM
Reply to this message Reply
What has been going on with Java for some time now is a bit contrevertial...


IMHO there are two ways to progress, step forward and advance or step back and reassess.

Developing habits, and that includes knowing and using a certain language for some time, should lead to stability. stability, in turn, is a good base for progress, if it is built upon, that is.
Stabilize a layer/language/system and abstract it out, to move on, and define a bigger more complex system in simpler terms, and that is one way to do progress (note that this approach involves first building habits and then breaking them when going to the next level).

Another way to go, is to develop to a certain stage, gain experience, learn from mistakes made and do things over differently...


both of these ways target reducing complexity by either abstraction or redesign.


what Java is doing is it promotes habits (stability) by enforcing backward compatibility and at the same time adding new stuff, thus advertising progress. this essentially means keeping all the old features while constantly adding new ones... or, in other words, working on constantly adding complexity.
one can't move forward and stay in place at the same time!


So, I totally agree that what is going on is not best, but moving to Scala might not be an effective (or radical) enough answer...


P.S. Merry Christmas and Happy New year to all! :)

Paulo Pinto

Posts: 4
Nickname: pjmlp
Registered: May, 2006

Re: Java: Evolutionary Dead End Posted: Jan 5, 2008 3:17 PM
Reply to this message Reply
I'm also afraid that the way Java is playing catchup with C# might kill the language.

Java is Java and C# is C#. This might be obvious, but when I want to program in C# I'll use it, and not Java in a C# way.

Sun seems to be somehow affected how Microsoft cloned Java to give birth to C# and now tries to cram all C# features in the language.

When languages start behaving like products having feature after feature, they start their way to oblivion. I just hope that Java doesn't follow that path.

New features are nice. Featuritis not.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: Java: Evolutionary Dead End Posted: Jan 5, 2008 5:55 PM
Reply to this message Reply
> Jörn Zaefferer brings up a good point: how about breaking
> compatibility (when reasonable) every major release but
> offer tools like Retrotranslator to offer backwards or
> forwards compatibility?
>

Don't know about Java, but with other languages (VB, Managed C++) these tools work pretty much only for trivial projects. At the end of the game people usually end up rewriting the code altogether.

Which brings me to another point - it seems that almost everybody here thinks that backward compatibility is not such a big deal, which I find (mildly put) very strange. How would you explain to your management or customers that youu need to spend their time to port code because the language became more "clean and elegant"?

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Java: Evolutionary Dead End Posted: Jan 5, 2008 7:03 PM
Reply to this message Reply
> I'm somewhat rather compelled by Bruce's proposal. But
> first, Bruce, before we close the lid on Java and weld it
> shut, could we get a few innocuous tweaks in?

Most of what you describe here falls into what I would call "cleaning up the language," fixing it rather than extending it. In general that would be a good thing, vs. adding more fundamental features which is what I argue is trouble for the language.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Java: Evolutionary Dead End Posted: Jan 5, 2008 7:08 PM
Reply to this message Reply
> Which brings me to another point - it seems that almost
> everybody here thinks that backward compatibility is not
> such a big deal, which I find (mildly put) very strange.
> How would you explain to your management or customers that
> youu need to spend their time to port code because the
> language became more "clean and elegant"?

My argument is that trying to add fundamental new features AND preserve backward compatibility produces bad new features. My previous attitude was to break backwards compatibility in order to add the feature correctly. I now think that the feature shouldn't be added if it requires compromise in order to maintain compatibility.

Java is functional; trying to add every feature will break it. If you really need those features, perhaps using another JVM language that is designed from scratch to support those features (Scala, for example) is a better choice than trying to (badly) force it into Java.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Java: Evolutionary Dead End Posted: Jan 5, 2008 9:55 PM
Reply to this message Reply
> How would you explain to your management or customers that
> youu need to spend their time to port code because the
> language became more "clean and elegant"?


The prudent thing to do is avoid porting a legacy product to a new language/framework/VM version if there's no compelling need to, even if it is supposed to be backwards compatible.

If there is a valid reason to upgrade your product, then all the necessary changes (including those triggered by incompatibilities) are just part of the overall effort. Then it's a matter of determining if the increased value of the upgrade exceeds the cost of the port.

waseem sadeh

Posts: 1
Nickname: ccoder
Registered: Jan, 2008

Re: Java: Evolutionary Dead End Posted: Jan 6, 2008 12:55 AM
Reply to this message Reply
first of all, thank you Bruce for your really important books. your books and guidance have taught a lot of people how to understand OO thinking. They also allowed a lot of developers to start even talk about OO because those developers have a model of thinking about OO paradigm in their minds.

I agree with you totally about not making the Java language more complex.
after reading your article, i have remembered two nice advices from James Gosling and Brian Kernighan.

James Gosling, in one of his important interview, said "if you want to do something, make it right and nice or just leave it out"

Brian Kernighan, in his software tools book, said "before start to build tools and solve programming problems, we have to find the most important tool which is the programming language. This tool should be simple and clean so that we can build other tools and solve major software problems. Otherwise, the programmer will just keep fighting the programming language tool instead of fighting the programming problems he has to solve"

This is exactly what is going on: instead of focusing on how to build creative tools and solve major software problems using good ideas and techniques, we are spending our time fighting the Java programming language tool.

Regards.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: Java: Evolutionary Dead End Posted: Jan 6, 2008 6:23 AM
Reply to this message Reply
> If there is a valid reason to upgrade your product, then
> all the necessary changes (including those triggered by
> incompatibilities) are just part of the overall effort.
> Then it's a matter of determining if the increased value
> of the upgrade exceeds the cost of the port.


That's what I am talking about. Introducing serious backward incompatibilities for the sake of "elegance" and "cleanup" will increase the cost of the project, and it is really hard (impossible?) to quantify the long term savings that the new/revised features will bring in. And many times sticking to the old version is simply not an option - especially if we are talking about a long-term "flagship" project rather than a "legacy" one.

I have been fortunate to work with a prety stable language (C++), but even the relatively small changes that bring modern compilers closer to the Standard (like introducing two-phase name lookup with g++ 3.4) are sometimes very painful even if they are necessary in this case.

Flat View: This topic has 92 replies on 7 pages [ « | 1  2  3  4  5  6  7 | » ]
Topic: Java: Evolutionary Dead End Previous Topic   Next Topic Topic: Can iTunes Accomplish What Jini Couldn't?
Sponsored Links


Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use