Digital Rights Management. Digital Restrictions Management is the FSF's retconning of the term in an attempt to obtain better accuracy. Personally, I don't see what the big deal is. Digital Rights Management already tells me that someone else is "managing" my rights to my stuff.
That, and you're being overly pedantic. I wonder if they have a movie about such pedantism on DVD Disk?
"[I asked my tech people, and they said that] theoretically those analog outputs could be disabled, forcing consumers to use a secure digital connection to watch HD content. [Then they tried to convince me that such measures were mostly token measures, but I ignored them.] A lack of copy protection is holding HBO back from making its own content available in high-definition through its popular HBO On Demand platform, [because I didn't take the time to listen to my technologists. I decided that the real problem was the name, not that the technology was backed by poor use of legal constructs.]"
I'm still waiting to see how long it takes these people to realize that they're actually driving piracy with every day they wait. They should consider the data gathered in the "freakanomics" research. The data clearly shows that most people are honest, and those that aren't simply aren't. If you offer up content at a fair price, the majority of users will purchase that content rather than resorting to illegal or immoral means to obtain it. Meanwhile, the DRM restrictions will do little to stop those looking for a free ride. They're not going to pay for it in the first place, so why worry about it now? If they can't get past your DRM scheme (not likely), they'll rip it from the DVDs or HD-DVDs.
The software industry had to learn the same thing many years ago. Copy protection annoyed the paying users while doing little to stop the pirates. Why can't anyone get that lesson through their head?
Dang, this is difficult isn't it? The more I pull up these old songs, the more I realize that they all have to be rearranged to be effective in Guitar Hero due to their overuse of the synth. Final Countdown is a perfect example. It's got a great solo (as in Jump), but the rest of it is almost entirely driven by the synth.
Ok, here's a few more tries for songs that wouldn't need rearrangement (I think):
Rebel Yell by Billy Idol
Walk like an Egyptian by The Bangles
We Got the Beat by the Go Gos
Edge Of Seventeen by Stevie Nicks (?)
? Not sure if this one would translate to the game very well.
Yeah, I'm feeling pretty sheepish about that one. (Bhaaaaa!)
And those Ray Parker and Proclaimers aren't exactly featured-guitar songs.
As someone already mentioned, Ghostbusters was obviously written for a guitar. Why they used a synth that sounds like a guitar is... well... who the heck knows? There was I link I posted above of a version done with actual guitars.
As for the Proclaimers, those look an aweful lot like guitars they're playing there:
Doh! I didn't realize about "It's My Life" (silly me, I had assumed it was a track they didn't play on the radio at the time), but "We didn't start the Fire" most certainly came out in the 80's:
And several of those (We Didn't Start the Fire, Wild, Wild West for example) are great songs, but not exactly known for their guitar tracks.
Neither are most of their picks. That doesn't stop them from being rearranged for the guitar. Wild, Wild West already utilizes the (bass?) guitar, so it's not too much of a stretch.
Exactly. Sun didn't tell the press for three years how they were going to change the world with it, they just did it and then announced it. Compare that to Sun's overhyped Grid Computing Service. Millions of dollars flushed into the project and no serious customers to speak of.
See, the thing about Oak is you didn't hear about how "Oak was going to change the world" or "Oak was going to make your toaster toast better". Sun just did it without all the fanfare. Thus we got Java without ever hearing about this "Oak" thing.
Same thing here. If Sun would just do it, there wouldn't be any concern. But the moment they announce to the press that it's a big project with codename XYZ and that it's going to change the world, yada yada yada, it's already over.
Not to say that some of the Solaris tools couldn't use a good sprucing up with newer and fresher versions, but I tend to get nervous whenever Sun codenames something. It usually means that they're about to start on something that isn't a bad idea per se, but will be guaranteed to be aborted prior to any real commitment or follow-through. What state that will leave Solaris in is anyone's guess.
*shudder* I still remember Mad Hatter. Such promise. Such failure to follow up,
I've been studying FX since the announcement yesterday, and I think that Sun is overhyping it to the extreme. As it turns out, all JavaFX is is a new scripting language formerly known as F3. The purpose of this language was to offer control over the Java2D and Swing APIs in a manner that is easy to use and fast to develop. Because of the control provided, developers are able to create richer GUIs.
Somewhere along the way, the concept got derailed. Sun must have seen the iPhone and started worrying about what would happen to J2ME should it take off. So they yanked F3 off the shelf to show how similarly impressive GUIs could be created for cell phones. But before they could announce it, Microsoft jumped in the fray with their Silverlight announcement. (Silverlight being a powerful multimedia technology solution in search of a problem.) Not to be outdone, Sun somehow managed to convince the press that if you throw F3 (nay, JavaFX!) scripts into an Applet, you have a strong competitor to Silverlight. A rather incredible claim, IMHO, as JavaFX is lacking in the streaming video department. Even more telling is the fact that none of the JavaFX examples are actually applets!
Thankfully, Sun seems to be hedging their bets. None of the pages on the JavaFX site even mention Silverlight, almost making it look like the entire idea was a press invention. Sun's pages make a few passing references about running the technology in an Applet, but nothing firm.
My verdict? I think that F3/JavaFX is the GUI layout technology that Swing developers have been waiting for. With any luck, the technology will create a new market for Java Desktop Applications. The rest of Sun's claims can be safely ignored.
But the elements that will make the language useable into the future are going to be:
* object oriented?
* interpreted language.
* extremely lightweight such that it can be loaded as part of the browser without bringing down the house lights.
* non-proprietary is an absolute must.
* capable of it's own (secure?) data transmission methods -- data marshalling, maybe xml, and ssl tunnelling support?
Congratulations, you've just described Javascript.
When I say server-side push, I mean in the context of AJAX-type applications. What is Comet if not an attempt to perform server-side pushes of data? Such a design is used day-in and day-out by Javascript application that require an immediate response to server-side events.
Take GMail as an example. You know how it embeds a GTalk widget, right? How does the browser know when an IM comes in? Or when a buddy logs in? Or when a status changes? Obviously, a connection to the server needs to be maintained in order to get this information in a timely matter. That's what Comet* communications solves. Server-side Events solve that problem more elegently by providing a standard mechanism for long-running connections. No more up and down polling by Javascript code. It all gets handled automatically. To that end, SSE addresses a real-world need that exists today.
* There is actually another architecture that I somewhat prefer to Comet, but its portability is questionable. Basically, you can use a hidden IFrame to maintain an open communications channel. When an event needs to be sent by the server, a bit of Javascript code is flushed down the pipe to activate that event in the parent frame. The design works really well, but as I said; it's portability is questionable. It's also a PITA to implement on the browser side.
The thread is about whether or not you can use non-GPLv2 compatible code with the GPLv2ed JRE. The answer is an emphatic no. Therefore, based on those four facts, a GPLv2 JRE may only run GPLv2 compatibly licensed code.
So what you're telling me is that if Joe gives Bob a Java program, and Bob then decides to run it using a GPLed JVM, Bob is in BIG TROUBLE if that program isn't GPLed?
Wow. Your legal theorez just blewz meez mind, man. I think I'll have to take a few tokes on the ole' weed here to catch up with such profound logic. I mean, that's just incredible stuff. All this time I thought that the end user wasn't subject to the GPL unless he modified the code or redistributed the package! (Paragraph 5) Dudez, I jus' went totally NEO on your azzes!
I suppose that maybe you were being facetious or sarcastic, or maybe you were simplifying, but static typing hardly "makes all the bad problems go away".
Incredibly simplifying. I should have thought it was clear from the poor grammar I used? No matter. The "bad problems" I was referring to are the issues of properly securing an interface against accidental abuse, documenting how an interface should be correctly used, and generally catching errors in the compiler whenever possible. Such tight control over code is necessary in a language like Java where code reuse in the form of libraries is a common practice.
Static typing can't ensure that the library gets used correctly, but it can ensure that the library only gets expected inputs. Which means that a library author can free his own code from any potential bugs caused by input that's sorta-kinda ok some of the time.
Strings recast as integers is one case of this that gives me nightmares. That stuff needs to be checked the moment it's read into the system, not ignored because it's more convenient to pass it through via casting rules. Unfortunately, many programmers (even those who should know better and have the best of intentions) won't take the time to implement such checks. Meaning that you're better off forcing their hand with the compiler rather than trying to support someone who just wrote about 50,000 lines of gnarled code that depends on your library and "suddenly broke". (Call me crazy, but I like knowing a bit more about the problem then, "it broke". I hate bug reports like that.)
So there you have it. The long version of how static typing "makes all the bad problems go away." Otherwise, nice rant.;-)
A good software engineer sees both and asks what the hell! And a bad one just codes around things as they are, and asks nothing. He's too busy talking about how l33t he is on Slashdot.
And the experienced engineer knows that cross-platform problems follow you everywhere. At some point you need to stop whining and get the work done. If we simply complained about the platform technologies all the time, there would be no POSIX programs, no Win32 programs, and a much smaller pool of good Java programs. Specs are specs, and they tend to get interpreted differently. As an experienced engineer you should have long ago learned how to normalize these differences rather than simply throw up your hands in frustration.
This is not to malign JavaScript, but seriously, why should you need JavaScript to make a simple HTTP request from a browser?
How does one answer this question? Of course you don't need Javascript for a "simple HTTP request". You need Javascript to dynamically modify the DOM, restyle the layout, respond to user input, and manage a less-than-simple HTTP request all at the same time. And like the "vealed calf" that I supposedly am, I've been finding that this design has many superior aspects when compared to a Java or Flash program. (Even though I'm actually supporting Flash with an AS2.0 version of the same APIs.)
Here's something for you to ponder. I am creating these APIs because the target environment does not support Java. It supports Flash and it supports advanced Javascripting. So like the "vealed calf", I am targeting the platform out of necessity. And you know what I've found? It's not actually as bad as everyone is making it out to be. The pitfalls are well documented and/or testable. Mostly minor cross-platform issues that will go away with each browser release. So it becomes quite easy to patch minor holes in the interim.
[lots of blah, blah, blah about security]
You know what we didn't have 10 years ago? An internet on which the vast majority of the world's population performed financial transactions. An internet that targeted your average consumer rather than business folk or hackers. An internet through which financial gain could be obtained by disrupting the normal flow of traffic.
You may be too young to remember when "Client/Server" was the latest hotness, but I remember it well. And I can tell you right now that we would have been no safer with those programs than we are with some of the moronic coders we have today. I just loved it when it was possible to telnet into a port and start executing commands before passing login credentials, because no one had ever tested the no-credential situation. All their code assumed that things happened in a certain order without ever verifying the case.
If you want to point a finger at the security problems of the web, then how about starting with yourself? Specifically, you and every programmer who writes software for the web. Computers Software is an engineering discipline just like any other. If you fail to apply proper engineering principles, you will fail. Those principles don't get learned overnight. They take years to cultivate and grow. Unfortunately, the industry wants fast answers and cheap programmers. They are rarely willing to pay for older programmers with strong skills to head up teams and ensure that the engineering is done right. Instead, they first try junior programmers, then outsourcing, then offshoring. All in an attempt to make a process cheaper by cutting corners.
You accuse me of trying to show off my "l33t"ness (whatever the hell that is). Well, how's this for "l33t"ness: A recent security advisory revealed that JSON objects were vulnerable to a cross-scripting exploit by the very nature of being serialized Javascript objects. It was mentioned that it was the first exploit that could target only AJAX-enabled applications. Well, I use JSON. And you know what I found when
Seems I confused you with my slightly sarcastic tone. "for(var i in object)" is a core part of Javascript and the way it works. That feature (and what it implies) are why it's so simple to fix different browsers to work like one another. If you don't know how to use it, you shouldn't be coding web apps.
Also, OOP is not bolted on in Javascript. It's been there since nearly the beginning. It's just that 99% of web coders never actually learned how to code Javascript.
How do you know JavaFX will be so bad when they have only announced it and haven't previewed it?
I've been a Java programmer for about 11 years. In that time, I've explored the VM and libraries inside-out, upside-down, and sideways. The conclusion I've come to is that Java in the browser is a bad idea. At least in the form of the J2SE. If it had been developed more like a J2ME plugin with access to the DOM, it might have been a decent replacement for Javascript. But it wasn't developed that way, and now I think it's not in a very good position to compete in that space.
This sounds like it is targeting more than just "fetch this list box dynamically" by trying to be a way to make web pages that are currently only realistically implementable by making the entire thing in Flash.
You bring me requirements, and I'll show you the magic that modern web technology can perform. And it's only going to get better. My comments about Server Side Events and XMLSocket are meant to mention how much better it's going to get. SSE will effectively obsolete Comet-style requests, resulting in rich server "push" systems that can transmit nearly anything to the client on demand. No need to worry about different XMLHttpRequest implementations, it will all be automatic in the browser. Opera already supports this, and thanks to the magic of Javascript, it's easy to branch to code that makes use of it when available. Wrap it in your libraries, and you're ready. to. ROCK!:)
Java has the ability to do static typing.
Which is its strength as a platform, and its weakness as a scripting language. Don't get me wrong, the computer scientist in me wants to go with static typing. I love static typing. It makes all the bad problems go away. But the web coder in me knows that distributed document technology needs something more flexible. Dynamic typing as in Javascript is that flexibility.
It's slightly out of date, but you might find this article I wrote to be interesting. Web technologies are really accomplishing what Sun envisioned all those years ago.
Anyway, given the current state of Java technology in the browser, I don't see this as being any different from WebStart, which everyone loves to hate because it is so clunky.
Speak for yourself. I personally love Webstart technology. It's a beautiful solution to installing/launching applications in a cross-platform way. You just click, and it loads. No guarantees about the quality of content the developers package on the side, though.:-/ (The SpaceInvaders demo you pointed to being an obvious example.)
I really hate when people refer to Active-X as "viral" or something similar... Active-X is a technology like any other
Actually, ActiveX is a patented Microsoft Security Hole(TM) big enough to drive a Mack Truck through. Effectively, Microsoft looked at Java Applets and said, "The biggest problem with it is that it doesn't access Windows APIs and has all that security BS. We can do better." Next thing you know, Microsoft "partners" are showing how you can access DirectDraw and Direct3D to make ActiveX components that were WAY more impressive than the simplistic animations that Java was capable of. Of course, the security implications hit Microsoft less than a year later as Malware started exploiting the system for all kinds of nefarious purposes.
Microsoft kinda-sorta shuffled it off into other areas after that. Now they're back with a vengence. Silverlight will be everything that ActiveX was going to be, but BETTER! Can you feel the excitement?:-/
Does this really spell the end of AJAX? I sincerely hope so. Nothing built on Javascript will ever achieve the security, cross-platform reliability, and programmatic friendliness that Web 2.0 needs.
Did it occur to you that you're sounding exactly like the hype you're decrying?
AJAX is a stupid name developed for the ole' hype machine (mostly to sell conferences and books, methinks) but the basic web technologies behind it are NOT THAT BAD. To use the example from the article, am I "tearing [my] hair out over as [I] attempt to get the JavaScript working in both Internet Explorer and Firefox?" Actually? No, I'm not. And I just implemented a Comet library in both Javascript and Actionscript. About the most frustrating thing was the fact that Opera ignored the cache-disable commands when using XML.load in Flash. So I build a solution into the library. And if you think that's fun, wait until I detect Server Side Events in Opera and use XMLSockets in Actionscript!
*shrug*
Oh, and I had to dynamically patch Safari and Opera to add support for the toSource function. Easy as for(var i in object) pie.
The problem with most "AJAX coders" is that they still think of Javascript as that cutesy language they used to do scrolling statusbar text with. But it simply isn't that bad. In fact, Javacript is a full-up, Object Oriented (or at least, OOP capable) langauge that fits the lightweight needs of the web browser perfectly. Java is a 600 pound gorilla that's better for designing heavyweight applications that are secure, robust, fast, and feature complete. The two target very different markets.
As for JavaFX, there is (if you'll excuse the expression) "nothing to see here". It's just a Silverlight competitor. Which makes it just as questionable as the product against which it's competing. If you really want a replacement for XMLHttpRequest, use XMLSocket instead,
Slashdot Mirror
Digital Rights Management. Digital Restrictions Management is the FSF's retconning of the term in an attempt to obtain better accuracy. Personally, I don't see what the big deal is. Digital Rights Management already tells me that someone else is "managing" my rights to my stuff.
That, and you're being overly pedantic. I wonder if they have a movie about such pedantism on DVD Disk?
Silly me. This whole time I thought it meant Digital Rights Management.
P.S. ATM Machine.
I'm still waiting to see how long it takes these people to realize that they're actually driving piracy with every day they wait. They should consider the data gathered in the "freakanomics" research. The data clearly shows that most people are honest, and those that aren't simply aren't. If you offer up content at a fair price, the majority of users will purchase that content rather than resorting to illegal or immoral means to obtain it. Meanwhile, the DRM restrictions will do little to stop those looking for a free ride. They're not going to pay for it in the first place, so why worry about it now? If they can't get past your DRM scheme (not likely), they'll rip it from the DVDs or HD-DVDs.
The software industry had to learn the same thing many years ago. Copy protection annoyed the paying users while doing little to stop the pirates. Why can't anyone get that lesson through their head?
Guitar Hero: Spanish Guitar sounds great to me. Nintendo would then follow up with their own "classic" spinoff, Donkey Harmonica. :P
Ok, here's a few more tries for songs that wouldn't need rearrangement (I think):
? Not sure if this one would translate to the game very well.
Yeah, I'm feeling pretty sheepish about that one. (Bhaaaaa!)
As someone already mentioned, Ghostbusters was obviously written for a guitar. Why they used a synth that sounds like a guitar is... well... who the heck knows? There was I link I posted above of a version done with actual guitars.
As for the Proclaimers, those look an aweful lot like guitars they're playing there:
http://www.youtube.com/watch?v=qQfqSWe8eVE
Ok, so it's not a hard rock beat. But I thought this was 80's music Guitar Hero, not "Electric Guitar Hero".
Side Note: I should say it's "allegedly" Green Day's version. Seems to be some confusion on who's cover it actually is. :P
I'm not sure if it was all a synth or a synth and a guitar. It was certainly intended to sound like a guitar in the background.
Here's Greenday's version with an actual guitar. They need to slow it down a bit, though...
http://en.wikipedia.org/wiki/We_Didn't_Start_the_
Neither are most of their picks. That doesn't stop them from being rearranged for the guitar. Wild, Wild West already utilizes the (bass?) guitar, so it's not too much of a stretch.
I could probably go on all day, but you get the idea.
Exactly. Sun didn't tell the press for three years how they were going to change the world with it, they just did it and then announced it. Compare that to Sun's overhyped Grid Computing Service. Millions of dollars flushed into the project and no serious customers to speak of.
See, the thing about Oak is you didn't hear about how "Oak was going to change the world" or "Oak was going to make your toaster toast better". Sun just did it without all the fanfare. Thus we got Java without ever hearing about this "Oak" thing.
Same thing here. If Sun would just do it, there wouldn't be any concern. But the moment they announce to the press that it's a big project with codename XYZ and that it's going to change the world, yada yada yada, it's already over.
Not to say that some of the Solaris tools couldn't use a good sprucing up with newer and fresher versions, but I tend to get nervous whenever Sun codenames something. It usually means that they're about to start on something that isn't a bad idea per se, but will be guaranteed to be aborted prior to any real commitment or follow-through. What state that will leave Solaris in is anyone's guess.
*shudder* I still remember Mad Hatter. Such promise. Such failure to follow up,
Jini was actually a good idea. Unfortunately, Sun was not in a position to exploit it, and wanted too much money for licensing anyway.
Completely agree on JXTA. I remember watching the introduction and thinking, "WTF?"
I've been studying FX since the announcement yesterday, and I think that Sun is overhyping it to the extreme. As it turns out, all JavaFX is is a new scripting language formerly known as F3. The purpose of this language was to offer control over the Java2D and Swing APIs in a manner that is easy to use and fast to develop. Because of the control provided, developers are able to create richer GUIs.
Somewhere along the way, the concept got derailed. Sun must have seen the iPhone and started worrying about what would happen to J2ME should it take off. So they yanked F3 off the shelf to show how similarly impressive GUIs could be created for cell phones. But before they could announce it, Microsoft jumped in the fray with their Silverlight announcement. (Silverlight being a powerful multimedia technology solution in search of a problem.) Not to be outdone, Sun somehow managed to convince the press that if you throw F3 (nay, JavaFX!) scripts into an Applet, you have a strong competitor to Silverlight. A rather incredible claim, IMHO, as JavaFX is lacking in the streaming video department. Even more telling is the fact that none of the JavaFX examples are actually applets!
Thankfully, Sun seems to be hedging their bets. None of the pages on the JavaFX site even mention Silverlight, almost making it look like the entire idea was a press invention. Sun's pages make a few passing references about running the technology in an Applet, but nothing firm.
My verdict? I think that F3/JavaFX is the GUI layout technology that Swing developers have been waiting for. With any luck, the technology will create a new market for Java Desktop Applications. The rest of Sun's claims can be safely ignored.
Start here:
i pt_1.5_Guide
a ndards/Ecma-262.htm
http://developer.mozilla.org/en/docs/Core_JavaScr
(Yes, those are the Netscape docs from 10 years ago. No one read them then, either.)
If you're brave, I also recommend the ECMA specs:
http://www.ecma-international.org/publications/st
All the Web APIs you need to go with that can be found at the source:
http://www.w3.org/
Congratulations, you've just described Javascript.
When I say server-side push, I mean in the context of AJAX-type applications. What is Comet if not an attempt to perform server-side pushes of data? Such a design is used day-in and day-out by Javascript application that require an immediate response to server-side events.
Take GMail as an example. You know how it embeds a GTalk widget, right? How does the browser know when an IM comes in? Or when a buddy logs in? Or when a status changes? Obviously, a connection to the server needs to be maintained in order to get this information in a timely matter. That's what Comet* communications solves. Server-side Events solve that problem more elegently by providing a standard mechanism for long-running connections. No more up and down polling by Javascript code. It all gets handled automatically. To that end, SSE addresses a real-world need that exists today.
* There is actually another architecture that I somewhat prefer to Comet, but its portability is questionable. Basically, you can use a hidden IFrame to maintain an open communications channel. When an event needs to be sent by the server, a bit of Javascript code is flushed down the pipe to activate that event in the parent frame. The design works really well, but as I said; it's portability is questionable. It's also a PITA to implement on the browser side.
So what you're telling me is that if Joe gives Bob a Java program, and Bob then decides to run it using a GPLed JVM, Bob is in BIG TROUBLE if that program isn't GPLed?
Wow. Your legal theorez just blewz meez mind, man. I think I'll have to take a few tokes on the ole' weed here to catch up with such profound logic. I mean, that's just incredible stuff. All this time I thought that the end user wasn't subject to the GPL unless he modified the code or redistributed the package! (Paragraph 5) Dudez, I jus' went totally NEO on your azzes!
Moron.
Incredibly simplifying. I should have thought it was clear from the poor grammar I used? No matter. The "bad problems" I was referring to are the issues of properly securing an interface against accidental abuse, documenting how an interface should be correctly used, and generally catching errors in the compiler whenever possible. Such tight control over code is necessary in a language like Java where code reuse in the form of libraries is a common practice.
Static typing can't ensure that the library gets used correctly, but it can ensure that the library only gets expected inputs. Which means that a library author can free his own code from any potential bugs caused by input that's sorta-kinda ok some of the time.
Strings recast as integers is one case of this that gives me nightmares. That stuff needs to be checked the moment it's read into the system, not ignored because it's more convenient to pass it through via casting rules. Unfortunately, many programmers (even those who should know better and have the best of intentions) won't take the time to implement such checks. Meaning that you're better off forcing their hand with the compiler rather than trying to support someone who just wrote about 50,000 lines of gnarled code that depends on your library and "suddenly broke". (Call me crazy, but I like knowing a bit more about the problem then, "it broke". I hate bug reports like that.)
So there you have it. The long version of how static typing "makes all the bad problems go away." Otherwise, nice rant.
And the experienced engineer knows that cross-platform problems follow you everywhere. At some point you need to stop whining and get the work done. If we simply complained about the platform technologies all the time, there would be no POSIX programs, no Win32 programs, and a much smaller pool of good Java programs. Specs are specs, and they tend to get interpreted differently. As an experienced engineer you should have long ago learned how to normalize these differences rather than simply throw up your hands in frustration.
How does one answer this question? Of course you don't need Javascript for a "simple HTTP request". You need Javascript to dynamically modify the DOM, restyle the layout, respond to user input, and manage a less-than-simple HTTP request all at the same time. And like the "vealed calf" that I supposedly am, I've been finding that this design has many superior aspects when compared to a Java or Flash program. (Even though I'm actually supporting Flash with an AS2.0 version of the same APIs.)
Here's something for you to ponder. I am creating these APIs because the target environment does not support Java. It supports Flash and it supports advanced Javascripting. So like the "vealed calf", I am targeting the platform out of necessity. And you know what I've found? It's not actually as bad as everyone is making it out to be. The pitfalls are well documented and/or testable. Mostly minor cross-platform issues that will go away with each browser release. So it becomes quite easy to patch minor holes in the interim.
You know what we didn't have 10 years ago? An internet on which the vast majority of the world's population performed financial transactions. An internet that targeted your average consumer rather than business folk or hackers. An internet through which financial gain could be obtained by disrupting the normal flow of traffic.
You may be too young to remember when "Client/Server" was the latest hotness, but I remember it well. And I can tell you right now that we would have been no safer with those programs than we are with some of the moronic coders we have today. I just loved it when it was possible to telnet into a port and start executing commands before passing login credentials, because no one had ever tested the no-credential situation. All their code assumed that things happened in a certain order without ever verifying the case.
If you want to point a finger at the security problems of the web, then how about starting with yourself? Specifically, you and every programmer who writes software for the web. Computers Software is an engineering discipline just like any other. If you fail to apply proper engineering principles, you will fail. Those principles don't get learned overnight. They take years to cultivate and grow. Unfortunately, the industry wants fast answers and cheap programmers. They are rarely willing to pay for older programmers with strong skills to head up teams and ensure that the engineering is done right. Instead, they first try junior programmers, then outsourcing, then offshoring. All in an attempt to make a process cheaper by cutting corners.
You accuse me of trying to show off my "l33t"ness (whatever the hell that is). Well, how's this for "l33t"ness: A recent security advisory revealed that JSON objects were vulnerable to a cross-scripting exploit by the very nature of being serialized Javascript objects. It was mentioned that it was the first exploit that could target only AJAX-enabled applications. Well, I use JSON. And you know what I found when
Also, OOP is not bolted on in Javascript. It's been there since nearly the beginning. It's just that 99% of web coders never actually learned how to code Javascript.
I've been a Java programmer for about 11 years. In that time, I've explored the VM and libraries inside-out, upside-down, and sideways. The conclusion I've come to is that Java in the browser is a bad idea. At least in the form of the J2SE. If it had been developed more like a J2ME plugin with access to the DOM, it might have been a decent replacement for Javascript. But it wasn't developed that way, and now I think it's not in a very good position to compete in that space.
You bring me requirements, and I'll show you the magic that modern web technology can perform. And it's only going to get better. My comments about Server Side Events and XMLSocket are meant to mention how much better it's going to get. SSE will effectively obsolete Comet-style requests, resulting in rich server "push" systems that can transmit nearly anything to the client on demand. No need to worry about different XMLHttpRequest implementations, it will all be automatic in the browser. Opera already supports this, and thanks to the magic of Javascript, it's easy to branch to code that makes use of it when available. Wrap it in your libraries, and you're ready. to. ROCK!
Which is its strength as a platform, and its weakness as a scripting language. Don't get me wrong, the computer scientist in me wants to go with static typing. I love static typing. It makes all the bad problems go away. But the web coder in me knows that distributed document technology needs something more flexible. Dynamic typing as in Javascript is that flexibility.
It's slightly out of date, but you might find this article I wrote to be interesting. Web technologies are really accomplishing what Sun envisioned all those years ago.
Speak for yourself. I personally love Webstart technology. It's a beautiful solution to installing/launching applications in a cross-platform way. You just click, and it loads. No guarantees about the quality of content the developers package on the side, though.
Actually, ActiveX is a patented Microsoft Security Hole(TM) big enough to drive a Mack Truck through. Effectively, Microsoft looked at Java Applets and said, "The biggest problem with it is that it doesn't access Windows APIs and has all that security BS. We can do better." Next thing you know, Microsoft "partners" are showing how you can access DirectDraw and Direct3D to make ActiveX components that were WAY more impressive than the simplistic animations that Java was capable of. Of course, the security implications hit Microsoft less than a year later as Malware started exploiting the system for all kinds of nefarious purposes.
Microsoft kinda-sorta shuffled it off into other areas after that. Now they're back with a vengence. Silverlight will be everything that ActiveX was going to be, but BETTER! Can you feel the excitement?
Did it occur to you that you're sounding exactly like the hype you're decrying?
AJAX is a stupid name developed for the ole' hype machine (mostly to sell conferences and books, methinks) but the basic web technologies behind it are NOT THAT BAD. To use the example from the article, am I "tearing [my] hair out over as [I] attempt to get the JavaScript working in both Internet Explorer and Firefox?" Actually? No, I'm not. And I just implemented a Comet library in both Javascript and Actionscript. About the most frustrating thing was the fact that Opera ignored the cache-disable commands when using XML.load in Flash. So I build a solution into the library. And if you think that's fun, wait until I detect Server Side Events in Opera and use XMLSockets in Actionscript!
*shrug*
Oh, and I had to dynamically patch Safari and Opera to add support for the toSource function. Easy as for(var i in object) pie.
The problem with most "AJAX coders" is that they still think of Javascript as that cutesy language they used to do scrolling statusbar text with. But it simply isn't that bad. In fact, Javacript is a full-up, Object Oriented (or at least, OOP capable) langauge that fits the lightweight needs of the web browser perfectly. Java is a 600 pound gorilla that's better for designing heavyweight applications that are secure, robust, fast, and feature complete. The two target very different markets.
As for JavaFX, there is (if you'll excuse the expression) "nothing to see here". It's just a Silverlight competitor. Which makes it just as questionable as the product against which it's competing. If you really want a replacement for XMLHttpRequest, use XMLSocket instead,