Bear Bibeault wrote:Java's dedication to backward compatibility is a double-edged sword.
Bear Bibeault wrote:Or maybe just a change of mindset where deprecated really means it. Things marked as @Deprecated in Java x are gone in Java x+1; in other words, you have one version to get your act together. Two version to be really permissive, but I'd prefer to see a 1-version cattle prod.
Bear Bibeault wrote:Java's dedication to backward compatibility is a double-edged sword. It makes it easier to upgrade to a new Java version without too much concern about breaking things, but it offers little in the way of carrots to urge people to abandon old ways and adopt the new. Simply marking things as deprecated is pretty weak and easily ignored.
Having been working in the JavaScript sphere for some time now, I think most Java devos are somewhat spoiled by Java's backward compatibility. Outside of the Java environment, breaking things with new versions is not unheard of, and it's expected that developers will need to fix broken code when something breaks as the price paid for moving forwards. That's not to say it's done willy-nilly -- there's got to be a good reason to break compatibility -- but it's not see as a cardinal sin the way that it is in the Java ecosystem. And as such, things move forward at a much faster pace.
For Java, I can't help but think that there's something in between. Perhaps a way that makes it harder, but not impossible, to use deprecated elements such that the path of least resistance is to use the new stuff. I'm not sure what that is, but it'd be nice if it existed.
Just look at the state of JSP. More than 12 freaking years after the introduction of the JSTL and EL, people are still putting JSP1.x-style scriptlets in JSP. Why? Because there's nothing to slap them on the wrist and say "no". If it were up to me, adding scriptlets to a JSP would require a Byzantine change to configuration such that it could be done for legacy apps by those savvy enough to figure out how, but out of the box, almost impossible to accomplish. So, it'd actually be far easier, especially for novices, to just do it right in the first place.
But I'm such a dreamer...
Jesper de Jong wrote:
Bear Bibeault wrote:Or maybe just a change of mindset where deprecated really means it. Things marked as @Deprecated in Java x are gone in Java x+1; in other words, you have one version to get your act together. Two version to be really permissive, but I'd prefer to see a 1-version cattle prod.
I would like that, but then you'd get the other side of the double-edged sword: companies would stick even longer (than they already do) to an outdated Java version, because they don't want to invest time and money in updating all their software to the latest version.
Bill Clar wrote: Fortunately, this means we'll all have jobs for the next 20-40 years.
Pat Farrell wrote:My only real solution is to stop calling it Java, maybe Java++, so the new stuff can throw away the 15+ year old crap.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:As soon as you modify a piece of old source, you are obliged to use the new semantics, but otherwise the 'new javac' can still deal with old source code via the old compiler.
Then, you'd only have to worry about backwards bytecode compatibility which, I suspect, is far less of an issue than source code.
Bear Bibeault wrote:Java's dedication to backward compatibility is a double-edged sword. It makes it easier to upgrade to a new Java version without too much concern about breaking things, but it offers little in the way of carrots to urge people to abandon old ways and adopt the new. Simply marking things as deprecated is pretty weak and easily ignored.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Martin Vajsar wrote:How would the compiler know that the code being compiled was or wasn't modified after the introduction of Java++?
I think that lots of the 'horrible' generics features exist because of the bytecode compatibility. But I may be wrong.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Martin Vajsar wrote:I think that lots of the 'horrible' generics features exist because of the bytecode compatibility. But I may be wrong.
Winston Gutkowski wrote:
Martin Vajsar wrote:How would the compiler know that the code being compiled was or wasn't modified after the introduction of Java++?
Not sure, but I can't imagine that a "Day 0" date would be too difficult to implement and then check against file mod timestamps; or indeed, introduce a new annotation ("@Java++' ?) for new source - although that would go against Bear's idea of obliging people to use the new syntax. Dunno...maybe a combination of the two...
Pat Farrell wrote:
Bill Clar wrote: Fortunately, this means we'll all have jobs for the next 20-40 years.
Yuck. Who in the world would want a job doing maintenance on 40 year old code written in a dead language? How many young programmers are dying to get jobs doing maintenance on 40+ year old COBOL systems?
If a language doesn't evolve, while the legacy installed base doesn't go away, it is never picked for new work. I've been a professional developer for 40 years, and I've been paid to write in about 30 languages. Any programmer who is smart enough to earn a salary is smart enough to pick up a new language.
Jay Orsaw wrote:And how many people still code C that's 40 years old? :P.
Jay Orsaw wrote:I had a computer science professor say that the entire architecture of computers could change at any time
Pat Farrell wrote:
Jay Orsaw wrote:I had a computer science professor say that the entire architecture of computers could change at any time
While it is true that the probability that we will switch from a Von Neumann architecture to something else is non-zero, its also very small. Perhaps vanishingly small.
While folks toss around the term "architecture" of computers loosely, such as claiming that an ARM chip is a different architecture than an Intel X86, they still have a lot in common. The last attempt at a different architecture was Intel's VLIW machines, which failed to deliver the promised performance, and failed in the market.
If there is a wide acceptance of functional programming languages or object-oriented DBMS packages, then we could see a significant switch. But lately, all we have done is crank up the clock and add more CPU units. A 64 processor chip running Von Neumann architecture is still Von Neumann.
Bear Bibeault wrote:
Jay Orsaw wrote:And how many people still code C that's 40 years old? :P.
Many, many, many, many, many, many developers.
Ever hear of embedded systems? What do you think is running in your residential gateway? Your TiVo?
Even though Java was invented with embedded systems in mind, C still rules that roost.
Jay Orsaw wrote: Saying that in 40 years Java, or an advancement of Java wont be around isn't "impossible." C is around, and will continue to be around for a long, long time.
....C might even make it past 100 years, wouldn't that be crazy?
Bear Bibeault wrote:If there were a better-suited, more modern tool, they'd be using it.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
No more Blub for me, thank you, Vicar.
chris webster wrote:what would be the difference between "Java++" and, say, something like Scala which is already available on the JVM?
The legacy of Java will be the platform, not the language.
No more Blub for me, thank you, Vicar.
chris webster wrote:Going beyond Java 8, Neal Ford has just started publishing some articles on "Java.next"
Jay Orsaw wrote:Well I also want to add in what about FX? That seems to be where the Java world is headed, at least the Client side.
Bear Bibeault wrote:
Jay Orsaw wrote:Well I also want to add in what about FX? That seems to be where the Java world is headed, at least the Client side.
I'm sure you meant to say "Desktop". JavaFX will not be making inroads on the web as a client-side technology.
Bear Bibeault wrote:Those are still desktop apps. Sure, they are client-server in that they connect to a remote database. But they are still traditional fat-client apps rather than web-based thin-client SAAS web applications which, these days, most people will think of when you say "client".
My point is to be more precise when you use the word "client".
But if your point is just that JavaFX is taking over from Swing for the limited areas in which Swing is used, I have no insight into that area.
Jay Orsaw wrote:So you're saying the only "Server side" technology is EE, and that everything else, FX/SE is "Desktop?"
What is the difference you are trying to make in FX cannot be SaaS? IF it can use web services I thoguht that is what is needed, and the rest of the code goes ont he client.
Are you saying that when doing a SaaS you ONLY use EE and server side technologies
Does GUI work go on a server? Im confused I guess....?
Bear Bibeault wrote:And there's more to Java than JEE. The Play! Framework for example, completely eschews JEE.
Jay Orsaw wrote:Are you saying that when doing a SaaS you ONLY use EE and server side technologies, and create some sort of small client side with SE or what? Does GUI work go on a server? Im confused I guess....?
Are you better than me? Then please show me my mistakes..
Yohan Weerasinghe wrote:So does this mean the whole Java is changed? I mean even the swing, IO, Servlets, Jsp, EJB and all other stuff existed in java 7?
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Rob Spoor wrote:You can go ahead and program exactly like you used to, plus use the new classes and interfaces. Just because the new language constructs are there doesn't mean you are required to use them. However, I do think you should at least check them out a bit. I've skipped Java 5.0 and stuck to Java 1.4 for too long just because I was afraid of everything that was new. I missed out a lot back then. I haven't made the same mistake when Java 7 came out, and I won't make that mistake when Java 8 comes out.
Are you better than me? Then please show me my mistakes..
It's weird that we cook bacon and bake cookies. Eat this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
|