Campbell Ritchie wrote:As long as you don't breach that important principle:-
If it ain't broke, don't fix it.
But as a counterpoint--if it's messy, hard to understand, inflexible, low performance, or unscalable, it might very well be "broke" even if it works properly ;)
However, to the original point, I have it on reliable authority (Mark Reinhold) that more than half the effort involved in creating a new version of Java goes into ensuring it's backward compatible. You might come across something that doesn't work, but a) that's pretty darn rare, and b) it's quite likely that your code used something that wasn't "recommended" in the first place.
I have one piece of code that's caused me trouble, and that was using a pre-released version of transparent windows in Java 6. The code specifically used classes in packages sun.blahblah, rather than exclusively using java... and javax...
So, yeah, try it, you might like it.
And, you might even find you can get directly to Java 9, though I've not kept up so can't comment with confidence on whether things like the command line might change for that.
Sean Corfield wrote:If your process changes, you need to modify your objects. If your data changes, you need to modify your objects. But with either kind of change, you're changing your fundamental building blocks in a way that is intertwined.