Slashdot Mirror
Mozilla Blocks Vulnerable Java Versions In Firefox
Trailrunner7 writes with this excerpt from Threatpost: "Mozilla has made a change in Firefox that will block all of the older versions of Java that contain a critical vulnerability that's being actively exploited. The decision to add these vulnerable versions of Java to the browser's blocklist is designed to protect users who may not be aware of the flaw and attacks. 'This vulnerability — present in the older versions of the JDK and JRE — is actively being exploited, and is a potential risk to users. To mitigate this risk, we have added affected versions of the Java plugin for Windows (Version 6 Update 30 and below as well as Version 7 Update 2 and below) to Firefox's blocklist. A blocklist entry for the Java plugin on OS X may be added at a future date. Mozilla strongly encourages anyone who requires the JDK and JRE to update to the current version as soon as possible on all platforms,' Mozilla's Kev Needham said."
https://wiki.mozilla.org/Extension_Blocklisting:User_Interface
Preferences for controlling the blocklist
The common user should not be allowed to override the automatic updating and application of the blocklist, but there are valid use cases for doing so.
The following preferences should be created to govern this behaviour:
* extensions.blocklist.enable (boolean), toggles blocklist enabled on/off
Other applications or distributions may want to provide their own backlist update url which will be controlled by the following pref:
* extensions.blocklist.url (string), url to the blocklist file
The interval in which the blocklist runs will be defined by the following pref:
* extensions.blocklist.interval (integer), the interval in which to download a new blocklist file
These preferences should be documented on developer.mozilla.org and any announcements for developers about the blocklist functionality.
From the article:
Affected versions of the Java plugin will be disabled unless a user makes an explicit choice to keep it enabled at the time they are notified of the block being applied.
The block isn't compulsory. Undo the block and keep working in the mean time.
The built in UI widgets and windowing (Swing) is weak at best. While it has many of the basic widget types, it hasn't really evolved much as time has moved forward.
Hasn't evolved, compared to what? Its big competitor for the rich-client is .NET, which is basically just a wrapper over same old Win32 controls we were using with MFC in the 90's. I can do anything with Swing.
Java applets, I feel, have been dead for a long time. Applet initialization time was just too long or would break during loading to discourage people from using it. Though, I've seen Java Web Start work pretty well for deploying Java applications.
The worst thing to ever happen to Java was Netscape 3.x and the Hotspot VM. Everybody remembers the "Starting Java..." message on the task bar - for several minutes - and then the inevitable browser crash. That sealed Java's fate on the client.
:wq
Slashdot hates Java because they hate anything that isn't Pure GNU open source.
No, there are a lot of legitimate reasons to hate Java, mainly because it promised things it couldn't deliver. It promised to be portable, but running it on anything that isn't one of under half a dozen blessed platforms is painful. That new MIPS server? Sorry, no Java for you! For a long time, even Java on *BSD on x86 was painful due to onerous licensing requirements (binaries weren't redistributable, so you needed to download the source - manually so you could agree to the license agreement - download the Linux version, use the Linux version to compile the BSD version).
Then there's performance. Java performance is on a par with StrongTalk or Self, yet it's a much lower-level language. Performance is usually okay, but again Java promised C-like performance and then shows misleading benchmarks to demonstrate it.
Next there's the pain of interfacing Java with other languages. If I have a C library, I can trivially call it from most scripting languages, from Objective-C, from C++, from D, from Pascal, from Lisp, and so on. If I have a Java library, it's difficult to use it from anything that's not Java. Conversely, it's difficult to use existing libraries from Java - JNI is a whole world of pain. This means that Java often involves reinventing the wheel, while other languages just provide thin (and often automatically generated) wrappers around libraries written in other languages where appropriate.
Then there's the incompatibilities between versions. Once you've got your write-once-run-anywhere program working on your customer's machine, he installs a new version of the JRE and it stops working. Meanwhile, the statically compiled, statically linked, program in another language works just fine...
And then there's the library system. Some rookie mistakes, like making String final. More importantly there's the design patterns fetishism that's so prevalent. There's a reason for all of those JavaProgramFactoryFactoryFactory jokes...
I am TheRaven on Soylent News
Oh, and I forgot to mention the UI problem. Java UIs look and feel wrong on every platform, although they look and feel least wrong on Windows. Java promoted the idea that you should use the same UI on every platform (ignoring the fact that different user interface guidelines are one of the main differences between platforms, from a user's perspective). They intentionally made it difficult to use the target platform's user interface APIs with Java code (although Apple fixed that on OS X in 10.0, before deprecating it around 10.4) to push the idea that you'd run the same code everywhere. Good cross-platform GUI apps are MVC, using native views and slightly different controllers on each platform, but the same model code. Doing this in Java is much harder than it should be.
I am TheRaven on Soylent News
So Microsoft invented a new language to "be LIKE Java" but not Java.
This was relevant 10 years ago when C# first appeared. Since then, it has evolved at a pace much faster than Java, and has many more useful features. Case in point: C# has had full-featured closures for 7 years now; Java is only getting them in the upcoming release.