Java 4-ever

[SteveRiley]

Sheesh.

[oshunluvr]

Friggin' hilarious!

[dibl]

Tee hee hee hee hee!

[NickStone]

Same video I posted here https://www.kubuntuforums.net/showth...6020-JAVA4Ever

[GreyGeek]

And another one!

[SteveRiley]

Oops. Sorry, nickstone... I totally missed your earlier post.

[NickStone]

That was good GG but not as funny as Java4Ever

[Feathers McGraw]

Hehe that was brilliant... but who made it?!

[NickStone]

Here's another one. The Java heist

WARNING! contains bad language

[oshunluvr]

Is that "Brick Top?"

[SteveRiley]

There's just one minor problem with these videos -- they're packed with lies! Java never fulfilled its write once, run anywhere promise; and the JVMs are so badly written that they present one of the most lucrative attack targets on PCs these days.

[Feathers McGraw]

Java never fulfilled its write once, run anywhere promise;

Is there anything better than Java at doing this, though? Do you think it's really possible to achieve this? Genuine questions.

[kubicle]

There's just one minor problem with these videos -- they're packed with lies! Java never fulfilled its write once, run anywhere promise; and the JVMs are so badly written that they present one of the most lucrative attack targets on PCs these days.

I kind of symphatize with the mother "My son is a monster"

[kubicle]

Is that "Brick Top?"

Yup. They clearly know what they're doing

[GreyGeek]

Is there anything better than Java at doing this, though? Do you think it's really possible to achieve this? Genuine questions.

I used the Qt API for four years before I retired. I'd write the client-server software in my Linux installation against PostgreSQL and recompile them on my Windows side for deployment on NetWare, and later, Windows servers. I could have just as easily recompiled the same source on a Mac box to make a Mac ap. However, the Qt API does not have a "virtual machine" mode.

The biggest problem with any language is the tendency for users to extend it into areas the language creators didn't intend for, nor prepare for, their use. This is especially true when "frameworks" are created using a language. Several Visual FoxPro developers created FoxPro Frameworks, which came with built in parts which supposedly made it easier for developers to create applications. We played with it a Revenue but decided it was too much trouble trying to fit our problem into that "solution".

I also noticed that developers extended Ruby to include frameworks, which were called "rails", i.e., Ruby On Rails. For a lot of developers it hasn't worked out well.
http://rjha94.blogspot.com/2006/12/w...-on-rails.html
http://ruby.about.com/b/2011/04/09/t...oning-ruby.htm
http://gilesbowkett.blogspot.com/201...ebuilding.html

I didn't show any FoxPro frameworks because FoxPro is, for all intents and purposes, a dead language. There are many other examples of languages that were extended beyond their design parameters.