• Post Reply Bookmark Topic Watch Topic
  • New Topic

don't freak out

 
Randall Twede
Ranch Hand
Posts: 4519
6
Java Python Scala
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The people who wrote java 8 must have thought hard about it. I hate to admit it, but they are better at it than me. Like someone said, if you don't like it. Don't use it. Java1 code will still run in java8
 
prateek shaw
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes correct , in java as programming language it support backward compatibility. Which i feel better than compile one and run anywhere.
Since java is backbone of a lot of things therefore it make sense that old code should run on new code.

The biggest example is Generic. Before Java 5 , the collection only support raw type. But introduction of generic was big changed by that time but i feel they did splendid job. All allow collection to work with generic too.



And in 7 they move one step further and even below code will compile.



This is just an opinion, i do agree with you !
 
 
Campbell Ritchie
Marshal
Posts: 52519
119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
prateek shaw wrote:. . . But introduction of generic was big changed by that time but i feel they did splendid job. . . .
Disagree. Introducing things like ? extends ... in order to maintain backwards compatibility makes Java┬« generics a right mess.
 
Stephan van Hulst
Bartender
Posts: 6583
84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Introducing things like ? extends ... in order to maintain backwards compatibility makes Java┬« generics a right mess.

This was not done to maintain backwards compatibility. This is inherent to generics. For instance, C# uses the out and in keywords for covariance (extends) and contravariance (super) respectively.

Erasure was done to preserve backwards compatibility. While many believe erasure is horrible, I do think they made it work as well as they could.
 
Campbell Ritchie
Marshal
Posts: 52519
119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:. . . Erasure was done to preserve backwards compatibility. . . .
Mistake acknowledged. I am one of those who think erasure is, if not horrible, not a good solution. They kept saying they were going to prohibit raw types in hew code, but haven't implemented that intention.
 
Tim Holloway
Bartender
Posts: 18408
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Java's stability is one of its most compelling features. VB people got burned when .Net came out. Python is struggling with the transition from Python 2 to Python 3. Longtime fans of mine will have heard the story about the 1-line emergency middle-of-the-night change to a C application program that not only required installing and patching an ancient IDE, but almost needed installing and patching an ancient OS.

And it doesn't stop there.

Java is pretty much unique in that it supports a deprecation mechanism. You can mark code as deprecated, continue to support it, but the compiler will discourage use of it. That can be invaluable when you need to do an emergency repair on a legacy system. You can get your hotfixes in, then go back at leisure and upgrade the code properly. Or at least you could if you weren't expected to be "giving 110%" and didn't have leisure. 

 
Stephan van Hulst
Bartender
Posts: 6583
84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:They kept saying they were going to prohibit raw types in hew code, but haven't implemented that intention.

Yeah that's unfortunate. I don't believe there is any legitimate reason to use raw types in new code.
 
Campbell Ritchie
Marshal
Posts: 52519
119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:. . . Java is pretty much unique in that it supports a deprecation mechanism. . . .
It is an improvement on the deprecation mechanism in Eiffel. Meyer says you should mark code as obsolescent and six months later mark it as obsolete, when you can remove it from the code. That means you can have an app which ran happily for twenty years and somebody removes code from a dependency and whoever created the app originally is not available to correct the error
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!