User revolt over Java bloatware
news.techeye.net
news.techeye.net
[1] http://www.youtube.com/watch?feature=player_embedded&v=-...
Hilarious! That dude is the worst of the worst, and should be on the wall of any Oracle using companies engineers as a reminder of why you want to put in the extra hours to implement Postgres to deny that asswipe his next megayacht.
EDIT: Wow. Didn't realize I felt that strongly until I wrote this. But client-side Java, which I spent many years programming, is a tragedy of epic proportions, and my anger hides a real sadness.
client-side Java != browser jvm In fact, all of your client-side Java code will run perfectly well without a browser on your Mac, Windows & Linux boxes. I still do a lot of client-side Scala, running on Mac & linux, with no browsers involved at all. The simplest way for a data scientist to process say ~10 GB of records & display linegraphs & scatterplots is like 20 lines of straight client-side Scala, no browser, no html, no CSS3, no JS, no canvas. Throw it in a generalpath & apply an affine transform & you have your curve.(http://bit.ly/WWoaKS). Almost all my work these days is client-side Scala, and I've never used a browser.
In the time it takes to learn GridBagLayout you could have finished your whole project, and the web version is going to be far easier to modify, and your architecture is almost certainly going to make the data easier to access.
When it comes to analyzing big data, I'd do the majority of the crunching server-side, and only pass viz data out to the client (which is always going to be orders-of-magnitude smaller than the source data).
Unfortunately, I think we're still a decade or so away from having technologically enlightened people saturated throughout our corporate landscape for that to happen.
Until then, we're stuck with know-nothing managers who make decisions based on how likely they are to get fired if things go wrong:
http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
("nobody ever got fired for buying IBM equipment")
6000 people? The more appropriate subject here would be "Most users don't care about Java bloatware".
Devlopers would have their own machines or VMs plus install and control the update cycle, often manually, by downloading the JDKs directly (which have no bloatware).
Applets and other front-facing Java services are also almost never used on the web due to the dominance of Flash, Javascript and other technologies.
In short, there are no common non-development desktop applications or task profiles that require Java.
Minecraft.
[1] http://www.oracle.com/technetwork/java/javase/downloads/inde...
Well, since Oracle is doing it and accepting the pubic outcry, it must be that they have no image to tarnish. Also, we don't know how much ask.com is paying for this deal, but given that the Java downloads are free, any payment deal with ask.com represents an infinite increase in profitability.
> It's not like they are so desperate for money they are grasping at straws, are they?
I see you haven't talked to any stockholders lately. Most only care about profits and don't ask where they come from.
That would make sense if Oracle was a company whose only business were providing Java downloads. However I heard they also have some other source of income, and I suspect compared to those whatever ask.com is paying is rather minuscule.
A modern corporation consists of individual departments, each of which must strive to justify its existence as though it were a separate entity. No rational corporate manager is willing to say, "We don't have to turn a profit -- we're an insignificant, small part of a hugely profitable corporation."
The fact that the second claim is true cannot be used to justify the first claim.
Some Java bashers should show a little more empathy towards the independent Java developers that are suffering the consequences of Oracle's decisions.
Thankfully with my needs I'm really not missing much.
Java having integrity. Good joke.
Publicly traded corporations are all the same; they're all equally obnoxious, a-moral, and hostile to customers when it suits their perceived interests. Oracle's Java adware is just a tiny little symptom of this; the actual problem is systemic to public corporations.
This kind of obnoxious user-hostility is what made me abandon closed source software for personal use. Additionally, my company (a private company) doesn't use any closed-source software in our systems, and never will. For us, open source software is better, more flexible, more supportable, and the nail in the coffin is that there simply aren't any vendors that can be trusted by a small organisation such as us.
Oracle don't care about little people signing a petition anyway. If one of their large corporate customers told them directly that this was unacceptable, they would stop it in a minute.
We could be seeing a second life for Java rather than this disgusting shuffle of the undead.
Off the top of my head:
IntelliJ's @Nullable annotation as a core part of the language (I would suggest spelling "Nullable" as "*" to avoid freaking out the C++ converts) would greatly improve static type safety. Let's stop re-inventing Tony Hoare's Billion Dollar Mistake.
Call me a heretic, but for most real-world uses (particularly financial calculations) IEEE 754-r decimal floating point is a better default than IEEE 754 binary floating point, plus it's less confusing for inexperienced programmers. Excel does some ugly ugly tricks to try and hide IEEE 754 binary artifacts from display, but the artifacts still show up from time to time. Even experienced programmers often mistake binary floating point artifacts for software bugs.
UTF-16 also fools many programmers into thinking it's a fixed-width representation, and Java's APIs force Strings to at least pretend that they're using UTF-16 internally. Chars should be 32-bit, since 16 bits aren't enough to represent all Unicode codepoints. Iterator-like String APIs are often more appropriate than Java's array-like String APIs, and give implementors more design flexibility.
These days, even a lot of embedded systems are beefy enough that a register-based or SSA-based bytecode is a better choice. (For small embedded systems, I'm sure a few companies would spring up with cut down standard libraries and tools to either generate native code or a stack machine representation from the standard bytecode.) Bytecodes manipulating NaN-tagged types would make the VM a better target for dynamically typed languages.
We know that CSP/Actors are a less bug prone concurrency abstraction than forcing developers to work directly with threads, but Java chose threads to make C++ programmers feel comfortable.
The use of type erasure in Java's generics was a compromise necessary to maintain compatibility with old class files. Safety and performance would be improved by starting out with a system that supports generics.
This would be a lot better, but even this is oversimplifying things and is going to cause problems. In this case, thinking "chars are 32 bits" ignores the fact that, in Unicode, a "char" (that is, a codepoint) and a single character you see on the screen (that is, a glyph) are not the same thing: Some codepoints don't map to glyphs, such as bidirectional markers, [1] and some codepoints modify existing glyphs, such as combining forms. [2] And Zalgo waits for people who forget about combining forms. [3] Zalgo hungers, mortal. [4]
The underlying 'problem' is that Unicode is the first text processing standard that's actually complex enough to be useful for more than one language. Its complexity reflects how complex the real world is.
[1] http://www.iamcal.com/understanding-bidirectional-text/
[2] http://en.wikipedia.org/wiki/Combining_character
"a respected corporation such as Oracle"
Give me a break.