The Long Death of Fat Clients 277
snydeq writes "With Adobe's divestment of Flex and mobile Flash and Microsoft's move from Silverlight to Metro, Oracle now seems all alone in believing that a fat client framework — in the form of JavaFX — is a worthwhile investment, writes Andrew Oliver. 'Fewer and fewer options exist for developing purely fat client desktop applications and fewer still for RAD applications with Web-based delivery (aka, "thick clients"). We are on the verge of a purely HTML/JavaScript client world. Or we would be, if it weren't for mobile pushing us back to client-side development.'"
Re:Yay. (Score:4, Informative)
Assuming you're running Windows just remove the older versions, newer installers do it automatically but if you have some REALLY old versions on there you'll have to remove them yourself.
If you're running Linux, well it's your choice to run Sun Java, OpenJDK and...whatever other Java RE you've found, at the same time.
Yuck!! (Score:3, Informative)
Silverlight is dead like VB6 is dead...
The technology will live on for a long time - it is still the best option for developing RIA LOB applciations.
I'm a native guy - HTML/Javascript is just not a solid method for developing applications.
fragmentation (Score:5, Informative)
Death of the fat-client makes sense for the multimedia, e-commerce world.
But for real-time, mission critical? I'll stick with fat-clients with a mobile component for now.
Re:Yay. (Score:4, Informative)
I haven't yet found a program which stopped working with newer java.
Up until last month, we still had to install Java 1.5 on some users' computers because their jobs required them to use a web application that would not work on Java 1.6 or newer. We neither develop nor host the application, so all we could do was keep installing the horribly outdated version of Java and wait for the application to be upgraded to work with Java 1.6.
Re:Yay. (Score:4, Informative)
Everything eclipse based got hit with that when Oracle rightly changed the vendor property of the Sun jvm to oracle, afaik checking that did not even make sense since both version and name of the jvm have their own properties . Sadly no programming language can protect you against stupid programmers, any attempt will be dwarfed by the world producing better idiots.
Re:Yay. (Score:3, Informative)
This is probably because of a security flaw that u29 closed and Entrust Truepass utilized to function. That isn't the fault of the compile code, but the security manager. This can be resolved through a change in the java.policy file.
Sometimes the problem comes up because someone used a Sun/Oracle class or an IBM class instead of the standard API.
Re:Um... (Score:5, Informative)
So? Machine code isn't typed either. Much like for native applications, you can use a statically (and strongly) typed language and compile it down to JavaScript.
List of languages that compile to JavaScript [github.com].
Re:Yay. (Score:4, Informative)
Speaking as someone who is an Eclipse committer, your representation of the situation is not accurate.
Sun's JVM has different proprietary options than other JVMs. It also has this notion of PermGen space that other VMs don't have, where various classloader stuff and other things can be stored. Run out of space there, and the JVM blows up.
When you have a Java application like Eclipse that is really big, it's not hard to run out of PermGen, especially because the default size is so paltry. So, the Eclipse launcher needs to be able to modify this size of the PermGen. However, the special command line option to do this is proprietary to the Sun JVM, and if you pass it to someone else's JVM it's common for that JVM to refuse to run because you gave it an option it didn't recognize.
So, Eclipse has to:
How do you propose checking #2 without checking the vendor name of the JVM?
Maybe you should look into things more before you call a bunch of experienced, professional, open source programmers stupid idiots.