Sun wasn't much better in this regard

I just reported a problem last week and got a response inside 12 hours. I was amazed. Certainly faster than I've ever gotten a response from Sun.

Average over the last 3 issues is about 48 hours - if accepted as a bug. But if you provide source code that demonstrates the problem turnaround is usually very fast, and that seems to be the case here.

So they're not falling over themselves to fix a bug which no one has noticed for 10+ years, and which hardly anyone is going to hit in actual use. Maybe they're spending their time fixing problems which are actually affecting developers.

Any public-facing Java server affected by this bug that accepts floating point numbers from the user as a string can be hung by this bug.

This is going to be a big problem.

Excellent point. I'm going to have some tests to run when I get in to work this morning.

Yup. A comment on the original webpage reported that this value appears to hang/time-out Google Spreadsheet. I tested and it indeed was the case. So there are going to be lots of places one can fool around on the input side only to send the server thread into a loop. That's bad.

And yet...in 10+ years...it hasn't been a problem? Certainly the need to fix it but saying it is going to be a "big problem" is a bit theatrical.

Well, yeah. Nobody _accidentally_ hit upon this number, but now that it's a known way to commit a denial of service attack, people are going to take advantage of it.

Imagine your response, but about a kernel privilege escalation bug:

"And yet...in 10+ years...it hasn't been a problem? Certainly the need to fix it but saying it is going to be a "big problem" is a bit theatrical."

I tried to dig up a list of websites with a java-backend but my google-fu is not strong enough. I don't think that there are actually many big sites running on java.

There are tons of sites running on java. Possibly more than php.

Yup - http://wiki.java.net/bin/view/Projects/RealWorldJSFLinks

Anecdotally, a lot of those [\w+]tube porn sites probably run on a Java server considering the heavy lifting that goes on there.

Most of internet banking systems in my country run on Java. And most of them can be affected if you know where to put this number.

Yes, but fortunately, there is not much reason why anybody would use double when developing a banking system.

They don't have to use it directly.

GET / HTTP/1.0

Accept-Language: en;q=2.2250738585072012e-308

If you're running Tomcat and you call getLocale() on that servlet request, you're toast.

This is precisely why "q" is defined only to accept three digits after the decimal. It's actually not a floating point number, and anyone who parses it as such is just being lazy.

"q" is more properly represented natively as an integer between 0 and 1000.

apparently q is not properly parsed in JBoss which is based on apache tomcat scaring not?