Recent Apple Java Update Doesn't Fix Critical Java Flaw Claims Researcher

hypnosec writes "Just yesterday Apple released updates to fix Java vulnerabilities, but it seems the patch doesn't actually target the recently discovered high-profile Java bug that has been the talk of the web during the last two weeks. The two updates – Java for OS X 2012-005 for OS X Lion and Java for Mac OS X 10.6 Update 10 for Mountain Lion, are meant to tackle the vulnerability described in CVE-2012-0547. But according to KerbsOnSecurity, it seems Cupertino hasn't addressed the recent mega-vulnerabilities in Java as described in CVE-2012-4681." Update: 09/07 12:00 GMT by S : As readers have pointed out, these updates address flaws in Java 6, which is the version Apple maintains. The recently-reported Java vulnerabilities primarily affect Java 7, the patching of which is handled solely by Oracle. Nothing to see here.

Comments

Huh?

[Anonymous Coward]

Isn't it Oracle's job to maintain Java on OS X now that Apple kicked it to the curb?

Re:Huh?

[Anonymous Coward]

Apple probably copied the patch wrong.

http://i.imgur.com/PMXXr.jpg

Re:Huh?

[Anonymous Coward]

No, the issue is the patch they received from Oracle didn't fix the issue people expected. Apple rightfully got rid of Java in the default OS install. If you install malware on your system voluntarily it's you're own fault that it damages your system.

Re:Huh?

[SplashMyBandit]

Java is malware now? Talk about flamebait from an AC. If Java is malware then so it MSVCRT and Internet Explorer. Talk about hyperbole!

Re:Huh?

[fm6]

Not sure what you mean by "kicked to the curb", but OS X Java is still maintained by Apple.

Re:Huh?

[Anonymous Coward]

By "kicked to the curb" they no longer install Java by default on the OS and Oracle is the one providing Java 7 for OS X not Apple.

Re:Huh?

[Lunix Nutcase]

How is it hyperbole? Look at Secunia. There are more than 1000 vulnerabilities between the combined versions of the JVM. They average around 200 per version which is actually worse than Flash player.

Re:Huh?

[SplashMyBandit]

What do you get for a similar search of "Windows"? (that is also another "platform", just as the JVM is). My point is not that Java is without vulnerabilities - clearly it has them - but that calling it "malware" is misleading since anything with a similar large amount of functionality also has a lot of attack surface. So the hyperbole ought to be cut. k?

Re:Huh?

[kybred]

Not sure what you mean by "kicked to the curb", but OS X Java is still maintained by Apple.

Not completely. Apple maintains Java for Mac OS X through version 6. Oracle took over starting with version 7. It's not clear how long Apple will continue to provide updates for version 6, though.

Apple stopped including it as a default install with Lion (Mac OS X 10.7), I believe.

Re:Huh?

[fm6]

I stand corrected, About 18 months ago, I was writing the installation docs for a Java application that had to run on Mac, and I went to rather a lot of trouble to find out how to configure Java on the Mac. (The main reason I got the job: they'd had bad experiences with users on various platforms who didn't understand Java runtime idiosyncrasies.) I was actually quite impressed by the way OS X support for Java worked — very elegant and carefully thought out,

Now I suppose my work will have to be thrown out and replaced by the cruder procedures Oracle uses. Oh well.

Re:Huh?

[dgatwood]

That's not a fair comparison. Users don't realistically have a choice about whether to run an OS. They do have a choice whether to add additional vulnerabilities by tacking on an unnecessary abstraction layer like Flash or Java.

Re:Huh?

[SplashMyBandit]

Huh? users can choose a less vulnerable O/S. Also, users will be secure if they don't install anything at all - but that is kinda doing a "denial of service" on themselves. So calling Java "malware" and saying "just don't install it" kinda seems non-sensical to me (especially since Java is not alone in potential attack surface - I mean, most would consider it ridiculous to not install Flash on the modern web browser, or not install MS Office [with all the macro viruses], or Adobe Reader - yet that is exactly what the grandparent poster was proposing for Java).

Re:Huh?

[Anonymous Coward]

Why is it ridiculous not to install Adobe Reader?
I avoid this program like the plague, and trust me I can still view PDF files.
Better yet, I can do many things that Adobe does not support in its free reader (and requires the full Acrobat package).

Re:Huh?

[hairyfeet]

Uhhh...comparing a single program to an entire OS, made up of hundreds of programs and millions of lines of code? We are talking about a single program with over 200 vulnerabilities per version here friend, that's not just bad, that is downright criminally shoddy!

This is why I no longer include Java in my default install base, its security is like a really bad joke. For all the remarks about Flash at least they have gotten better, look at Securina and you'll see Java has been shitty from the start and continues to be absolutely abysmal when it comes to security!

Re:Huh?

[SplashMyBandit]

Java is a single program? Do you have any idea about what you are talking about halfling?

Re:Huh?

[redback]

your.

Re:Huh?

[RaceProUK]

a single program with over 200 vulnerabilities per version

I count 20+ programs in a typical Windows Java installation.

Also, how does this 200+ compare to other frameworks, like Flash or Silverlight?

Re:Huh?

[dgatwood]

Huh? users can choose a less vulnerable O/S

Except that users cannot choose a less vulnerable OS. All OSes have significant numbers of vulnerabilities in that database.

most would consider it ridiculous to not install Flash on the modern web browser... or Adobe Reader....

Actually, that's exactly what I'm arguing. You should not install Flash. Or Adobe Reader (at least the plug-in version of it). Or Java.

Also, users will be secure if they don't install anything at all.

In theory, yes. In practice, web browsers are much more critical as far as vulnerabilities go because they are constantly being exposed to untrusted content. Most applications are not. Software that runs in that environment has to be extremely well written. Browsers are fairly well written, with remarkably few serious security holes. Flash is the exact opposite. Adobe Reader and Java are somewhere in-between.

... or not install MS Office [with all the macro viruses] ...

That one is a little different. It isn't hard to avoid that risk. Just don't use MS Office to open content that other people send you. You can't do that with a web browser, and because Java, Flash, and Adobe Reader run *in* a browser, you can't readily avoid using them to open content that other people send you, either. Your only option for improving the security of those tools, short of fixing all the security holes, is to not install them, or at minimum, to use something like ClickToFlash to disable them except on specific, user-chosen websites. The danger of that approach, however, is that websites will interpret the presence of those sorts of extensions as an indication that you have the plug-in in question, and will fail to fall back to alternative technologies even when available. Also, their stats will show that those plug-ins are still available almost everywhere, thus slowing the demise of those (almost always unnecessary) browser plug-ins.

Yes, in the short term, refusing to install those plug-ins may cause some temporary pain (though not much—I can only think of a handful of sites that I've visited in the past five years that required Flash, and exactly one that required Java; PDF is on its way out as an end-user delivery medium, too, as HTML/CSS improves), but as more people do this, fewer companies will grow to rely on those technologies, and the need for using them will continue to diminish. The advent of iOS went a long way towards killing these technologies, and the web is a safer place for their absence. The next step is up to the desktop user community and the developer community.

To the extent that Flash or Java are necessary to work around lack of features in a browser, file bugs and propose solutions. To the extent that websites require Flash or Java, complain to the site admins, and then don't go to those sites. When web browser developers have to go to insane lengths like running each tab in a separate process so that when Flash crashes (frequently), it doesn't take down the whole browser, it should be obvious that there's a problem. More precisely, when it represents the vast majority of browser crashes, there's a BIG problem. And although Java doesn't cause nearly as many browser crashes (possibly in part because there are many, many fewer sites that actually use Java), it has still had an abysmal security record lately, having been the sole successful vector for compromising OS X in recent memory. Any platform that is being actively used as a vector for compromising users' computers is a serious security risk and should be avoided unless there is no other alternative.

Re:Huh?

[SplashMyBandit]

I understand your point of view. One of my points was that "Java" is more than the Java Applet, so care has to be made to differentiate the terms. The other thing is I have written Java applets and were forced to because HTML/CSS is just not functional enough at the moment. Sure, you can do simple form-based stuff with it (and get fairly advanced even using the wonderful Google Web Toolkit and vaadin), even do some graphics with Canvas and the (not yet universal) WebGL, but unfortunately the Web experience still falls short of what is possible using an applet (video is designed for playing forward in HTML5, for my engineering purposes I needed forward and backward playback, single-frame stepping and exact frame seek - stuff that requires something like a Java applet to do). This forces me to use applets from time to time. Now requiring users to switch off applets because they have some holes seems to me as short sighted as switching off images (for example) or video because their video rendering libraries have holes discovered from time to time. We must demand that our browser plugins are made secure for sure, but basically throwing plugins out (the essence of your suggestion) is not the solution either. IMHO, the way forward is to hold plugin creators responsible for their product. That way effort would be directed to close the holes in those products. We would not only end up with a more functional web, but a safer one too.

> The advent of iOS went a long way towards killing these technologies, and the web is a safer place for their absence.
The killing of alternative tech helps Apple's agenda but doesn't help who is really important - me, the end user. Also, even a casual Google search would show you that despite the removal of Apple's competitor products iOS still has exploits. Doing a denial-of-service on yourself does reduce risk but certainly does not eliminate it. Therefore, removing functionality is not the solution - the solution is to make the product creators spend more effort on making the product secure (or if the effort is too great, ditch the product).

I hate finding bugs in my coffee

[puterguy]

Darn foreign coffee pickers and 3rd world working conditions...

Oh this is slashdot.... never mind. Yeah security holes in Java suck too

Java blows

[Anonymous Coward]

Why is anyone still running Java on the desktop? It's one of the biggest vectors of malware and exploits outside of Adobe's products. Leave it on the server with the COBOL code.

Re:Java blows

[SplashMyBandit]

Ummm, because it is the best cross-platform solution for rich clients out there. If there was something better I would use it, but there isn't (I'm writing a jet combat flight simulator and C++ and C# simply are too much effort to make truly cross-platform; eg. Mac, Linux, Window, Android). 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.

Re:Java blows

[Anonymous Coward]

use the Unity3d Engine. It ports to all major game platforms, AND doesn't have any glaring security vulns that go unpatched for months on end.

Re:Java blows

[Anonymous Coward]

Funny, I just attempted to play the battlestar galactica web MMO, and Unity3d is not supported on Linux..

Re:Java blows

[xclr8r]

http://www.cloudpath.net/solutions/solutions.php

A lot of their solutions work on Java.

Example: New kids to campus want to get their laptop on the university wireless system. All they have to do is have java and know their e-mail user name and password and this 3rd party solution takes the machines MAC address - registers it on the network and logs it in a back end database and automatically switches the student from the setupwireless to the WPA2 university wireless network. This saves a ton on help-desk logged hours/tickets and student lines.

Re:Java blows

[ThePhilips]

I'm writing a jet combat flight simulator and C++ and C# simply are too much effort to make truly cross-platform; eg. Mac, Linux, Window, Android

Care to elaborate on the specifics? Because it sounds a bit ... exaggerated. The difference between the platforms is in the UI and I do not think any sensible developer would subject its users to the horrors of AWT or Swing (none of which IIRC is available on Android). If you take the platform-specific UI out of the question, then the rest of the code would be pretty portable - regardless of the programming language. Except of course for the Android where IIRC you need different paradigm for an application, what would be a much bigger - yet programming-language-neutral - hurdle to overcome.

Re:Java blows

[exomondo]

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?

Re:Java blows

[John Bresnahan]

FlightGear is a multi-platform (Windows, OS/X, Linux) written in C++ and QT. Seems to work well enough for them.

Re:Java blows

[John Bresnahan]

FlightGear is a multi-platform (Windows, OS/X, Linux) flight simulator written in C++ and QT. Seems to work well enough for them.

Re:Java blows

[exomondo]

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.

Re:Java blows

[SplashMyBandit]

What would you like to know, specifically? Note that the 2D UI is a minor part of the application, and a "Filthy Rich Client" (Google if you don't understand this term) Swing startup is perfectly fine to start the JoGL/OpenGL main UI.

> Because it sounds a bit ... exaggerated.
This is why I am taking to point out that Java is more than adequate for 3D gaming (since all the important stuff runs on the GPU anyway). I find it lamentable that Slashdotters are so anti-Java (and have out of date perspectives) they simply cannot comprehend that modern JVMs are not only as good as C++ for gaming, they are superior in my experience as a indie game developer (for a hard-core simulation; eg. multi-threaded resource sharing in Java is so much easier than in C++ when you are targetting multiple-platforms). I understand that existing game devs with existing C++ pipelines and assets aren't interested in Java, but new games development should seriously consider it - expecially if you want to be as massively profitable as Java games like Minecraft are.

Re:Java blows

[SplashMyBandit]

Sorry, QT is vile and unnatural, IMHO. Effective sure, but unnatural for those used to proper Object Oriented UI toolkits (eg. back in the day Borland's OWL, Swing etc).

The C++ code itself is nothing. What matters is that for each platform you target you need different libraries, and each library has its own idiom. Then you end up contorting your architecture for each set of libraries you are trying to integrate. 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.

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 I understand your advocacy for C++. You can certainly accomplish useful stuff in it (and I have). However, I would never start a new forward-looking project in it. Java becomes the better choice for new heavily multi-threaded stuff, IMHO. (and yes, that includes rich clients, which can me made to look amazing using the "Filthy Rich Client" Swing techniques and OpenGL/JoGL).

Re:Java blows

[Anonymous Coward]

It is with Unity4 which is in beta right now.

Re:Java blows

[dudpixel]

Ummm, because it is the best cross-platform solution for rich clients out there. If there was something better I would use it, but there isn't (I'm writing a jet combat flight simulator and C++ and C# simply are too much effort to make truly cross-platform; eg. Mac, Linux, Window, Android). 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.

How about using the unity3d or corona sdk? Then you can add iPhone to the list of supported platforms as well.

Re:Java blows

[dudpixel]

What would you like to know, specifically? Note that the 2D UI is a minor part of the application, and a "Filthy Rich Client" (Google if you don't understand this term) Swing startup is perfectly fine to start the JoGL/OpenGL main UI.

> Because it sounds a bit ... exaggerated.

This is why I am taking to point out that Java is more than adequate for 3D gaming (since all the important stuff runs on the GPU anyway). I find it lamentable that Slashdotters are so anti-Java (and have out of date perspectives) they simply cannot comprehend that modern JVMs are not only as good as C++ for gaming, they are superior in my experience as a indie game developer (for a hard-core simulation; eg. multi-threaded resource sharing in Java is so much easier than in C++ when you are targetting multiple-platforms). I understand that existing game devs with existing C++ pipelines and assets aren't interested in Java, but new games development should seriously consider it - expecially if you want to be as massively profitable as Java games like Minecraft are.

What? No one was claiming that java was inadequate in any way. Your comment seems unwarranted and very defensive.

The GP merely stated that what you mentioned could be done in almost ANY language, and did not criticise your use of java specifically.

Your original claim was "because it is the best cross-platform solution for rich clients out there" and the GP answered that by saying that for what you want to do, there doesn't seem to be any clear or obvious reason to choose java over any other modern language. You can still choose to use it, but your claim that it is the "best" for this appears to have been overstated.

Re:Java blows

[SplashMyBandit]

I considered Unity3d but it wasn't suitable for my particular purposes - and I would still have to code in C++ (which after two decades of use I'm well sick of it).

Re:Java blows

[SplashMyBandit]

The parent posted this:
>"I do not think any sensible developer would subject its users to the horrors of AWT or Swing"
personally I disagree and find Swing to be one of the most powerful and productive rich client toolkits out there. If you know what you are doing you can do just about anything (although Swing has plenty of flaws still). It was based on that parent comment that I decided to "defensively" elaborate why I consider Java suitable - and IMHO, particularly suitable for massive multi-threading in a multi-platform application (yes, you can do the same in C++, but it is very much a hassle and the libraries change on each target platform; which was part of my point). Hence, I still see Java as the premier choice of platform for my project (which is what the parent of my original post disputed - he could see no use for client side Java; in fact I don't see any economic alternative; C/C++/C#/Python etc are not nearly as suitable for my purposes and intended development timescale).

Re:Java blows

[dudpixel]

You said you're doing a game. Most game engines or graphics engines contain UI classes as part of the SDK. Some even have UI designers to help build your UI.

I think Swing looks ugly, and doesn't blend in with the native OS (not exactly the spirit of cross-platform), and I suspect that is the common opinion too.

Still, feel free to use it. If it's your strongest toolkit (ie. the one you know best), then it's the best toolkit for you to use.

Re:Java blows

[exomondo]

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?

Re:Java blows

[Anonymous Coward]

I considered Unity3d but it wasn't suitable for my particular purposes

How come? It's more portable than Java for today's most common platforms.

Re:Java blows

[SplashMyBandit]

> I think Swing looks ugly, and doesn't blend in with the native OS
Many people I've made gaming utilities for rather like the Nimbus Look n' Feel (L&F). Perhaps your perception of Swing of the the rather ugly and outdated Metal L&F. I guess with most stuff moving to browser based apps its hard to find modern Swing apps, so it is easy to only think of Swing as the old apps you used to get.

> I think Swing looks ugly, and doesn't blend in with the native OS (not exactly the spirit of cross-platform), and I suspect that is the common opinion too.
That is a common but also rather out-of-date opinion. Most applications on Windows (for example) don't look like each other: MFC CTRL3D.DLL apps don't look like WinForms apps that don't look like browser apps that don't look like games (and their custom UIs) that don't look like MS Office not apps from the big providers (eg. HP printer driver control panel, or Adobe, or Symantec etc etc). In short, the lack of nativeness is a bit of a red herring. The problem with Swing apps was not really the Look, it was the Feel. Many developers made the mistake of blocking the Event Dispatch Thread (EDT) in Swing which made it feel like it was a slug and not responsive. When you don't do that (and make proper use of threading) then Swing apps generally are very performant and a delight to use (apart from a few quirks like not-quite-native looking file dialogs in the past; but those things have mostly been resolved now).

> Still, feel free to use it. If it's your strongest toolkit (ie. the one you know best), then it's the best toolkit for you to use.
Thanks :) It turns out that Swing has excellent integration with JoGL so that mixing 2D and 3D components is a complete breeze (and I don't have to write my own midget library to do the 2D stuff, so I get to overlay all the standard Swing controls even in my 3D views - which is vastly better than most of the crappy interfaces people seem to write when they try and mix DirectX/Direct3D with 2D controls). Given the vast number of controls needed in a combat flight simulator it is very useful to be able to pop up dialogs so the users can adjust their axis mappings and commands (eg. flight controls, radar slew, trim functions, countermeasure, sensor pod aiming etc) while still in-game.

Re:Java blows

[SplashMyBandit]

> So what specifically makes Java more reliable?
A combination of factors, like Java always ensuring everything is initialized, like the garbage collector ensuring that resources shared between multiple threads are eventually cleaned up, or not cleaned up too soon, and by setting references to null (aiding the gc) you can avoid the dangling pointers you get in C++ (which gets horrifically difficult in complex multi-threading programs in C++). The other thing is that Java has certain practices and tools that are not so common in the C++ code I encounter from other people. Yes, it is perfectly possible to do Test Driven Development in C++, but I hardly ever see it done - whereas it is pretty pervasive in the Java community and there are a vast number of tools and reporting engines for Java that help you utilize such techniques. My favourite tool of all is JVisualVM which is similar to gprof but you can instanteously attach to any running program/JVM without having to specially recompile your program.

> Java becomes the better choice for new heavily multi-threaded stuff, IMHO.
Why is that?
Thanks for asking. The real problem is when you have heap-allocated resources in a multi-threaded environment. Who owns the shared resource and who is responsible for releasing it, and when? For stuff that you write yourself this is not such a problem (I'd guess most Slashdotters are better than average devs, yeah?), but when you use libraries (especially older ones) then this becomes problematic very quickly (if they have different memory management strategies to yours, eg using wrappers C libraries in your C++). Again, all these problems can be solved when building large, complex C++ applications but when using Java I never have to devote nearly as much brainpower to worrying about these concerns. Instead, I get to devote my effort to the problem domain (which in my case is not simple form-to-database apps but is in fact quite complex physics [eg. simulating the optical transmission of the atmosphere in real time etc]).

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).

Re:Java blows

[exomondo]

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.

Re:Java blows

[SplashMyBandit]

Have you ever seen the Google Web Toolkit (GWT) or vaadin? These are both Java technologies (almost no one uses the 'browser plugin' Java applets for new projects).

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.

> 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.
It is possible to leak memory even using these in a long running application. If you have a statically allocated pointer then the memory can easily be held on to. With Java the VM actively looks at what can be released. This is a problem on uniprocessors but on today's hardware most cores that are often idle so letting the GC do work for you makes a lot of sense (it is analogous to the benefits that the C++ compiler and linker have over doing stuff in assembly; sure, you can build stuff in assembly but by choosing a higher level of abstraction you are free to concentrate on other concerns, like the 'problem domain').

Re:Java blows

[Anonymous Coward]

While I agree that most widgets would look out of place inside a game, I do take issue with your opinion that 'Swing is ugly'. Anyone who has ever actually used it should know that there is a setting to change the look of your application. All it takes is one line of code to change a string value to change from the default metal look which is the same on all platforms to the look of a native Windows or Mac application.

The reason you see all those 'ugly' java apps is because either the developer just wanted to scratch an itch and doesn't care about appearance (function>form), or he actually want it to look the same everywhere because it makes helping users easier. Ever thought of that?

Re:Java blows

[Anonymous Coward]

Except the only version that works on Linux is really buggy and is in beta precisely for that reason.

Re:Java blows

[ThePhilips]

"I do not think any sensible developer would subject its users to the horrors of AWT or Swing"

personally I disagree and find Swing to be one of the most powerful and productive rich client toolkits out there.

Being horrible and being powerful are two totally different orthogonal things. Being a Asm/C/C++/Perl guy, I did actually code with Java/Swing for several months. Oh, yeah it's very very powerful. But at the same time it is totally platform agnostic (making user of any OS feel out of place), it doesn't conform to behavioral standards of the OS it runs on, and lastly it is f***ing slow. Developing large interactive, stutter-free UI in Swing in the past (my past, something like 7 years ago) proved to be fruitless. (Eclipse UI toolkit is much much much better, but not portable.)

and the libraries change on each target platform

Now that is a good reason to pick Java.

I do it in C++ for ~5 platforms and yeah it can be PITA. C++'s Xerces alone cause about 30 person/days of problems per year. (But Xerces was self-inflicted pain: majority of developers wanted Xerces because it cool, while much more portable and robust libxml is too easy and thus not cool.) Orcale's C/C++ client is also pile of crap, causing constant portability grievances (e.g. Linux/x64 library exports public symbol "int count;" - and also about 40 symbols conflicting with the standard functions from libc; OK Oracle can be worked around nicely but most of our R&D don't even grasp in-depth what a dynamic-linked library is).

Sparing all the troubles by going with Java is a good technical reason.

Hence, I still see Java as the premier choice of platform for my project (which is what the parent of my original post disputed

I disputed not the choice of Java, but the reasons why Java is better.

As a C guy, I somehow managed to learn better than most Java guys the actual advantages of the Java. The "Java is the best!" and "OMG look at the $$$ Minecraft does", sorry, do not cut for technical reasons.

Though specifically for the games, I'm wondering about the Java choice - again for the interactivity reasons. We have a very fresh debacle where a Java application performance for no apparent reason degrades over time: after 6 hours of run-time, processing speed halves. Another older example is a latency-sensitive application which pretty often gets 1.5s latency spikes (== GC runs) what is about 30 times higher than allowed. (Googling for "Minecraft stutter" and "Minecraft lag" shows that the problem is not unique to our applications.)

Re:Java blows

[WankersRevenge]

I think Swing looks ugly, and doesn't blend in with the native OS (not exactly the spirit of cross-platform), and I suspect that is the common opinion too.

Native swing widgets looks horrific but you can theme them to make the widgets look and behave as if they were native ones. Just google mac widgets and you'll see what I mean.

Re:Java blows

[VGPowerlord]

It's literally a one-line block of code to make Swing use (what it thinks is) the native GUI look.

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

...and probably some exception handling. It's been a while since I've had to write Swing code in Java.

However, despite looking like native widgets, they really aren't and they behave differently in non-subtle ways (you mean my IME settings don't work in Swing?!). You need SWT for that.

Re:Java blows

[SplashMyBandit]

Thanks for taking the time to make interesting comments. With regard to your performance woes have you attached the JVisualVM to your running application? It comes as a standard part of the Sun/Oracle/OpenJDK. There you'll be able to see whether your performance issue is caused by: memory thrashing (when near the limit of the allocated heap), synchronization problems (threads locking/blocking each other), resource contention (eg. database row locks), or stuck in a loop somewhere. I'd be very interested to hear what your problem was once you discover it. I've tested by simulator and examined it under JVisualVM and the latency spikes from the GC are about 3% of one CPU core every 5 seconds (which is completely negligible for my purposes).

nb: I'm originally a C guy so understand very well what Java is doing for me. I love the simplicity of the C language and the design where the complexity is placed in the libraries rather than adding (or worse, overloading) more and more keywords. I like C++ too, but don't consider it superior to modern Java (C++ used to be better because of its speed, but in the last 5 years I think that has fallen away and thus I don't consider C++ better anymore).

With regard to XML processing. I used to have to use libraries like Xerces but now use JAXB, which is standard in Java. It's pretty hard to go back to manually wrangling XML once you have the ease of use of JAXB (a few annotations and you can serialize and deserialize any complex object graph). Of course, JAXB is not a one-size-fits-all solution, but for 90% of my XML needs it solves them very quickly. The reason I mention JAXB is that it neatly illustrates the design philosophy between (modern, new-style) Java and its C++ inheritance.

Well, Swing used to be slow when Java2D did software rendering. Quite a few things have changed in seven years. For starters the Nimbus theme is standard in Swing and is very nice to look at (looks as nice as the Mac widgets). Then, there is the fact that Java2D is now completely hardware accelerated through GPU shaders (OpenGL or DirectX, depending on the host platform) but not a single line of Java code needs to be changed to take advantage of this. As long as you don't block the Event Dispatch Thread in Swing (which bad programmers still do, even after all this time) your application is very, very responsive. So I don't disagree with your criticism of Swing, I just think it is quite outdated. If the disadvantages of Swing have fallen away and you are mostly only left with the advantages then I would suggest that many C++ developers ask themselves whether it is worth their time (or their employers money) that their next project should be started in C++. While I used to interleave C++ and Java projects (depending on the application) I find no compelling reasons to start with C++ anymore. So, all I'm trying to do is to counter out-of-date perceptions of Java and suggest to C++ folks that perhaps it is worth taking a second look at modern Java for just getting stuff done with less hassle than C++.

Re:Java blows

[exomondo]

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.

Re:Java blows

[SplashMyBandit]

Why the vitriol? Java is not perfect, I just happen to consider it better than its competitors for soe of the reasons I have outlined. Mind you, it suits me perfectly well to have commercial competitors using outdated tech like C++, since I get an easy development efficiency advantage for free. So, by all means, please continue using and advocating C++ rather than more modern solutions :)

Re:Java blows

[OdinOdin_]

QtJambi http://qt-jambi.org/ project exists and allows the best of both world. The Qt API for Java.

Re:Java blows

[SplashMyBandit]

Many thanks for the link Mighty Odin. I'll take a look.

Re:Java blows

[exomondo]

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.

Re:Java blows

[SplashMyBandit]

> I'm not using or advocating C++
So you don't use C++? well I do, as well as Java. It is laughable you think that I "clearly have no idea ..." when as a non-practitioner I suggest you have a look in the mirror ... and open your mind a little to the points others are trying to make (even if you find them made clumsily).

Re:Java blows

[exomondo]

So you don't use C++?

use != using, try to keep up.

It is laughable you think that I "clearly have no idea ..."

Then why are you so ignorant of things like memory leaks in Java? Why can you not specify all these C++ horrors you refer to ( 'awful porting nonsense' and 'dumb loopholes' and 'vile and unnatural' and need to re-architect because of unspecificed porting issues with libraries)? What is abundantly clear is that you have no idea what you're talking about, prove me wrong if you can, what libraries did you have to re-architect for? what porting nonsense? what dumb loopholes? what do mean by 'vile and unnatural'? If you do know what you're talking about you can tell me exactly but since you actually don't have any experience you can't specify what you meant by any of these things, they are just baseless.

Re:Java blows

[SplashMyBandit]

> use != using, try to keep up.
All I can go on is what you write. Since you are am ambiguous communicator (and it appears an arrogant prick to boot) that is not my problem. So no need for the attitude. k? If you want to make a point try and explain clearly and unambiguously, thanks.

> Vile and unnatural
Well, the fav C++ GUI toolkit around here seems to be QT. When I started playing with QT I was astounded by how horrible it was to use. Slots and macro madness abounded. Meta Object compilation - no thanks. Fortunately they have cleaned somewhat and it has become more OO like, say, Swing. But why settle for the imitation when I can have the real thing?

> "awful porting nonsense"
As in, moving C++ code between the same compiler. I remember using STL with g++ 2.7.2 back in the day (that version was stable for a long time) and then a patch-level release broke the tens of thousands of lines of code I'd been working on. Had to go and fix it all up. Just the other day I got some example code on atmospheric shading (the code wasn't important, it is nothing compared to the maths required). It didn't work right in Visual Studio and it didn't work right on Xcode. I then had to go and fix all the stuff up because each system puts its system headers in different places and the code required porting. Because C++ comes with fsck all as part of its standard library it means every platform has it own libraries (and way of doing things) that you have to fix up. Contrast that with Java. If you can see the JVM and your local lib/ then you are almost always good to go. My Java implementation of the optical atmospheric transmission just works when I *copy* (not recompile) it between Win7, Ubuntu and Mac OS X. I do know what I am doing (I was writing multi-platform C and C++ for nearly two decades using older versions of g++ and Turbo C++ - were you?).

> Then why are you so ignorant of things like memory leaks in Java?
Because I use JVisualVM and carefully examine the runtime execution of my code. I ensure that my products don't have resource leaks. Maybe I know what I'm doing.

> what dumb loopholes?
Every third-party C++ library you get that uses stcmp() instead of strncmp() or pointer-arithmetics their way into segfaulting. There are a lot of ways C++ developers can and do trip themselves - ways that Java was *designed* not to allow you to do (since the designers were heartily sick of all the fsckups with C++). Now, sure you can screw yourself over with Java, but usually I find the third party libraries to be of much better quality than the crap you get in the C++ world. And let's face it, modern software development is about re-using everything you can get your hands on.

> If you do know what you're talking about you can tell me exactly but since you actually don't have any experience you can't specify what you meant by any of these things, they are just baseless.
The only thing that is baseless is your assumption that I'm just another dumb Java guy who doesn't know diddly about C++. Like I said, I've been doing C and C++ for nearly two decades and have evolved past it. That's why I tire of folks like yourself that think because C++ is old and crufty it must be more l33t than modern alternatives. Here I would say, "I've been there, done that, and IMHO you are missing the point about software development". The point of software development is to develop *reliable* solutions with minimum time and effort/cost. C++ was good but is now behind the curve on this for most new development.

Re:Java blows

[exomondo]

Since you are am ambiguous communicator

I'm not the one making ambiguous comments with no explanation, that'd be you. All i've asked for is specificity in your comments, you make claims that you've worked with c++ for decades yet you can't provide any specific examples, one could do the exact same for Java and you'd simply arrive at an impasse.

Fortunately they have cleaned somewhat and it has become more OO like, say, Swing. But why settle for the imitation when I can have the real thing?

You specifically mentioned Android in your original post, are you running Swing on Android? If you don't like Qt that's fine, but that's not an objective criticism.

As in, moving C++ code between the same compiler. I remember using STL with g++ 2.7.2 back in the day (that version was stable for a long time) and then a patch-level release broke the tens of thousands of lines of code I'd been working on. Had to go and fix it all up.

What was that? In any case g++ is just one of many compilers, given its open source nature it is prone to issues just like that, just like the issues with going from Hotspot to Harmony in Java.

It didn't work right in Visual Studio and it didn't work right on Xcode. I then had to go and fix all the stuff up because each system puts its system headers in different places and the code required porting.

So you're complaining that platform-specific code that hasn't been ported is not cross-platform. It's not hard to write cross-platform code but if your code is platform-specific then you can hardly expect it to just compile on all platforms with no changes. Much like going from Hotspot to Harmony or JamVM.

Because C++ comes with fsck all as part of its standard library it means every platform has it own libraries (and way of doing things) that you have to fix up.

Which is why you use cross-platform libraries, if you use platform-specific libraries you're naturally going to have trouble porting, but again (for like the 8th time) what are these libraries you've had so much trouble with?

My Java implementation of the optical atmospheric transmission just works when I *copy* (not recompile) it between Win7, Ubuntu and Mac OS X.

Uh yeah, that's what you would expect given that it's not native code.

Because I use JVisualVM and carefully examine the runtime execution of my code. I ensure that my products don't have resource leaks. Maybe I know what I'm doing.

So then why do you have so much difficulty writing non-leaking code in c++?

Every third-party C++ library you get that uses stcmp() instead of strncmp() or pointer-arithmetics their way into segfaulting.

Like what? Why can't you specify which ones you've had problems with? If you're so experienced you should be able to specify them, this is what I asked for from the start. If you had problems and there were no alternatives then what were the problems?

The only thing that is baseless is your assumption that I'm just another dumb Java guy who doesn't know diddly about C++. Like I said, I've been doing C and C++ for nearly two decades and have evolved past it. That's why I tire of folks like yourself that think because C++ is old and crufty it must be more l33t than modern alternatives.

Get it through your thick head I'M NOT ADVOCATING C++ OR BASHING JAVA! You demonstrated your lack of expertise by ignoring the fact that memory leaks occur in Java, that is not a 'problem' with Java at all and I would never claim that it is, that is a problem with your understanding of Java. I don't even know you much less give a shit what programming language you use.

Re:Java blows

[SplashMyBandit]

> You specifically mentioned Android in your original post, are you running Swing on Android? If you don't like Qt that's fine, but that's not an objective criticism.
There is a small piece of code to load a different type of parent window on Android - detected using the normal Java mechanism. Once it hands over to the JoGL code then there is nothing really to do, since JoGL supports Android the same as any other platform.

> So then why do you have so much difficulty writing non-leaking code in c++?
Because once you are massively multi-threaded then resource management requires a colossal amount of effort to get right. Everything is non-deterministic. You then have the potential that you will not allocate large chunks of memory *in a timely manner*. Then once you factor in third-party C and C++ libraries that may have different resource allocation strategies to yours you end up with a decent probability of leaks. In the end you spend so much effort trying to do memory management in C++ you are basically writing your own memory management system/garbage collector - at least, for the large, complex real-time systems I've worked on.

> I don't even know you much less give a shit what programming language you use.
Actually, what I'm trying to discern is you reason for arguing. Is your argument that it is perfectly possible to write massively multi-threaded, cross-platform real-time applications in C++ in a manner that is easier than doing it in Java? otherwise I don't really get your point at all. It is always a lot more effort and risky to write such programs in C++ relative to Java (which was my point) - apparently do disagree, yeah? In that case, may I ask whether you have ever written such a large massively multi-threaded, cross-platform real-time application? if so then was it easy with C++ and were you very bug-free? because I am writing such an application and my *experience* has lead me to make the statements I do, it is not theoretical (although I will admit, my latest project is not written in C++, since it simply is not a contender for such an application once you factor in developer effort/cost). So, if you can be bothered to outline your experience in solving this problem then I'll bother to give a list of libraries that I've found shitty to work with when doing cross-platform stuff. Deal?

Re:Java blows

[exomondo]

There is a small piece of code to load a different type of parent window on Android - detected using the normal Java mechanism. Once it hands over to the JoGL code then there is nothing really to do, since JoGL supports Android the same as any other platform.

And if you extensively use Swing or AWT you have to port all of that to Android's XML-based UI.

Actually, what I'm trying to discern is you reason for arguing. Is your argument that it is perfectly possible to write massively multi-threaded, cross-platform real-time applications in C++ in a manner that is easier than doing it in Java?

No - and in fact if you recall you said cross-platform solution for rich clients - i'm not arguing at all, again i'm not advocating one way or the other, try to comprehend that, I'm just trying to work out what your justification is. With your 'decades' of experience you can't even come up with any specific examples to back up your comments. With all these problems with all different platform-specific libraries i would think it would be pretty easy to have dropped an example, but throughout the course of this entire thread you've staunchly resisted being at all specific.

It is always a lot more effort and risky to write such programs in C++ relative to Java (which was my point) - apparently do disagree, yeah?

No, it does depend on your proficiency in those languages though, and no that wasn't your point, you quite categorically said cross-platform solution for rich clients.

because I am writing such an application and my *experience* has lead me to make the statements I do

Which is precisely why i would have thought if that were true you would have had no problem backing up your statements with specific facts sometime in the last 8 or so times i asked but you continue to post that you have all this experience but nothing specific. Except to say that you go to the trouble of using JVisualVM to examine your running code Java for memory leaks - which makes sense in most applications but certainly not in a non-deterministic highly parallel application.

In that case, may I ask whether you have ever written such a large massively multi-threaded, cross-platform real-time application? if so then was it easy with C++ and were you very bug-free?

I use a lot of GPGPU for offloading massively parallel tasks, the language that drives it doesn't really matter so long as it has bindings for the GPGPU library (in my case mostly CUDA).

So, if you can be bothered to outline your experience in solving this problem then I'll bother to give a list of libraries that I've found shitty to work with when doing cross-platform stuff. Deal?

I'm not trying to sway you one way or the other or advocate for either way, i even said i'm not currently using C++ so i don't see how it's so hard for you to understand i am looking at this in an objective way and only asking for clarification of your statements. I can see you're pushing Java pretty hard but i don't really have any preference for anything, i'll use whatever tool is best suited for the job. I'm trying to ascertain what the experience was that led you to make the statements regarding c++ and as far as you have told me there isn't really any.

Re:Java blows

[SplashMyBandit]

> Except to say that you go to the trouble of using JVisualVM to examine your running code Java for memory leaks - which makes sense in most applications but certainly not in a non-deterministic highly parallel application.
Ok, this is bullshit right here. With a highly non-deterministic application the first approach is to look at the statistical overall expectation behaviour of the application, for which this tool is awesomely suited.

> I use a lot of GPGPU for offloading massively parallel tasks, the language that drives it doesn't really matter so long as it has bindings for the GPGPU library (in my case mostly CUDA).
Ah, I get it now. Based (solely) on this your problem domain is massively parallizable. That is *not the same* as the massively multi-threaded program that I was talking about where you have different resources with different hard and soft real time requirements (and usually low-latency is what you are aiming for). I am surprised you didn't see the difference.

Ok, for the CUDA-esque problems what one tries to achieve is not usually not complex (in relative terms) it just has to have be speed up to fit within useful timeframes. I feel I understand this problem as I did planetary gravitational microlensing simulations that would have been awesome to use CUDA on, if it had existed at the time.

Ok, now for some libraries I'm not so fond of. Well, I find that even something as core as STL is quirky between implementations. I found I needed to spend a lot of effort #ifdefing to handle the differences when using different compilers (or versions of the compiler) - this is quite a fail to me (yes there are differences between JDK implementations and versions too [grrr the stupid breaking change in java.sql.DataSource in v7], but they are fair more avoidable and less effort to resolve IMHO). Then there are the unicode problems with all C++ libraries. Depending where the program was running was you could never tell whether your wchar_t would be able to accept asian character sets or not (since wchar_t was often shitty old UCS-2 rather than a proper unicode format; and if you are developing software for China you must meet GB18030 to meet government standards). For multi-threading pthreads was ok, but managing shared collections was a lot of work (unlike Doug Lea's genius poured into java.util.concurrent). Then there is OpenGL context creation that is a PITA to set up for each platform. Sure, there's GLUT etc for toy programs, but it is not well suited for programs where mostly you want a higher level of abstraction and integration with your UI toolkit but then occasionally want to get down to the nuts and bolts.

Ok, now I wanna do device I/O, hmm let's see, I get to use DirectInput or libusb and keep tabs on who is releasing resources when (and don't fsck it up or you'll be in a world of pain - your program will run for another five minutes before it crashes [hopefully not crashing the system due to bugs in the graphics driver; curse AMD's trouty bodies], then you get a core that you have to go through to work out where the problem was, which is not necessarily the same place the pointer violation occurred due to the unprotected memory). Oh, and once you have your program running and ported you have end users running it and find it won't run and you have to debug remotely but the standard library gives you no convenient stack trace of the calls made, and you can't just plug in to their running system and watch what their system is doing (hence my unseemly love for JVisualVM; strace is good but I don't always get shell access to use it on a client system). Then I really miss annotation-based libraries like JAXB and JPA2/Hibernate, I've not seen C++ libraries that are anywhere near as convenient. Also RTTI was not nearly as good as Reflection once I got used to the latter.

So, the more and more varied application domains led me to conclude that C++ is not the best choice for modern apps doing a lot of stuff outside C++'s limited standard library. The more com

Jokes on them

[Anonymous Coward]

I don't have Java installed on my Mac in the first place!

At work, our IT department runs about 400 machines. Not one has Java installed.

Story is misleading.

[Anonymous Coward]

Except that Apple have never even installed Java 7 to be vulnerable.. this is update to their Java 6, so the story is bogus.

It's oracles job to handle Java 7 on mac, Apple are only dealing upto 6.

Re:Story is misleading.

[Anonymous Coward]

Except that Apple have never even installed Java 7 to be vulnerable.. this is update to their Java 6, so the story is bogus.

It's oracles job to handle Java 7 on mac, Apple are only dealing upto 6.

Those vulnerabilities exist in Java 6 as well, and if what you're saying is true then why are they fixing this this vulnerability in the bugfix?

Disables Java by default

[Anonymous Coward]

Seems like a good start to the fix to me.

Mega vulnerability is for Java v7 - Apples is v6

[sasparillascott]

While the Apple update doesn't fix the v7 vulnerability, it shouldn't as the Apple Java is v6 which supposedly doesn't have it (or some part of it). So this seems to make sense. To get v7 on a Mac you have to go out of your way and download v7 from Oracle separately.

Re:Mega vulnerability is for Java v7 - Apples is v

[Anonymous Coward]

Well you have to go out of your way to get Java 6, too, since Apple shitcanned Java a while back.

Garbage story

[Anonymous Coward]

Apple doesn't ship Java installed by default... but if you do install it, it's Java 6. The "unpatched" vulnerability in the summary only affects new Java 7 functionality and does not affect Java 6.

My understanding...

[Yaztromo]

...is that CVE-2012-4681 uses a vulnerability during Applet execution.

Apple's Java for OS X 2012-005 disables all browser Applet support, and if re-enabled by the user, will automatically disable it again if it goes unused for 35 days. The Java for Mac OS X 10.6 Update 10 release appears to go a step further, and disables applets in browsers until they are clicked on explicitly by users, along with disabling the applet plug-in if unused for 35 days.

So while I'm presuming the vulnerability does still exist in the Java classes themselves, Apple certainly has lessened the overall attack surface. You can't take advantage of the vulnerability if you can't run any applets. This negates the possibility of drive-by attacks for the majority of users (although it doesn't lessen the possibility of socially engineered attacks -- I'm willing to bet that if you provide directions on how to re-enable the plug-in and ask users to do so and reload the page to see a dancing monkey, some percentage of users are going to be dumb enough to follow them and have their systems violated).

FWIW, AFAIK Apple doesn't fix bugs in the Java classes themselves. They have to get upstream fixes for these from Oracle.

Yaz

Re:My understanding...

[fm6]

You can't take advantage of the vulnerability if you can't run any applets

Not true.

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html

Re:My understanding...

[_xeno_]

...is that CVE-2012-4681 uses a vulnerability during Applet execution.

Not quite. Applets are the most likely infection vector, but the vulnerability exists in any Java code.

Basically, what CVE-2012-4681 does is let untrusted Java code turn off the Java sandbox. Applets are about the only Java code where the sandbox is likely to be enabled by default, but there are scenarios where the sandbox is used by non-applet code. (As an example, in a Java servlet environment (think Java CGI), the individual pages might be run in the Java sandbox.)

Which means that, for the most part, this only effects applets, since most Java code isn't run in the Java sandbox anyway. But it's conceptually possible that it opens security holes in other Java-based code, if that code happens to run within the Java sandbox.

Re:My understanding...

[VGPowerlord]

As an example, in a Java servlet environment (think Java CGI), the individual pages might be run in the Java sandbox.

Java servlets are running on the server side, which makes this a moot point. The client side isn't running any Java code for a servlet and the client's JVM (if present) is never invoked.

Unless, or course, the page hosts an applet, but you already discussed applets.

Re:My understanding...

[_xeno_]

Java servlets are running on the server side, which makes this a moot point.

Not if it's your server. For example, say you're a hosting provider, and offer hosting of Java servlets. Tomcat provides an option to enable the Java sandbox for embedded servlets, and the vulnerability being discussed would allow them to bypass it. If the servlets are being provided by potentially hostile sources, that's a problem.

I can't really think of any other scenarios where the Java sandbox is enabled (other than Java Web Start, I suppose, which are basically "applets" by another name). The point remains that the vulnerability effects any code that uses the Java sandbox to securely run potentially hostile code.

Stop Trolling us Slashdot

[Anonymous Coward]

Hey Editors, you've been trolled. The "mega-vulerabilites" described in CVE-2012-4681 don't even apply to the version of Java Apple ships. Do some homework before jumping on the bandwagon next time.

Re:Stop Trolling us Slashdot

[Anonymous Coward]

some appletard just felt raped

Re:Stop Trolling us Slashdot

[Anonymous Coward]

Can't rape the willing.

Re:Stop Trolling us Slashdot

[Jesus_666]

Oh come on, you apologist. Stop splitting hairs.

Apple missed a lot of serious issues with this Java patch. The JRE7 security flaw. iOS text message spoofing. The Pentium FDIV bug. The Prius stuck accelerator problem. PHP's inherent design flaws. Unity.

I salute the efforts of Mr. What'shisname to warn us of Apple's disastrous negligience. Now if you'll excuse me, I'm off to demonstrate against the Vatican for not having achieved break-even with fusion power yet.

Java? Apple?

[Anonymous Coward]

The Apple people don't want anybody to cross to their platform. So they made Java experience on their products as unpleasant as they can. It's their strategy. People buying any iCrap for anything related to Java are simply ignorant. Get over it, people!

Of course they didn't fix CVE-2012-4681!

[WD]

CVE-2012-4681 is a vulnerability that affects Java 7. Apple has only ever provided Java 6 with OS X, and with recent OS X versions, it's not even included by default. So it's pretty silly to make a sensational story that calls out Apple for not addressing CVE-2012-4681 in their update to Java, since they're not even affected by it.

For more details, see: http://www.kb.cert.org/vuls/id/636312

OS X uses Java SE 6 not Java SE 7

[DeadboltX]

The bug described in CVE-2012-4681 affects Java SE 7. OS X uses Java SE 6. It would be a little weird if they patched Java SE 6 for a bug that doesn't exist in Java SE 6.

Re:OS X uses Java SE 6 not Java SE 7

[viperidaenz]

http://www.oracle.com/technetwork/topics/security/alert-cve-2012-4681-1835715.html It effects Java 6 u34 and below but the impact is not as severe. I believe malicious code can still change the value of private fields but the Java 6 version of the sandbox is implemented differently, so the list of permissions can't be replaced with "AllPermissions"

Re:OS X uses Java SE 6 not Java SE 7

[Anonymous Coward]

http://www.oracle.com/technetwork/topics/security/alert-cve-2012-4681-1835715.html It effects Java 6 u34 and below but the impact is not as severe. I believe malicious code can still change the value of private fields but the Java 6 version of the sandbox is implemented differently, so the list of permissions can't be replaced with "AllPermissions"

This has been called out repeatedly, also in previous stories on this, but the debunked claim about Mac not being affected still gets repeated so frequently it almost seems like a GOP talking point.

Re:OS X uses Java SE 6 not Java SE 7

[Plumpaquatsch]

http://www.oracle.com/technetwork/topics/security/alert-cve-2012-4681-1835715.html It effects Java 6 u34 and below but the impact is not as severe. I believe malicious code can still change the value of private fields but the Java 6 version of the sandbox is implemented differently, so the list of permissions can't be replaced with "AllPermissions"

According to the risk matrix at the bottom of the page, the problem of vulnerability under Java 6 u34 and below is identified as CVE-2012-0547 - which is exactly what Apple's fix fixes as said in TFS. IOW TFA is still uninformed at best.

Apple bashing at its finest

[Anonymous Coward]

The exploitable com.sun.beans.finder.MethodFinder and com.sun.beans.finder.ClassFinder classes in CVE-2012-4681 are available only since JDK 7. JDK 7 is an Oracle only affair.

Nothing to see here.

Congratulations hypnosec!

[Anonymous Coward]

For the dumbest submission to Slashdot ever. Reading comprehension #fail.

You must be new here

[ArchieBunker]

The janitors running this site can't even be bothered to read submissions over for spelling and grammar mistakes.

ummmm

[Anonymous Coward]

your not very bright are ya THE new version doesn't fix the issue that 6 had...thus it still affects mac dummies....gee now i see why mac people are seen as utter dummies , go back to making some pretty pictures already.....

Re:ummmm

[Anonymous Coward]

You're the one that's not very bright. Read the link he posted. It states that downgrading to Java 6 will avoid the vulnerability.

Who cares, Java is dead.

[funky_vibes]

Why would anyone want to use Java anyway?
It was all promises, and now we know they were lies.
There are better alternatives like perl, python and ruby.

Re:Who cares, Java is dead.

[gtall]

Errr...because some of us don't have a choice, Einstein?

Re:Who cares, Java is dead.

[Gaygirlie]

Why would anyone want to use Java anyway?

The more important question is why would anyone want to use a Mac anyway? ;)

Re:Who cares, Java is dead.

[Anonymous Coward]

Errr...because some of us DO have a choice, Einstein?

Re:Who cares, Java is dead.

[funky_vibes]

I'd pick Einstein over Java any day.

Re:Who cares, Java is dead.

[funky_vibes]

Yeah, ever since the apple logo lost the rainbow colours, they've become totally un-gay :(

Re:Mega vulnerability is for Java v7 - Apples is v

[Anonymous Coward]

To get v7 on a Mac you have to go out of your way and download v7 from Oracle separately.

Yeah, I can see how downloading java from java.com is really going out of your way for a Mac user ;)

Systematic Java Deficiencies

[Anonymous Coward]

In many settings efficient use of memory, short runtime and (soft) realtime capabilities *do indeed matter*. Just take the case of a rich GUI or a game: if the user workflow is interrupted by the GC randomly kicking in, the user will be rightfully annoyed. So, for best GUI user experience you need a GC-free system.

There are many other fields of application, where realtime capabilities matter - signal processing, robotics, factory automation, autonomous vehicles and much more. You can only do that with Java if you refrain from using new after an the "boot" phase. And of course, never call anything which directly or indirectly calls new. That excludes about 99% of the standard library.

Finally, Java's memory model is "my way or the highway": you cannot allocate string buffers on the stack, you cannot have value arrays for complex types, you cannot aggregate value objects. Instead, you are forced to use lots of pointers and lots of new operations.

You cannot have reference-counted memory management, also called Smart Pointers. The latter would be highly beneficial for things like Strings.

You cannot nicely return/release resources by means of destructors. So every exit point from a block must carefully and explicitly deallocate resources. If you throw exceptions, resource leaks will happen if you don't enclose everything in a nasty try/catch/finally expression.

Here is a language, which proves you don't need a VM do get almost all of C++'s and Java's benefits combined:

http://sourceforge.net/projects/sappeurcompiler/

Re:Systematic Java Deficiencies

[OdinOdin_]

The project you cites have zero downloads (this week). Come back when you've fixed all the bugs and the rest of the world is onboard.

Until then I'll keep using Java as I don't seem to run into the same difficulties you seem to have.

I'm sure realtime does matter but I can stil code in C/C++ for that and the resulting work can still run inside the Java VM in complete harmony. I'm sure you will find it hard to find people suggesting you write your video codecs in Java.

For the bigger picture where a collective project can consist of over 1000 modules with over 200 teams all able to collaborate, inspect, review/debug and see-inside each others modules and then on release day have it deploy and be operational in a high degree of certantity on wide variety of hardware, runtime implementation nothing can hold a candle to it.

Regarding "Cross-Platform"

[Anonymous Coward]

The argument that Java is required for cross-platform support does not hold water either. Nowadays there is an array of cross-platform toolkits such as Qt, wxWidgets, fltk, gtk which do provide nice cross-platform GUI functionality.

Developers just have to plug wax into their ears and ignore the siren songs of Redmond and Cupertino. Don't use the registry and other Windows- or Apple-specific API calls. With Boots, and the mentioned libs there is virtually no need for platform-specific code any more. Even if you want to launch threads, open sockets and files and so on. If an application still needs to do something platform-specific, isolate that in a wrapper class, which will be implemented differently for each platform, but will have an identical external API and semantics.

Also, the open source community provides a rich repository of complex libraries for document formatting/printing (e.g. latex),xml parsing, PDF viewing, html rendering, data storage, data encoding (e.g. Google protocol buffers). Do some Googleing before you decide to use some proprietary printing, persistence or html rendering system. Many successful shrink-wrapped software products do this for years now.

 

! Kerbs, Krebs

[Anonymous Coward]

As long as you are making corrections it's 'Krebs on Security' not Kerbs, and certainly not KerbOnSecurity.

Re:Mega vulnerability is for Java v7 - Apples is v

[Anonymous Coward]

You mean click "Yes" to the dialog that pops up when anything ever tries to invoke a JVM?

Yeah, really fucking out of the way.

They did Snow Leopard as well

[bogie]

Finally they did Snow Leopard as well! You know, that OS that most Mac users are currently using?

They still haven't released Safari 6 for Snow Leopard or released Safari 5.1.8 etc to address the 121 fixes that Safari 6 brought to Lion. That's a huge problem. I'm very happy they fixed Java but why did they bother when Safari 5 is loaded with so many other flaws they won't bother fixing?