4 ms·

Why don't they start now and build Java 2.0 from ground up instead of Java 10 for 2017? That would be way faster and they learned so much by now to make a grea

by sek 15y ago

Why don't they start now and build Java 2.0 from ground up instead of Java 10 for 2017? That would be way faster and they learned so much by now to make a great successor. Who wants a Java 1.x in 2040?

mahmud 15y ago
by the time the rebuilt java2.0-NG reaches stability it will be 2017, or whatever.
francoisdevlin 15y ago
Because they learned from netscape's mistake, that's why. http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- lhnz 15y ago
  "You are wasting an outlandish amount of money writing code that already exists." On the contrary, there has been a number of times that I've completely rewritten some code to use a framework or library that was already battle-tested and more fully-featured than the previous effort. I ended up saving myself from writing code that already exists.
  - anonymous 15y ago
    Right, but you're one person and you're redoing the plumbing. At this point oracle can't rewrite Java. If they don't support the current programs, nobody would use it, if they do, they will really be rewriting code that already exists.
- sek 15y ago
  I didn't say they should rewrite everything, but to make a new Java version with backward incompatibilities. Drop a new 1.x version on java for decades can't be the solution.
- moonboots 15y ago
  The netscape rewrite became Firefox.
  - shangrila 15y ago
    Yeah no kidding. That's one thing people seem to forget about that Joel article ... the new code base he's mocking went on to become the only browser capable of taking on Microsoft's juggernaut for many years. It was faster & better than everything else out there. Eventually the only thing capable of overtaking it was WebKit ... another from-scratch code base!
    - nknight 15y ago
      That new codebase was iterated on for five years before a viable browser was released, and two more before Firefox 1.0 appeared. The history of the WebKit codebase stretches back as far as Gecko. The earliest KDE HTML work I can definitively establish is in 1997. We got Konquerer in 2000, but Safari didn't emerge until 2003. 5-7 years before something other than IE could again be competitive... Do you really think that disproves Joel's point? I think it may be quite the opposite...
- InclinedPlane 15y ago
  That article is an incredibly useful warning against the temptation for casually taking code rewrites, but it's incomplete. Sometimes full rewrites are necessary and good. The trick is doing it correctly. Rewrites are riskier, more difficult, and require more development resources than greenfield development. More so when you consider that you can't just abandon the old code until the new code is mature and has proven itself. Most people do rewrites the wrong way, and they get into trouble, but that doesn't mean there isn't a right way. There are many examples of unsuccessful rewrites in history, but also many examples of highly successful ones.
protomyth 15y ago
To be fair, if you were researching computer languages and rewrites, you would be looking at Python 3.0 and Perl 6.0. I believe both will be successful in time, but for business planing, it looks like a lot of problems and a slow evolution will work better. Oracle is pretty comfortable with the slow evolution route.
- sek 15y ago
  I think Python 3.0 is really well executed. With such a big ecosystem this takes a while, but when you wait too long somebody else eats your lunch.
- kbd 15y ago
  There's no way I'd put Python 3 and Perl 6 in the same sentence. Also, IMO there's no chance of Perl 6 being successful in time (which makes me sad, because 10 years ago or so I was really hopeful about it).
  - protomyth 15y ago
    If you are some manager in a big company and looking at the press, there is little distinction. In fact, more stories have been posted about Python 2.x to 3.x conversions (mostly because Perl 6 is not a story). Heck, I would imagine a couple of people on HN have run into the "can't use Python 3 because it isn't compatible with anything"-meme. Carefully considered logical analysis with realistic risk mitigation gets trumped by headlines in ComputerWorld and InfoWorld quite often. I still have quite a bit of hope for Perl 6. I use Perl 5 as my goto short scripting language. I really want it to work.
    - kamaal 15y ago
      You are not getting it, Perl 6 is not designed as a successor to Perl 5 but as a Age proof Perl. Think of it like pg called a hundred year lisp language. Perl 6 might be the age proof Perl language. When you have such and ambitious goal the time taken is worth to fulfill it. Larry wall figured out quite a while back evolving Perl 5 may fix some warts but it won't solve the larger problem. The larger problem today is doing language extensibility sane-fully. There are no C based languages that are as much extensible as a Lisp based languages. Perl 6's larger aim is to solve that. While retaining the 'Perl factor'. Re write is inevitable if you have to solve this problem, no matter what joel says you have to rewrite a few things to fix them. The incremental path is too slow and you will loose out on time while somebody eats your lunch. Perl 5, Python x.0 and Ruby x.0 series are all great languages but eventually on the very long run they will be plagued with the same technical problem every language runs in to. Providing sane ways of extensibility without bloating too much. IMO Perl 6 will do well, for the same reasons Lisp has done well.
soc88 15y ago
Isn't that what Scala already does quite successfully for a while now?
noselasd 15y ago
Because backwards compatibility matters more. There's anyway many other alternatives to Java if you need something else but still use the JVM.

by sek 15y ago

mahmud 15y ago

by the time the rebuilt java2.0-NG reaches stability it will be 2017, or whatever.

francoisdevlin 15y ago

Because they learned from netscape's mistake, that's why. http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

lhnz 15y ago
"You are wasting an outlandish amount of money writing code that already exists." On the contrary, there has been a number of times that I've completely rewritten some code to use a framework or library that was already battle-tested and more fully-featured than the previous effort. I ended up saving myself from writing code that already exists.
- anonymous 15y ago
  Right, but you're one person and you're redoing the plumbing. At this point oracle can't rewrite Java. If they don't support the current programs, nobody would use it, if they do, they will really be rewriting code that already exists.
sek 15y ago
I didn't say they should rewrite everything, but to make a new Java version with backward incompatibilities. Drop a new 1.x version on java for decades can't be the solution.
moonboots 15y ago
The netscape rewrite became Firefox.
- shangrila 15y ago
  Yeah no kidding. That's one thing people seem to forget about that Joel article ... the new code base he's mocking went on to become the only browser capable of taking on Microsoft's juggernaut for many years. It was faster & better than everything else out there. Eventually the only thing capable of overtaking it was WebKit ... another from-scratch code base!
  - nknight 15y ago
    That new codebase was iterated on for five years before a viable browser was released, and two more before Firefox 1.0 appeared. The history of the WebKit codebase stretches back as far as Gecko. The earliest KDE HTML work I can definitively establish is in 1997. We got Konquerer in 2000, but Safari didn't emerge until 2003. 5-7 years before something other than IE could again be competitive... Do you really think that disproves Joel's point? I think it may be quite the opposite...
InclinedPlane 15y ago
That article is an incredibly useful warning against the temptation for casually taking code rewrites, but it's incomplete. Sometimes full rewrites are necessary and good. The trick is doing it correctly. Rewrites are riskier, more difficult, and require more development resources than greenfield development. More so when you consider that you can't just abandon the old code until the new code is mature and has proven itself. Most people do rewrites the wrong way, and they get into trouble, but that doesn't mean there isn't a right way. There are many examples of unsuccessful rewrites in history, but also many examples of highly successful ones.

protomyth 15y ago

To be fair, if you were researching computer languages and rewrites, you would be looking at Python 3.0 and Perl 6.0. I believe both will be successful in time, but for business planing, it looks like a lot of problems and a slow evolution will work better. Oracle is pretty comfortable with the slow evolution route.

sek 15y ago
I think Python 3.0 is really well executed. With such a big ecosystem this takes a while, but when you wait too long somebody else eats your lunch.
kbd 15y ago
There's no way I'd put Python 3 and Perl 6 in the same sentence. Also, IMO there's no chance of Perl 6 being successful in time (which makes me sad, because 10 years ago or so I was really hopeful about it).
- protomyth 15y ago
  If you are some manager in a big company and looking at the press, there is little distinction. In fact, more stories have been posted about Python 2.x to 3.x conversions (mostly because Perl 6 is not a story). Heck, I would imagine a couple of people on HN have run into the "can't use Python 3 because it isn't compatible with anything"-meme. Carefully considered logical analysis with realistic risk mitigation gets trumped by headlines in ComputerWorld and InfoWorld quite often. I still have quite a bit of hope for Perl 6. I use Perl 5 as my goto short scripting language. I really want it to work.
  - kamaal 15y ago
    You are not getting it, Perl 6 is not designed as a successor to Perl 5 but as a Age proof Perl. Think of it like pg called a hundred year lisp language. Perl 6 might be the age proof Perl language. When you have such and ambitious goal the time taken is worth to fulfill it. Larry wall figured out quite a while back evolving Perl 5 may fix some warts but it won't solve the larger problem. The larger problem today is doing language extensibility sane-fully. There are no C based languages that are as much extensible as a Lisp based languages. Perl 6's larger aim is to solve that. While retaining the 'Perl factor'. Re write is inevitable if you have to solve this problem, no matter what joel says you have to rewrite a few things to fix them. The incremental path is too slow and you will loose out on time while somebody eats your lunch. Perl 5, Python x.0 and Ruby x.0 series are all great languages but eventually on the very long run they will be plagued with the same technical problem every language runs in to. Providing sane ways of extensibility without bloating too much. IMO Perl 6 will do well, for the same reasons Lisp has done well.

soc88 15y ago

Isn't that what Scala already does quite successfully for a while now?

noselasd 15y ago

Because backwards compatibility matters more. There's anyway many other alternatives to Java if you need something else but still use the JVM.