What vitriol? Pointing out that you're citing issues with one language while ignoring those in the other is not vitriol.
Java is not perfect, I just happen to consider it better than its competitors for soe of the reasons I have outlined.
You still haven't said what those issues are, just used ambiguous terms like 'awful porting nonsense' and 'dumb loopholes' and 'vile and unnatural', those aren't reasons used to justify something by people who know what they are talking about.
So, by all means, please continue using and advocating C++ rather than more modern solutions:)
I'm not using or advocating C++, i'm just pointing out that you clearly have no idea what you're talking about.
With regard to the "awful porting nonsense" I'm afraid I have to stand by my comment. Apart from trivial applications and even with good libraries it is still fairly painful to port a large application between Linux, Windows and Mac OS X.
You can stand by those comments all you want, but since you can't explain specifically what you mean they are just baseless.
It is possible to leak memory even using these in a long running application.
It's possible to leak memory in Java too, you're always reliant on the JVM, like the memory leak with File.deleteOnExit, the memory leak in the Apple JVM with BufferedImage or probably the worst ones being ClassLoader leaks. The ignorant attitude towards Java memory leaks is a problem, everyone reckons 'oh it's ok, Java cleans up all the memory and can't have memory leaks', which is rubbish if you know anything about Java.
There are plenty of strategies for dealing with memory management (smart points, basic ref counting, etc...), but you prefer to not worry about that and that's your main concern then yes a GC language will serve you better.
So, on Slashdot it seems very fashionable to 'dis' Java as not 'l337' enough (and hence crufty and outmoded C++ is considered more leet), but I find Java an excellent go-to language for a very wide range of problems (webapp using GWT, embedded, and even my rich-client flight simulator).
I certainly don't have an issue there, for example i certainly wouldn't be writing a basic webserver in c++ over using something like node.js. I also don't see any problem with Java for client-side applications (i'd naturally avoid it for webapps given the amount of nasty security issues thanks to the browser plugin).
Anyway this seems to have gone far from the topic of what specifically you were referring to by 'awful porting nonsense', 'dumb c++ loopholes' and these different libraries for different platforms that were forcing you to change your architecture.
If you don't like it that's fine, that's not really any kind of objective criticism though. If you don't like Qt there's always other options like wxWidgets, FLTK, etc...
Effective sure
Which is why so many people use it.
The C++ code itself is nothing.
Which is why your post was so baffling.
What matters is that for each platform you target you need different libraries, and each library has its own idiom.
But you don't, there are so many cross-platform libraries. You get the same when targeting Android with Java anyway, you can't just use Swing like on other platforms.
Then you end up contorting your architecture for each set of libraries you are trying to integrate.
Do you have a specific example of why you did this?
This is not impossible (I've written lots of portable, complex C++ in the last two decades) but I can tell you it is *vastly* easier, more consistent, and I would argue more performant (since the time I save not fixing dumb C++ loopholes I instead spent optimizing my Java) to use Java.
This all depends on your proficiency, not sure what these 'dumb C++ loopholes' you're referring to are, could you be specific?
Flightgear is an admirable bit of software. I looked at extending it but realized after two decades of C++ and a decade of Java I knew which language to base a new *reliable* multi-player, multi-core product on.
So what specifically makes Java more reliable?
So I understand your advocacy for C++.
What advocacy for C++?
Java becomes the better choice for new heavily multi-threaded stuff, IMHO.
FlightGear is a multi-platform (Windows, OS/X, Linux) written in C++ and QT. Seems to work well enough for them.
That's what i was thinking, writing portable c++ code isn't complicated, the obvious thing that is difficult is if you use platform-specific toolkits rather than something cross-platform like Qt.
If you would please suggest a useful alternative to Java that was cross-platform and I didn't have to go through all the awful porting nonsense of C++ or C#/Mono (been there done that, don't want to do it again) for my flight sim then I'm all ears.
What 'awful porting nonsense' did you have with c++ code?
How is it any different? You call the datasource provider API or you call the local API, no difference from the developer effort perspective, you still have to update your app data based on the result, whether that comes from the local API calling the external datasource or just calling the external datasource directly.
Why maintain a source for getting the current time as an API call in Android when you can tell app developers that they're on their own.
Because - unlike weather forecasts that differ between sources - the time is the time, if it differs between sources then it's incorrect, so comparing time to weather is obviously not relevant.
After all, they can use the GPS to get the time. Or the cell network signal. Or a time server online. Or keep their app running all the time and use a timer, ask the user to set the time once and then just figure out the time based on number of ticks elapsed + the time initially set and a LUT for daylight savings for a given locale. Or maybe the cellphone supports WWVB and you can tap into that.
And they should all give the same result, unlike weather forecasts and other weather data which depends on the sensors used by the datasource and bureau providing the data, the time is either correct or incorrect.
On the other hand, Google already saw fit to make a location API so that any app that wants to know the user's location can simply poll that
Because again, the location is either correct or incorrect, you always just want the most accurate one, which is the most accurate weather data source? which is the most accurate forecast?
Except that it doesn't work just fine as soon as that data source becomes unavailable, changes format, etc.
And that's why you use a maintained and supported API like one of the 5 i linked to earlier, like WeatherBug, Weather Channel, etc...
I get it, though - you're vehemently opposed to suggesting that Google add an API. Not sure what your reasoning is other than "there's already third party data sources". I don't see the harm you're seeing in adding one, I guess.
No, my reasoning is quite clear and logical and is the very reason such an API does not exist within android (or iOS or Windows Mobile/Phone or any Blackberry OS). Suggesting an API should be added simply as an intermediary to a totally external datasource like weather just to cache data that may or may not even be accurate is showing a fundamental misunderstanding of the reason for having built-in APIs like time and location (which utilize the inbuilt hardware of the platform) and external APIs which have nothing whatsoever to do with the inbuilt hardware.
Yeah, I'm sure if windows phone 8 takes off devs are going to bother being backward compatible with a dead platform with next to no users. Tell me another one.
Then who cares? If the platform has no users then being backwards compatible serves no purpose. The only thing that would matter would be going forwards, which doesn't appear to be a big deal.
But if for any reason whatsoever the chosen data source disappears, there would still be the built-in API to fall back to.
And would be the source for that API's data? Why not just go directly to the API of that datasource instead like you do now? And why maintain a source for a weather API when there are already so many weather APIs provided by the datasource maintainer out there? It makes no sense. Would you do the same for all external data sources or just weather?
Whether there is any sanity in having that many apps with weather info in the first place may be a point of contention - but it's there, might as well try to cater to it.
No, you might as well leave it the way it is because it works just fine and works the same as all other external data sources.
Sorry, not even close. It's a shame the climate on slashdot is as such that I have to actually type this out to justify my point of view without being labeled a shill.
It's not everyone, just some people on here that either think using the 'shill' label is an adequate rebuttal when discussing Microsoft or use the 'shill' label to attempt to gain the upper hand in the argument (like the 'I realize you're trolling, but I'll bite' method of starting a response).
I bought all the aforementioned products (except Windows 8, which I have through Dreamspark Premium) after comparing them with the competition and choosing which is best for me, given my requirements.
You'll find quite a lot of people on here do the same thing. I use Windows at work and a bit at home but i mostly use OSX (laptops and mac mini), i have an xbox (and ps3), had an ipad (but found i never really used it) and i had a WP7 phone and really liked it (i reckon the platform is brilliant) but the iphone made more sense because the apps i wanted weren't available on it at the time and while I use OSX predominantly at home the Windows Phone connector software is pretty average. I'm really torn on whether to go with Windows Phone 8 or the next iPhone, i really like WP but the iphone is kind of the bog standard choice and the support at the apple store if something goes wrong is great!
Now a lot of people - like me - just avoid posting anything positive about experiences with Microsoft products, or things Microsoft is doing well because it's not worth the effort given that it will likely just be down-modded and flooded with 'Shill' and 'Troll' responses. Windows Phone actually is objectively a good product, but instead of discussion on its merits you get detractors going back in time to discuss Windows Mobile instead or Microsoft's past business practices or dismissing it for its low marketshare (Linux and OSX can have low desktop marketshare though, that's ok).
All discussions revolve around the most subjective and personal aspect of the OS (and also the most customizable): the UI.
Actually it's only one aspect of the UI, the start screen, and some people will act as though this one element is the be all and end all of the entire operating system yet if they had done Windows 8 with the start menu you'd have people saying 'why should i upgrade, it's no different'.
What really scares me, though, is that you put me in front of an Apple laptop and I suddenly don't know WTF I'm doing, even though I can work the innards of Linux with little problem. I am pretty glad that I'm enough computer savvy to have the option of not using Windows or iOS.
So is there something specific or are you just completely baffled by OSX? It's not really much different to any of the other unix-like OSes out there so i don't see how you can be so confused by it if you are as computer savvy as you claim to be.
Sorry, I should have made it more clear in my post that I meant that Google should offer the API as a part of Android (similar to the location API).
Well in terms of location there's no 2 ways about it, your location is your location...as for weather forecasts they vary based on the source of the information and the way it is interpreted.
I know there's plenty of other weather APIs available, and most of the better weather apps do let you choose.
And that's really the best way, let you choose your source.
But given the popularity of weather apps (full apps, widgets, notification services, etc.) I think it would make sense for an API to be available within Android itself. This can then poll and cache results so that apps X, Y and Z can all grab the exact same information without actually submitting 3 separate queries (which sometimes results in app X saying it's cloudy while app Y says it's clear skies depending on when the online service last updated their data).
So what happens to being able to choose your source? Caching that data would only have any benefit if you had a bunch of different weather apps showing the same data, which is pointless.
So in other words the idea that "statistically nobody wants to play video games developed by people with no experience in the mainstream video game industry" is actually false, there are no statistics at all, just a couple of posts on Slashdot...seems you need to think before you just extrapolate the opinions of nobodies.
A regular on Slashdot who has in the past worked with PS2 Linux
Actually he said he was part of the SCEA PS2 Linux community and not a programmer, so what, a forum member? Great source.
Yeah, and some teenager working on his hobby program late at night might actually want to send his code to other people, so that they can run it and possibly work with him.
Yet that is exactly the message that people like CronoCloud keep telling me: statistically nobody wants to play video games developed by people with no experience in the mainstream video game industry.
Then CronoCloud - whoever the hell that is - is incorrect, unless of course you want to show these statistics? Because games on iOS and Android seem to thrive if they are good regardless of whether the developer has prior experience or not.
If they hold a copyright/patent on it, then they should be compelled to license it to keep that copyright protection, or it should released into the public domain.
And do they in this case? No. So what's your point?
Is it asking too much of a company whose motto is "Don't be evil" to have given a week or two of warning or at least to have spent a minute or two setting up a meaningful and informative error page? Come on Google, you can do better...
And if it were a supported API it would have that, but it's pretty clearly not a supported API.
I tend to think that those vulnerabilities are there already, whether you use them or not. Browsers support SVG and whatnot, so those are already there whether beneficial developers are using them or not.
I see your point, yes they are there to a degree but at this stage no browser even fully implements the 'standards' yet and they aren't widely used, much better to target Java as you know just about everyone has it installed. Once everyone has a HTML5/Canvas/SVG/AJAX/etc... compliant browser installed that will become a much larger target
I don't think there are vulnerabilities specific to individual toolkits like jQuery or Prototype
Those were specifically generating vulnerable code.
So it's up to the browser vendors to fix those, and for the most part they are doing a decent job at it.
The real concern there is that browser makers have enough trouble with vulnerabilities without taking everything Java is used for and having to maintain that too.
So the way I see it, you already have the vulnerabilities present in the browser and adding plugins like Java or Acrobat are just going to increase the attack surface. Using technologies like SVG or WebGL or other relatively new and high-level things aren't going to add any new vulnerabilities, because they're there whether you use them or not, but eliminating Java or Acrobat or Flash should in theory make you safer.
I agree, but from an attacker's perspective why bother with HTML5/Canvas/SVG/AJAX when there is much more chance that your target will have Java, sure they aren't any more secure but they aren't as ubiquitous, when things shift the other way so will the attackers. Yes we will see a significant reduction of Java from the browser but then HTML5/Canvas/SVG/AJAX will just become the target with already-struggling browser security teams having to deal with all of that too.
So i see your point but i don't think the overall amount of infections/vulnerabilities is going to change, it will just be what technologies are exploited. But yes if you don't need Java you might as well uninstall it.
Just out of curiosity, what percentage of infections are the result of attacking those exploits?
I don't know, those were just examples to illustrate that replacing Java will eliminate Java exploits but introduce new ones because not only are there a bunch of replacement technologies there are a bunch of different implementations of them. HTML5/Canvas/SVG/AJAX is demonstrably no more secure than Java, i find the technologies themselves to be better and that would be my case for switching to them but to make a case for them on a security basis is just ignorant of the fact that they are not inherently any more secure.
Java is responsible for 37% of infections on Windows machines, how many infections were caused by exploiting Xajax, or MochiKit?
I don't know, i'm not saying Java is better, clearly you would have to correlate Java infections with the installbase of Java vs the various technologies replacing it as well as the amount of use of them, but that would end up convoluted and inaccurate and isn't even relevant unless you're trying to make a case for one over the other...which i am not.
Can you point to a reference for anyone using Safari who got an infection via SVG?
No.
More importantly, does installing Java eliminate all of those other vulnerabilities, or does it just add new ones?
I don't think that's important, in fact i would think you'd have to be an idiot to think installing Java eliminated those vulnerabilities at all. I'm not pro-Java (in fact i don't really like Java, Java applications just don't feel right on desktops/laptops) i'm just saying that eliminating Java and switching to HTML5/Canvas/SVG/AJAX/etc... doesn't make security problems go away because Java isn't inherently less secure than those technologies, we'll just see vulnerabilities in all the implementations of those instead.
...while eliminating all security issues around Java.
In exchange for security issues in a bunch of other technologies across a number of implementations, great tradeoff! Like the SVG Remote Execution Exploit in Safari, or the SVG Font Manipulation Vulnerability in Opera, or Mozilla's cross-origin data theft canvas vulnerability or the AJAX Javascript hijacking bug found by Fortify that affected applications built with Xajax, GWT, jQuery, Prototype, Dojo, Moo.fx, Yahoo.UI, Microsoft Atlas, MochiKit, etc...
Slashdot Mirror
Now try doing that on Windows RT (the ARM version).
That's like Firefox on iOS, but it's ok because it - like WindowsRT - doesn't have a monopolistic position.
Why the vitriol?
What vitriol? Pointing out that you're citing issues with one language while ignoring those in the other is not vitriol.
Java is not perfect, I just happen to consider it better than its competitors for soe of the reasons I have outlined.
You still haven't said what those issues are, just used ambiguous terms like 'awful porting nonsense' and 'dumb loopholes' and 'vile and unnatural', those aren't reasons used to justify something by people who know what they are talking about.
So, by all means, please continue using and advocating C++ rather than more modern solutions :)
I'm not using or advocating C++, i'm just pointing out that you clearly have no idea what you're talking about.
With regard to the "awful porting nonsense" I'm afraid I have to stand by my comment. Apart from trivial applications and even with good libraries it is still fairly painful to port a large application between Linux, Windows and Mac OS X.
You can stand by those comments all you want, but since you can't explain specifically what you mean they are just baseless.
It is possible to leak memory even using these in a long running application.
It's possible to leak memory in Java too, you're always reliant on the JVM, like the memory leak with File.deleteOnExit, the memory leak in the Apple JVM with BufferedImage or probably the worst ones being ClassLoader leaks. The ignorant attitude towards Java memory leaks is a problem, everyone reckons 'oh it's ok, Java cleans up all the memory and can't have memory leaks', which is rubbish if you know anything about Java.
So, on Slashdot it seems very fashionable to 'dis' Java as not 'l337' enough (and hence crufty and outmoded C++ is considered more leet), but I find Java an excellent go-to language for a very wide range of problems (webapp using GWT, embedded, and even my rich-client flight simulator).
I certainly don't have an issue there, for example i certainly wouldn't be writing a basic webserver in c++ over using something like node.js. I also don't see any problem with Java for client-side applications (i'd naturally avoid it for webapps given the amount of nasty security issues thanks to the browser plugin).
Anyway this seems to have gone far from the topic of what specifically you were referring to by 'awful porting nonsense', 'dumb c++ loopholes' and these different libraries for different platforms that were forcing you to change your architecture.
Sorry, QT is vile and unnatural, IMHO.
If you don't like it that's fine, that's not really any kind of objective criticism though. If you don't like Qt there's always other options like wxWidgets, FLTK, etc...
Effective sure
Which is why so many people use it.
The C++ code itself is nothing.
Which is why your post was so baffling.
What matters is that for each platform you target you need different libraries, and each library has its own idiom.
But you don't, there are so many cross-platform libraries. You get the same when targeting Android with Java anyway, you can't just use Swing like on other platforms.
Then you end up contorting your architecture for each set of libraries you are trying to integrate.
Do you have a specific example of why you did this?
This is not impossible (I've written lots of portable, complex C++ in the last two decades) but I can tell you it is *vastly* easier, more consistent, and I would argue more performant (since the time I save not fixing dumb C++ loopholes I instead spent optimizing my Java) to use Java.
This all depends on your proficiency, not sure what these 'dumb C++ loopholes' you're referring to are, could you be specific?
Flightgear is an admirable bit of software. I looked at extending it but realized after two decades of C++ and a decade of Java I knew which language to base a new *reliable* multi-player, multi-core product on.
So what specifically makes Java more reliable?
So I understand your advocacy for C++.
What advocacy for C++?
Java becomes the better choice for new heavily multi-threaded stuff, IMHO.
Why is that?
FlightGear is a multi-platform (Windows, OS/X, Linux) written in C++ and QT. Seems to work well enough for them.
That's what i was thinking, writing portable c++ code isn't complicated, the obvious thing that is difficult is if you use platform-specific toolkits rather than something cross-platform like Qt.
If you would please suggest a useful alternative to Java that was cross-platform and I didn't have to go through all the awful porting nonsense of C++ or C#/Mono (been there done that, don't want to do it again) for my flight sim then I'm all ears.
What 'awful porting nonsense' did you have with c++ code?
Whatever Google would decide.
Well that could be anything.
Saves you having to poll the data yourself.
How is it any different? You call the datasource provider API or you call the local API, no difference from the developer effort perspective, you still have to update your app data based on the result, whether that comes from the local API calling the external datasource or just calling the external datasource directly.
Why maintain a source for getting the current time as an API call in Android when you can tell app developers that they're on their own.
Because - unlike weather forecasts that differ between sources - the time is the time, if it differs between sources then it's incorrect, so comparing time to weather is obviously not relevant.
After all, they can use the GPS to get the time. Or the cell network signal. Or a time server online. Or keep their app running all the time and use a timer, ask the user to set the time once and then just figure out the time based on number of ticks elapsed + the time initially set and a LUT for daylight savings for a given locale. Or maybe the cellphone supports WWVB and you can tap into that.
And they should all give the same result, unlike weather forecasts and other weather data which depends on the sensors used by the datasource and bureau providing the data, the time is either correct or incorrect.
On the other hand, Google already saw fit to make a location API so that any app that wants to know the user's location can simply poll that
Because again, the location is either correct or incorrect, you always just want the most accurate one, which is the most accurate weather data source? which is the most accurate forecast?
Except that it doesn't work just fine as soon as that data source becomes unavailable, changes format, etc.
And that's why you use a maintained and supported API like one of the 5 i linked to earlier, like WeatherBug, Weather Channel, etc...
I get it, though - you're vehemently opposed to suggesting that Google add an API. Not sure what your reasoning is other than "there's already third party data sources". I don't see the harm you're seeing in adding one, I guess.
No, my reasoning is quite clear and logical and is the very reason such an API does not exist within android (or iOS or Windows Mobile/Phone or any Blackberry OS). Suggesting an API should be added simply as an intermediary to a totally external datasource like weather just to cache data that may or may not even be accurate is showing a fundamental misunderstanding of the reason for having built-in APIs like time and location (which utilize the inbuilt hardware of the platform) and external APIs which have nothing whatsoever to do with the inbuilt hardware.
Yeah, I'm sure if windows phone 8 takes off devs are going to bother being backward compatible with a dead platform with next to no users. Tell me another one.
Then who cares? If the platform has no users then being backwards compatible serves no purpose. The only thing that would matter would be going forwards, which doesn't appear to be a big deal.
If wp8 takes off, you can say bye-bye to wp7 development because who in their right mind wastes money devving for a platform with no users.
In that case who cares? Saying bye-bye to wp7 development has no effect if the platform has no users.
But if for any reason whatsoever the chosen data source disappears, there would still be the built-in API to fall back to.
And would be the source for that API's data? Why not just go directly to the API of that datasource instead like you do now? And why maintain a source for a weather API when there are already so many weather APIs provided by the datasource maintainer out there? It makes no sense. Would you do the same for all external data sources or just weather?
Whether there is any sanity in having that many apps with weather info in the first place may be a point of contention - but it's there, might as well try to cater to it.
No, you might as well leave it the way it is because it works just fine and works the same as all other external data sources.
Sorry, not even close. It's a shame the climate on slashdot is as such that I have to actually type this out to justify my point of view without being labeled a shill.
It's not everyone, just some people on here that either think using the 'shill' label is an adequate rebuttal when discussing Microsoft or use the 'shill' label to attempt to gain the upper hand in the argument (like the 'I realize you're trolling, but I'll bite' method of starting a response).
I bought all the aforementioned products (except Windows 8, which I have through Dreamspark Premium) after comparing them with the competition and choosing which is best for me, given my requirements.
You'll find quite a lot of people on here do the same thing. I use Windows at work and a bit at home but i mostly use OSX (laptops and mac mini), i have an xbox (and ps3), had an ipad (but found i never really used it) and i had a WP7 phone and really liked it (i reckon the platform is brilliant) but the iphone made more sense because the apps i wanted weren't available on it at the time and while I use OSX predominantly at home the Windows Phone connector software is pretty average. I'm really torn on whether to go with Windows Phone 8 or the next iPhone, i really like WP but the iphone is kind of the bog standard choice and the support at the apple store if something goes wrong is great!
Now a lot of people - like me - just avoid posting anything positive about experiences with Microsoft products, or things Microsoft is doing well because it's not worth the effort given that it will likely just be down-modded and flooded with 'Shill' and 'Troll' responses. Windows Phone actually is objectively a good product, but instead of discussion on its merits you get detractors going back in time to discuss Windows Mobile instead or Microsoft's past business practices or dismissing it for its low marketshare (Linux and OSX can have low desktop marketshare though, that's ok).
All discussions revolve around the most subjective and personal aspect of the OS (and also the most customizable): the UI.
Actually it's only one aspect of the UI, the start screen, and some people will act as though this one element is the be all and end all of the entire operating system yet if they had done Windows 8 with the start menu you'd have people saying 'why should i upgrade, it's no different'.
What really scares me, though, is that you put me in front of an Apple laptop and I suddenly don't know WTF I'm doing, even though I can work the innards of Linux with little problem. I am pretty glad that I'm enough computer savvy to have the option of not using Windows or iOS.
So is there something specific or are you just completely baffled by OSX? It's not really much different to any of the other unix-like OSes out there so i don't see how you can be so confused by it if you are as computer savvy as you claim to be.
Sorry, I should have made it more clear in my post that I meant that Google should offer the API as a part of Android (similar to the location API).
Well in terms of location there's no 2 ways about it, your location is your location...as for weather forecasts they vary based on the source of the information and the way it is interpreted.
I know there's plenty of other weather APIs available, and most of the better weather apps do let you choose.
And that's really the best way, let you choose your source.
But given the popularity of weather apps (full apps, widgets, notification services, etc.) I think it would make sense for an API to be available within Android itself. This can then poll and cache results so that apps X, Y and Z can all grab the exact same information without actually submitting 3 separate queries (which sometimes results in app X saying it's cloudy while app Y says it's clear skies depending on when the online service last updated their data).
So what happens to being able to choose your source? Caching that data would only have any benefit if you had a bunch of different weather apps showing the same data, which is pointless.
I think the question is, or should be, why isn't there a supported API?
What are you on about? Here's a list of 5 weather APIs.
A regular on Slashdot who has in the past worked with PS2 Linux
Actually he said he was part of the SCEA PS2 Linux community and not a programmer, so what, a forum member? Great source.
The iPad (or my slow-ass Kobo Vox) and Logitech keyboard fit in my CamelBak backpack perfectly. A laptop will not.
A 9.7" tablet + keyboard fits but an 11" MacBook Air doesnt?
Yeah, and some teenager working on his hobby program late at night might actually want to send his code to other people, so that they can run it and possibly work with him.
And why can't you do that?
Yet that is exactly the message that people like CronoCloud keep telling me: statistically nobody wants to play video games developed by people with no experience in the mainstream video game industry.
Then CronoCloud - whoever the hell that is - is incorrect, unless of course you want to show these statistics? Because games on iOS and Android seem to thrive if they are good regardless of whether the developer has prior experience or not.
Well goody for them...
Why?
My point remains, don't look to Google for long term anything.
The more pertinent point would be 'don't use unsupported APIs regardless of who provides them'.
If they hold a copyright/patent on it, then they should be compelled to license it to keep that copyright protection, or it should released into the public domain.
And do they in this case? No. So what's your point?
Is it asking too much of a company whose motto is "Don't be evil" to have given a week or two of warning or at least to have spent a minute or two setting up a meaningful and informative error page? Come on Google, you can do better...
And if it were a supported API it would have that, but it's pretty clearly not a supported API.
I tend to think that those vulnerabilities are there already, whether you use them or not. Browsers support SVG and whatnot, so those are already there whether beneficial developers are using them or not.
I see your point, yes they are there to a degree but at this stage no browser even fully implements the 'standards' yet and they aren't widely used, much better to target Java as you know just about everyone has it installed. Once everyone has a HTML5/Canvas/SVG/AJAX/etc... compliant browser installed that will become a much larger target
I don't think there are vulnerabilities specific to individual toolkits like jQuery or Prototype
Those were specifically generating vulnerable code.
So it's up to the browser vendors to fix those, and for the most part they are doing a decent job at it.
The real concern there is that browser makers have enough trouble with vulnerabilities without taking everything Java is used for and having to maintain that too.
So the way I see it, you already have the vulnerabilities present in the browser and adding plugins like Java or Acrobat are just going to increase the attack surface. Using technologies like SVG or WebGL or other relatively new and high-level things aren't going to add any new vulnerabilities, because they're there whether you use them or not, but eliminating Java or Acrobat or Flash should in theory make you safer.
I agree, but from an attacker's perspective why bother with HTML5/Canvas/SVG/AJAX when there is much more chance that your target will have Java, sure they aren't any more secure but they aren't as ubiquitous, when things shift the other way so will the attackers. Yes we will see a significant reduction of Java from the browser but then HTML5/Canvas/SVG/AJAX will just become the target with already-struggling browser security teams having to deal with all of that too.
So i see your point but i don't think the overall amount of infections/vulnerabilities is going to change, it will just be what technologies are exploited. But yes if you don't need Java you might as well uninstall it.
Just out of curiosity, what percentage of infections are the result of attacking those exploits?
I don't know, those were just examples to illustrate that replacing Java will eliminate Java exploits but introduce new ones because not only are there a bunch of replacement technologies there are a bunch of different implementations of them. HTML5/Canvas/SVG/AJAX is demonstrably no more secure than Java, i find the technologies themselves to be better and that would be my case for switching to them but to make a case for them on a security basis is just ignorant of the fact that they are not inherently any more secure.
Java is responsible for 37% of infections on Windows machines, how many infections were caused by exploiting Xajax, or MochiKit?
I don't know, i'm not saying Java is better, clearly you would have to correlate Java infections with the installbase of Java vs the various technologies replacing it as well as the amount of use of them, but that would end up convoluted and inaccurate and isn't even relevant unless you're trying to make a case for one over the other...which i am not.
Can you point to a reference for anyone using Safari who got an infection via SVG?
No.
More importantly, does installing Java eliminate all of those other vulnerabilities, or does it just add new ones?
I don't think that's important, in fact i would think you'd have to be an idiot to think installing Java eliminated those vulnerabilities at all. I'm not pro-Java (in fact i don't really like Java, Java applications just don't feel right on desktops/laptops) i'm just saying that eliminating Java and switching to HTML5/Canvas/SVG/AJAX/etc... doesn't make security problems go away because Java isn't inherently less secure than those technologies, we'll just see vulnerabilities in all the implementations of those instead.
...while eliminating all security issues around Java.
In exchange for security issues in a bunch of other technologies across a number of implementations, great tradeoff! Like the SVG Remote Execution Exploit in Safari, or the SVG Font Manipulation Vulnerability in Opera, or Mozilla's cross-origin data theft canvas vulnerability or the AJAX Javascript hijacking bug found by Fortify that affected applications built with Xajax, GWT, jQuery, Prototype, Dojo, Moo.fx, Yahoo.UI, Microsoft Atlas, MochiKit, etc...