So is it still Java?

[Pat Farrell]

Nice article about Java 8:
http://www.techempower.com/blog/2013/03/26/everything-about-java-8/

It describes a lot of the functional programming styles that are now part of Java 8. Lambdas being the biggest change (IMHO).

Code written with these new features will look very different from traditional Java. So much so that I question if its still Java.

[Jesper de Jong]

It's Java by definition, but it's different from "old-fashioned" Java.

There are a lot of new, interesting features. Some of them look like they've been inspired by Scala, and some things seems to come from Google Guava, and ofcourse java.time which comes directly from Joda Time.

What's unfortunate is that there's still a lot of legacy stuff in the standard Java library, and it's growing. Now we're going to have to tell people for years that they shouldn't use java.util.Date and java.util.Calendar anymore. Those classes will continue to exist and won't even be deprecated, because it would give too many warnings for existing code.

It would be nice if there would be a way they could get rid of the legacy stuff. Maybe in Java 9, when we'll hopefully get the module system. Put all the legacy stuff in a legacy compatibility module.

[Pat Farrell]

Number one on my list of "legacy" or backward compatible stuff that I wish would go away are all the hacks to make Generic's be backward compatible. Type-erasure, strange syntax, etc. are all evil. Why does a way to improve type safety need a 500+ page FAQ? Clearly the design is broken.

[Bear Bibeault]

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...

[Pat Farrell]

Bear Bibeault wrote:Java's dedication to backward compatibility is a double-edged sword.

Well, there is the standard joke: Q: How did God make the whole universe in 6 days? A: no installed base.

I like things that have a version or two of upward and backwards compatibility. Java's problem is that they have no concept of deprecating really bad ideas in the language, and rarely deprecate bad parts of the libraries. Having two Date classes, one for Sql and a main one is terrible. This is separate from the simple fact that Date was a terrible class when it was introduced with Java 1.0, and while in theory was replaced by Calendar, it still has places where you have to use it.

My only real solution is to stop calling it Java, maybe Java++, so the new stuff can throw away the 15+ year old crap.

[Bear Bibeault]

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 agree that making incompatible changes without at least a single version buffer would be too harsh, and is not really necessary to foster the goal of herding people forward. But really -- things that have now been deprecated in multiple versions just need to go away soon.

[Jesper de Jong]

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.

[Bear Bibeault]

Too true -- and you'd know it would happen: there are still companies that mandate the use of IE6 even though even Microsoft has said for years that it's dead as yesterday.

But at least those companies would only be hurting themselves while the rest of us could move on.

[David Blaine]

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...

Yes, I completely agree. Why don't they remove the deprecated stuff and let people continue using their old Java libraries, JVMs etc ? If people want to live in the age of Java 1.3, then let them live there.

[David Blaine]

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.

I think I get what you said. If Java forces its users to change their code "rapidly" (which costs time and money), then java might become less attractive to them. They might consider choosing other languages instead of Java and Oracle probably does not want that.
Does Oracle make any money off Java ?

[Bill Clar]

I believe that if Java's backward compatibility is revoked or hindered, the end result will not be developers rapidly making changes. It will be developers, and consumers, staying with that version of Java for a long time.

Vendors will need their own legacy versions - one for each java version to contain its respective, deprecated code. Consumers will then be tasked with choosing which vendor package is right for them. If their java auto-updates, then the vendor package could break or fail.

Unfortunately, legacy code will be around for a long time. Fortunately, this means we'll all have jobs for the next 20-40 years. :-)

[Pat Farrell]

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.

[Winston Gutkowski]

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.

I love the idea; and furthermore, I suspect it wouldn't be too difficult to implement AND maintain backwards compatibility.

How about this:
You install Java++ and get two compilers: A new javac that enforces the stuff that we all (??) seem to agree is wrong, and the old one (hidden under a different name - or as a .o or dll) that deals with any existing unmodified source code.
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.

Obviously it's simplistic, and I'm sure there'd be "ripple effects" to deal with; but that strikes me as a management problem, not a language one - and I'm sure there'd be no end of freeware hackers out there who would be delighted to provide "refactoring services".

I await your flames.

Winston

[Martin Vashko]

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.

How would the compiler know that the code being compiled was or wasn't modified after the introduction of Java++?

Then, you'd only have to worry about backwards bytecode compatibility which, I suspect, is far less of an issue than source code.

I think that lots of the 'horrible' generics features exist because of the bytecode compatibility. But I may be wrong.

[Winston Gutkowski]

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.

I think you've missed out a third category of users like me: the "cherry pickers".

I still don't use annotations much (other than "@Override" - a brilliant addition), but I'm a confirmed zealot when it comes to generics. To me, Java code just doesn't look right without it any more.

I also think that there's some notion of acceptance in this whole business. When Sun was running the shop, I was confident (perhaps wrongly) that upgrades would:
(a) be worth having.
(b) would work - especially poignant in the wake of the latest v7 fiasco.

I always liked their conservative approach to "new things", because I didn't feel like we were getting inundated with stuff every time a new release came out. The two new ones under Oracle's stewardship seem to me to be a bit "too much, too fast" for my liking.

Closures? Hey, if you need 'em, there are plenty of other languages out there - many of which run in a JVM - that you can use. I'm happy, for the moment, with Java as a statically-typed language with a few bells and whistles and lots of structure; I don't need a JavaDynamic.

I'd also like to know where the test harnesses for all this new stuff are.

Winston

[Winston Gutkowski]

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...

I think that lots of the 'horrible' generics features exist because of the bytecode compatibility. But I may be wrong.

True, but I think that generics was quite a big departure from the norm, even for Java. I'm also not quite sure which "horrible" features you mean; I'm far more annoyed by those horrible compiler messages. I also realise that it's not a 100% solution; but for what it does do, I think its great.

Winston

[Pat Farrell]

Martin Vajsar wrote:I think that lots of the 'horrible' generics features exist because of the bytecode compatibility. But I may be wrong.

I too have read good sources that bytecode compatibility was the cause of type-erasure, which is one of the evil parts of generics. The other is the most bizarre syntax for some cases, which was obviously to keep the compiler from complaining about old code.

[Jay Orsaw]

I wouldn't say it's "not Java" but it's that Java has advanced beyond SE, and EE. With FX now being a part of the JDK 8 we now get the new advanced GUI and powerful engine to do things for us.


As someone who has switched from Swing to FX and have been working on the Beta builds(currently build 84) the new tools, and goodies are AWESOME. Lambda is SUCH a useful feature. With the addtion of 3D, better sensor support, and overall improvements FX and JDK8 is going to be a great addition to our toolkit.

Add that to the announcement of FX and Java on Mobile devices and we have an entire new set of goodies to work with, and an entire new platform to take over! 2013-2014 is going to be a big push for us.

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...

I'm not 100% sure, but I believe I heard something about new annotations over at the FX Oracle Forum... I forgot what exactly I was reading on there, but if I find it again I will let you know. I know it had to do with someone asking about using $(something) like in Javascript, and I believe a user posted some link about that, though I'm not too sure it has to do with annotations....

If anyone has any idea, let me know.

EDIT: I did find this http://jdk8.java.net/type-annotations/

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.

And how many people still code C that's 40 years old? :P.

New Languages come out all the time, some stick around for a little bit, some for a long time, and some don't make it at all. Languages will constantly evolve. C has C, C++, C#, and Obj-C if you want to count them that way. Java started out with SE(not too sure about EE) and is evolving itself as well as adding in things like JavaFX, and other opensource projects. The beauty of Java is that you create the language yourself(Extensions). We can continue to ever evolve our language, as long as the JVM can continue to improve as well.


That being said Java C, and any other language around now might be completely useless in the future. I had a computer science professor say that the entire architecture of computers could change at any time, though that would completely mess up a lot of things most likely, so I doubt people will "deviate from the norm "

[Bear Bibeault]

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.

[Pat Farrell]

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.

[Jay Orsaw]

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.

Yup I agree, and unless something huge happens that is going to break the market with such an amazing advancement, I don't think we have to worry either. Especially since you would most likely have to port so much code on it(Granted the JVM should be okay) but other languages that run native and such will have to be rewritten for that, and I think it will be a big mess.

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.

Yes, exactly, that was my point. 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.

Now that things are more "standard" we will see languages tend to last longer, or be able to work with one another.

Visual Basic is still #7 on TIOBE's list even though a lot of people don't code in it anymore, there are tons and tons of VB applications still used.

C and Java fight for the 1-2 spots and I think it's amazing how C can last so long, and will continue to last.

C might even make it past 100 years, wouldn't tha tbe crazy? :P

[Pat Farrell]

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?

But C and Java are aimed at solving problems in different spaces. C is a systems implementation language, aimed at writing operating systems and low level utilities. Java is an application programming language, suitable to business problems.

While C has competitors, from Bliss back in the 80s to Google's 'go' today, C is well suited for its tasks, and many programmers know how to use it (if not use it well). I'd much prefer to see 'go' take over, as I think its better suited to the problems of today.

Java has many competitors, from the obvious, C#, python, etc., to the more obscure (scala, haskell). I expect that one of them, or something new, will push Java out of its position over the next decade. The functional hacks to Java 8 will help keep it alive, but IMHO, its really no longer Java.

[Bear Bibeault]

I agree with Pat that you're not comparing apples to apples. You're talking about C as if it were some ancient obsolete language that's still being used today due to momentum. It's not. C is still the best tool for writing systems-level software.

The company I work for makes residential gateways, DVRs, and other set top boxes. I'm one of the very few people in my group that does not work exclusively in C. If there were a better-suited, more modern tool, they'd be using it.

It'll be some time before C can be considered an antique. It will outlive Java quite easily.

[Winston Gutkowski]

Bear Bibeault wrote:If there were a better-suited, more modern tool, they'd be using it.

One wonders what it would be (I have to admit not having looked at 'go'). To me, it's a wonderful abstraction for machine code that delivers functional capability and tools for modularity, while still allowing experts to write code that doesn't take up much more room than an equivalent piece of assembler. I remember ages ago looking at the getc() macro to figure out how it worked (1 line of code). It took me about an hour, but I was in awe of the author - truly a thing of beauty.

I suspect also that Java may have done a lot of good in highlighting some of the mad practises that led to the exploitations common to large C-based systems back when (although it has to be said that Unix has always been pretty solid in that respect; and it was written almost entirely in C).

And just to get in on the ground floor of Pat's Java++ idea:
Could we have an Object<T> class please?

Winston

[chris webster]

So... what would be the difference between "Java++" and, say, something like Scala which is already available on the JVM? I know Scala also has its flaws, but if you're going to break backward compatibility and have to learn lots of new stuff anyway, why mess about trying to fix Java (again)?

[Pat Farrell]

chris webster wrote:what would be the difference between "Java++" and, say, something like Scala which is already available on the JVM?

I've never designed a language, so this is pure speculation.

I've tried to get into Scala and can't grok it. Which is weird, because I've picked up easily 30 languages over the years, as varied as COBOL and FORTRAN to Smalltalk.

So what I'd really like is something in the sprit of Java, maybe even with Java 7's closures, but designed to be cleaner. Generics don't have to be such a hack if they didn't have to be backwards compatible.

I'd also remove all the AWT and javax libraries. There may be some javax APIs that are worth keeping, but those should be renamed to just com.java

That said, philosophically, I think that it may be time to kill off sequential languages with their manual mutex, and move to a language that is designed from the start for parallel processing.

[chris webster]

Going beyond Java 8, Neal Ford has just started publishing some articles on "Java.next" at IBM DeveloperWorks, where he begins by quoting Martin Fowler:

The legacy of Java will be the platform, not the language.

Lots of folk around here have made the same point, of course. I find the arguments for moving beyond pure Java on the JVM pretty convincing - I just wish I could see some prospect of it happening in the trailing-edge "enterprise" Java bloatware shops where I have to earn my daily crust.

[Pat Farrell]

chris webster wrote:Going beyond Java 8, Neal Ford has just started publishing some articles on "Java.next"

Interesting articles, thanks for the link.

But, he spends a LOT of time covering operator overloading. This is something that Ada and C++ had that Java does not have. Back when Ada and C++ were invented, it was very popular to have operator overloading in new languages. In every case, the examples were implementing complex numbers.

Of course, if you look at a Fortran manual, there are no discussions of operator overloading, since COMPLEX is a native number type. The writeups at the time for Ada and C++, and these articles spend a lot of time on it, as if it were a problem of general interest. I'm not convinced that it is. I will claim that if modern languages simply included Complex as a native type, like int and float, we would never think about operator overloading.

I find it interesting that Complex is the example, because while the name makes us think it is a good example, its not. Complex numbers are closed. Any operation with a complex and any other number results in a complex number. This is not true of a lot of other numbers that we would love to have, and overload. The obvious example is money. Zillions of hours of debugging has been wasted because naive programmers us float (or double) for money. It doesn't work. So you'd like to have a Money class, with all the usual operators. While the usual + - * / on complex give a complex, they don't on money. You can add two Money, but if you multiply them, you get a MoneySquared. Multiplication is only valid between one Money and on Numeric object.

Operator overloading has always just been syntactic sugar. IMHO we'd be better off if new languages skipped that section.

[Jay Orsaw]

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. Swing is dead, and FX not only takes over the GUI portion, but it also has a lot of other nice features bundled into it. I personally transferred to FX not too long ago and found it to be very excellent, and a much better alternative.


As for Lambda or any other new addition I don't see the big deal. You can call a language whatever you want, or think that a language is known for whatever reasons, but a new addition saying it's a new lang well, maybe, if you want to think that way. Java is still Java. There isn't anything different, just newer tools to get things done.

I'm really looking forward to 8, but maybe that's just me .

[Bear Bibeault]

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.

[Jay Orsaw]

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.

There have been examples of FX used with EE

http://www.oracle.com/technetwork/java/javafx/samples/index.html

http://docs.oracle.com/javafx/2/overview/jfxpub-overview.htm

Sales Dashboard (DataApp)
DataApp is a client-server application for a fictional global automobile company called Henley Car Sales. Automobile sales are simulated on an EJB server using JavaDB, and the data is available via Derby and a RESTful web service. The client demonstrates a variety of data presentations by using a mix of FXML and JavaFX.

I thought originally that JavaFX was "Desktop" only also, until I found this example. I couldn't get it to run due to some weird Database line read issue that others also had. I'm not sure if this is now due to FX's integration, or if this was something new, but I believe I have seen another FX client-server app as well.


I'm not that familiar with the client-server side of Java yet, so if you have other Information I would like to know, because I am looking to design a Client-Server app with FX, and I don't see why it would be an issue, unless there are huge limitations.

[Bear Bibeault]

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]

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.

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, and create some sort of small client side with SE or what? Does GUI work go on a server? Im confused I guess....?

[Bear Bibeault]

Jay Orsaw wrote:So you're saying the only "Server side" technology is EE, and that everything else, FX/SE is "Desktop?"

I said nothing of the kind. (Though I would be hard-pressed to come up with a use for Swing/JavaFX that wasn't considered "desktop" -- but it's not my area).

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.

What I'm saying is that regardless of whether a fat client makes a connection to a server or not, it's generally considered a "desktop" program.

A good example (non-Java) of such a program that I use is Evernote; it has a fat client whose only purpose is to give access to the repository of documents that it manages on behalf of the user. The important stuff is all on the server, but the desktop client provides the user access. Regardless of its reliance on the server, it's a desktop program. (There's also a thin-client view that runs in the browser.)

It's a matter of semantics whether a desktop program delivered by a web mechanism such as JNLP could be considered SAAS or not. But like "client", most people think of SAAS as software running remotely and serving its view through a browser. (Though even that distinction may be beginning to be blurred with web apps moving to more and more client-side JavaScript functionality.)

Are you saying that when doing a SaaS you ONLY use EE and server side technologies

Nope; putting words in my mouth again. There's more to programming than just Java. No one said SAAS needs to be Java-based at all.

And there's more to Java than JEE. The Play! Framework for example, completely eschews JEE.

Does GUI work go on a server? Im confused I guess....?

I'm confused by the question. I have no idea what you are asking. In a client-server environment, whether thin or fat client, a GUI on the server isn't of much use to the client.

[Pat Farrell]

Bear Bibeault wrote:And there's more to Java than JEE. The Play! Framework for example, completely eschews JEE.

Many systems written in Java by very smart people follow the lead here and run as far away from JEE or J2EE as possible.

Eschew JEE !!!

[Pat Farrell]

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....?

Jay, every system that I've written this century uses a Java server that talks HTML to a browser. None use any Java GUI code, no AWT, no Swing, no JavaFX. They create HTML.

They often use JSP, CSS, javascript and other things, but all of the presentation is done on the client's browser. Not only do I not write any GUI code, but I have no control over what browser they use. Could be IE, or Firefox, Chrome or Safari, even Opera and other more obscure ones.

I'm sure that there are still a few folks writing GUI code using Java, but I don't know any, and haven't even seen it since the late 1990s. I sure that some folks writing for Android use the SDK's Java-like language, but I have no idea what APIs they call to do the touch sensitive stuff or the displays. All of the IOS folks use Objecting-C, as Chairman Steve hated anything that was not Objective-C

[Yohan Weerasinghe]

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? Everything is converted to this C++ related programming style? :O Or else, does this means some classes and packages added into Java with a new programming style?

If java developers cannot code things in the way we used to do with the classes existing in Java 7, I am sure all the Java developers are simply betrayed by Oracle

[Pat Farrell]

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?

Well, you need to make the distinction between Java the language and the usual libraries. Java 8 the language will have some changes. They will alter how code is written.

There may be very minor changes to the usual libraries, like "IO, Servlets, EJB" but they are really outside of the language itself.

[Rob Spoor]

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.

[Yohan Weerasinghe]

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.

That is really great to know! I am really happy now!

Anyway I have seen symbols like "->" which are pointer method calls in C++. Since Java is built on C++, this new version means Java new classes got access to pointers?