Forgot your password?
typodupeerror
Programming

The Long Death of Fat Clients 277

Posted by samzenpus
from the slimming-down dept.
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.'"
This discussion has been archived. No new comments can be posted.

The Long Death of Fat Clients

Comments Filter:
  • Re:Yay. (Score:4, Informative)

    by GameboyRMH (1153867) <gameboyrmh@NoSpAM.gmail.com> on Thursday June 28, 2012 @03:20PM (#40484009) Journal

    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)

    by Anonymous Coward on Thursday June 28, 2012 @03:23PM (#40484057)

    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)

    by recharged95 (782975) on Thursday June 28, 2012 @03:24PM (#40484085) Journal

    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)

    by benf_2004 (931652) on Thursday June 28, 2012 @03:35PM (#40484307)

    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)

    by Anonymous Coward on Thursday June 28, 2012 @04:10PM (#40484979)

    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)

    by Bigby (659157) on Thursday June 28, 2012 @04:30PM (#40485309)

    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)

    by icebraining (1313345) on Thursday June 28, 2012 @05:10PM (#40485893) Homepage

    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)

    by Mechanik (104328) on Friday June 29, 2012 @07:17AM (#40491999) Homepage

    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.

    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:

    1. Check which JVM it is launching with.
    2. Is it the Sun JVM?
    3. If it is, pass PermGen options

    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.

...when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor. - Fred Brooks, Jr.

Working...