×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Oracle Promises Patches Next Week For 36 Exploits In Latest Java

timothy posted about 3 months ago | from the they-call-this-progress dept.

Java 154

An anonymous reader writes "Oracle is posting patches for all its products next Tuesday, which include 36 exploits for Java alone and over 140 for all Oracle products currently supported, included over 80 that require no authentication to execute.These patches look to be critical for any administrator. Java 6 users who use equipment or programs that rely on older versions are SOL unless they sign up for a very expensive support contract, as these patches are for Java 7 only."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

154 comments

again? (-1, Flamebait)

Anonymous Coward | about 3 months ago | (#45925195)

Java, one of the worst things to happen to computing, ever.

Re:again? (1)

Selur (2745445) | about 3 months ago | (#45925235)

it's only bad if you believe in secure computing and thought java was secure to begin with ;)

Re:again? (3, Insightful)

Urkki (668283) | about 3 months ago | (#45925281)

Java, one of the worst things to happen to computing, ever.

Nah, I doubt anything would be much better, if they were in position Java is now. If it were native code, anybody without the sources would be screwed, now only anybody with Java6 requirement and no sources to fix it is screwed (but they were the moment their software got tied to specific JRE6 version). If it were .net instead of Java, when do you think MS would get around to patching Linux versions? If it were some scripting language... ok, it couldn't be: duck typing is too fragile, performance is problem, no serious contenders for many (not most, but many) Java use cases.

In absence of Java, maybe something really better would exist now, but I very much doubt it. It's a paradoxical package deal.
 

Why doubt something better would exist? (3, Insightful)

Anonymous Coward | about 3 months ago | (#45925387)

Sun was very much responding to a need when they started developing Java all those years ago. Other groups largely left them to it as Sun was a company with an excellent reputation. Things would have been just fine but for one most unfortunate event.

Oracle bought Java.

We suddenly switch from famous to infamous. As far as I'm concerned, Java died on that day, and I've been far more interested in freer languages since then. I feel for those that continue to endure Java due to corporate inflexibility.

Re:Why doubt something better would exist? (5, Insightful)

Urkki (668283) | about 3 months ago | (#45925449)

What is telling is, JRE installer from Oracle keeps pushing ask.com toolbar (borderline malware) with underhanded tactics (check box checked by default, re-checked for updates, and hidden behind changing install directory from default). Business is business, sure, and I wouldn't want something this dirty anywhere near my business...

Re:Why doubt something better would exist? (0)

Anonymous Coward | about 3 months ago | (#45925485)

I wouldn't want something this dirty anywhere near my business...

Better never take a shit; it's only a taint away from your business.

Re:Why doubt something better would exist? (5, Insightful)

IamTheRealMike (537420) | about 3 months ago | (#45925521)

Sun did that for years, that's hardly something new Oracle brought in. It's because Sun, despite their excellent engineering reputation, never figured out how to make money off Java. Lots of other companies did but Sun didn't. So they ended up resorting to pushing crapware through the Windows installer in a desperate attempt to monetize. Oracle merely continued that awful tradition.

The good news is that ever since Java has been open source, distributing it in other ways is possible and with Java 8 they're changing the license on the Oracle packagings of it so you can cut it down to size for your specific app. It's getting a lot close to just being a big runtime library than an entire parallel OS which it was trying to be in previous years.

As to whether Java is secure or not, I don't think we should be too hard on the Oracle/Sun developers here. Every attempt to do mobile code has turned into a security nightmare. Not just Java, ActiveX and Flash, but web browsers routinely patch exploits in their core rendering or JavaScript engines, and that's HTML5 - a vastly simpler and more crippled platform than even the most basic core Java system provides. In fact browser developers have given up trying to make renderers secure which is why they're all heavily sandboxed, it's inevitable people will find ways to exploit the mobile code aspects of the rendering engines. Even then, Chrome sandbox escapes still get found from time to time.

I don't think we should read these stories as "Java sucks". Programs written in Java or any other modern managed language are still much more secure than code written in C++. There are no stack or heap overflows to worry about, no double frees. These stories are not about how easy it is to write secure code in any given language or platform. Instead we should understand these stories as "sandboxing malicious code is incredibly hard". Java hurts from it more because Java was a lot more ambitious than other attempts.

Re:Why doubt something better would exist? (0)

Joce640k (829181) | about 3 months ago | (#45925579)

Programs written in Java or any other modern managed language are still much more secure than code written in C++. There are no stack or heap overflows to worry about, no double frees.

You're thinking of C, not C++.

(Trouble is, so are many people who put "C++" on their resumes...)

The problem with Java is that the exploits are in Oracle's hands, not ours. We can't fix them even if we know what they are...

The other problem with Java is that if I install the runtime on my machine to run a little corporate desktop app it also ends up in the web browser, exposed to every single web page I visit. In what universe was that a good idea?

Re:Why doubt something better would exist? (2)

RabidReindeer (2625839) | about 3 months ago | (#45925607)

Programs written in Java or any other modern managed language are still much more secure than code written in C++. There are no stack or heap overflows to worry about, no double frees.

You're thinking of C, not C++.

(Trouble is, so are many people who put "C++" on their resumes...)

The problem with Java is that the exploits are in Oracle's hands, not ours. We can't fix them even if we know what they are...

The other problem with Java is that if I install the runtime on my machine to run a little corporate desktop app it also ends up in the web browser, exposed to every single web page I visit. In what universe was that a good idea?

WHERE did you get the idea that C++ is more immune to memory leaks or buffer overflows than C? C++ adds to the basic C memory management services and memory organization, but it still retains the original C ones. And adds an additional way to leak memory - undisposed objects.

I think that the stock JVM's ability to auto-activate itself in browsers in something that varies by machine and by browser, but if it is enabled, there are ways to switch it off.

Re:Why doubt something better would exist? (1)

darkHanzz (2579493) | about 3 months ago | (#45925669)

WHERE did you get the idea that C++ is more immune to memory leaks or buffer overflows than C? C++ adds to the basic C memory management services and memory organization, but it still retains the original C ones. And adds an additional way to leak memory - undisposed objects.

Probably from experience: Consistent use of stl memory classes (shared_ptr and unique_ptr) and containers (mostly std::vector) make it very hard to shoot yourself in the foot. Adhere to "Raw pointers don't transfer livetime from function to function" if you use raw pointers. These things are really easily spotted by code-review.

Re:Why doubt something better would exist? (1)

fnj (64210) | about 3 months ago | (#45925923)

Agreed. Ignorant fools who have no idea about smart pointers and containers should shut their traps rather than pontificate about C++, since they know nothing about its first principles. They probably also think you have to use *scanf in C++.

Re:Why doubt something better would exist? (3, Informative)

RabidReindeer (2625839) | about 3 months ago | (#45926073)

This particular "ignorant fool" was one of the first commercial vendors of C++.

Just because some people may use certain features that make C++ safer doesn't mean that it is safer. Plenty of people think they're so clever that they can invent their own "more efficient/better" systems. And use scanf, for that matter.

I'm not generally of that ilk myself, but STL did make me itch. The worst features of programming and mathematics combined into one.

Re:Why doubt something better would exist? (0)

Anonymous Coward | about 3 months ago | (#45925781)

WHERE did you get the idea that C++ is more immune to memory leaks or buffer overflows than C? C++ adds to the basic C memory management services and memory organization, but it still retains the original C ones.

You are supposed to use stringstream and string in C++, you are supposed to use std::vector for growing data arrays, you are supposed to use std::shared_ptr or std:unique_ptr. The C standard library has always been a bad joke, every operation to manipulate buffers or strings needed at least 5 lines of bloat checking array size and data length to make sure that you did not corrupt your memory. The newer C standards now include alternative string and memory manipulation functions that will check several of these problems for you - to the detraction of C purists who loudly complain that these functions bloat C and make their bug riddled programs 5 micro seconds slower (note to flammers: not every fucking piece of a C program is in the middle of a performance critical loop).

So yes C++ is not more immune if you continue to use the old C style string and memory handling methods and avoid C++ features (a.k.a writing C with classes). It is more secure once you actually use what the language has to offer and avoid the replaced features.

Locale bloat in iostream (1)

tepples (727027) | about 3 months ago | (#45926255)

You are supposed to use stringstream and string in C++

I have discovered that with GNU libstdc++, instantiation of ostringstream automatically brings the date, time, and money formatting libraries into a statically linked Hello World program that doesn't even print a date, time, or money object. This causes the executable to be a quarter megabyte in size, compared to the C equivalent that's smaller than 6K. Why does this happen?

Re:Why doubt something better would exist? (0)

Anonymous Coward | about 3 months ago | (#45925919)

Programs written in Java or any other modern managed language are still much more secure than code written in C++. There are no stack or heap overflows to worry about, no double frees.

You're thinking of C, not C++.

No, he was thinking of C++.

If you go back to when Java was first released, the main corporate application programming language was C++. (There were other business logic languages that ran on big iron, but for most applications it was C++. C was reserved for operating systems, generally speaking.)

As Guy Steele, a big-time Lisp guy who designed Scheme and also co-wrote the Java spec, once remarked:

And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html

While many people may not like Java the language, I think the biggest thing it did was break the "deadlock" of C/C++ in the corporate world. Certainly the the sysadmin morlocks used things Perl, but those folks didn't count: "real" application needed a compile language. Java gave a decent third option, and once you have a third option, a fourth and fifth one don't look unreasonable, which I think is why the rise of Python and all the other dynamic languages were helped to achieve mainstreaming by Java IMHO.

Re:Why doubt something better would exist? (2)

ChunderDownunder (709234) | about 3 months ago | (#45925723)

The problem with Java is that the exploits are in Oracle's hands, not ours. We can't fix them even if we know what they are...

Only if you use Oracle's binaries. linux distros switched to openJDK years ago, whose source is available under the GPL.

Re:Why doubt something better would exist? (1)

IamTheRealMike (537420) | about 3 months ago | (#45925831)

You're thinking of C, not C++.

(Trouble is, so are many people who put "C++" on their resumes...)

No, I'm not. I'm quite fluent in C++ thanks and know how to use the STL. Yes, well written C++ is much better than your typical C app. Unfortunately, even codebases like WebKit that are worked on primarily by experienced, well paid engineers from places like Apple and Google routinely contain exploits in them that would have been avoided by the use of managed languages (not that I think WebKit should be written in Java).

The problem with Java is that the exploits are in Oracle's hands, not ours. We can't fix them even if we know what they are...

I think you missed the memo about Java going open source.

The other problem with Java is that if I install the runtime on my machine to run a little corporate desktop app it also ends up in the web browser, exposed to every single web page I visit. In what universe was that a good idea?

Not so long ago this was considered entirely unremarkable. Browser plugins were a very common and widely used idea, not just Java but Flash, QuickTime, ActiveX, Shockwave (aka Macromedia Director) and so on.

The cost of exposing surface area to malicious code was massively underestimated by practically the entire computing industry, for over a decade. Organized crime has repeatedly exploited that fact and now people are much more realistic about the difficulty of handling malicious code or data: the world learned the hard way that there are lots of ingenious ways to take control of a program that's handling malicious input, especially when those programs are written in unsafe languages!

Re:Why doubt something better would exist? (0)

Anonymous Coward | about 3 months ago | (#45925851)

The STL is the steaming pile of shit that made other languages like Java more competitive when it comes to speed and features.

Re:Why doubt something better would exist? (0)

Anonymous Coward | about 3 months ago | (#45925933)

Ignorant twit.

The managed language itself has exploits (1)

tepples (727027) | about 3 months ago | (#45926265)

Unfortunately, even codebases like WebKit that are worked on primarily by experienced, well paid engineers from places like Apple and Google routinely contain exploits in them that would have been avoided by the use of managed languages

How would the use of managed languages save the user from exploits when the managed language itself has exploits?

Re:Why doubt something better would exist? (1)

ThePhilips (752041) | about 3 months ago | (#45925655)

...are still much more secure than code written in C++. There are no stack or heap overflows to worry about, no double frees.

Ah, here we go again: poorly written C++ is worse than poorly written Java.

Coming from network daemons, frankly, I see more often how Java developers manage to fsck-up the most trivial things. All in the name of the "proper design" and "{buzzwords du jour}" and stuff. Where in C++ I needed one routine for which one code review session was enough to harden it, Java people created instead a net of 12 classes for the task. And there is no end to bugs in this convoluted mess.

In the end, I still blame Java itself. The standard library, though swelling in some parts, in many parts remained very very spartan. I've seen lots of stupid reimplementations in the C/C++ - and I tend to remove them and replace with standard functions. But with Java way too often I get back responses like "there is no standard function for it" or "standard function is way too slow". And more code gets written, causing more code to be written to organize the previously written code. And then even more code is written to organize now this code. And it goes on. End result is, a supposedly simple application, linking three 3rd party libraries, has 250 classes and requires minimum 15 threads and 16GB RAM. And that, before you count the requirements of the 3rd party libraries.

What I'm getting at, is that image of "poorly written Java application" is wrong. It probably doesn't have stack overflows, but sure like hell it has RAM and thread abuse. And blanket exception handling. And vast unparsable nets of objects delegating everything to some other objects making finding what is responsible for what virtually impossible. Making fixing the problems virtually impossible.

Re:Why doubt something better would exist? (1)

IamTheRealMike (537420) | about 3 months ago | (#45925797)

You can get bad programmers in any language. That doesn't tell you much. The problem with C/C++ is that even extremely good programmers in these languages still write code that is exploitable from time to time. Things like over-engineering or memory bloat can be trained out of people. Some kinds of buffer overflows too. But if one class in your program is bloated and overly verbose, your app will still work. If one class in your C++ program incorrectly uses scanf or starts a thread with a pointer to something on the stack, that can result in your company getting hacked and massive damage beig inflicted.

Re:Why doubt something better would exist? (1)

gbjbaanb (229885) | about 3 months ago | (#45925853)

as opposed to Java where even if you are the perfect programmer, your code is still insecure, which until Oracle decides to release some patches, can result in your company getting hacked and massive damage being inflicted.

Mind you, if you're running Java code at a company, you've already inflicted massive damage. I would welcome my new hacker overlords if they could rid me of the Enterprise Java code my company insists on using.

Anyway, you're thinking of C. No-one writing C++ uses scanf or any of the other C runtime calls, not for a decade or so.

Re:Why doubt something better would exist? (2)

IamTheRealMike (537420) | about 3 months ago | (#45925979)

No, you haven't understood what these vulnerabilities are about. They're all issues that affect you if you download and run malicious Java programs from the internet, which describes applets that are often disabled in the browser anyway. Not "any Java program that talks to the network is remotely exploitable". So if you aren't a malicious programmer then your code is still secure.

As I said above, I'm thinking of C++. You'll find a lot of C++ programs that use unsafe calls, but even if they are STL only, you can still easily do things like use after free and other bugs.

Re: Why doubt something better would exist? (1)

Anonymous Coward | about 3 months ago | (#45926333)

Realmike is totally right. These vulnerabilities are only issues in the browsers running applets. This is clearly MS FUD again. Patch build #51 is a security patch that has been in the works for months. Our company has been working with Oracle support to get any applets or other browser-based code to work with signed certs. This is going to be an issue for all bowsers when running code.... Not just Java.
We have discovered that Microsoft has created their own proprietary format for security certificates and these will only work "self-signing" on MS server with only IE browsers. They are locking out every other product. Public certs from a good source has made everything work perfectly... We have been ready for this security patch for over a month now.
        I have worked with both Oracle and java before the purchase and I am a big proponent of open source - I still don't like how Oracle assumes ownership, but we have received our own patch for java through Oracle support and everything rocks. I have developed systems in COBOL, C, C++ , java, SAS, PHP, and even that VB crap in the 90's. Java has been the best between different platforms by far, but it is only one tool of many. This posting is just flame bait, like arguing whether a screw driver is better than a hammer. Given a choice today, I would use PHP,MariaDB, and Python, but in a big enterprise, I would use Oracle and their version of java anyday. I also have a great appreciation for what Google is doing with their java base as well. It's all winning from my perspective and java will always be better than VB,C#, or any other proprietary language.

Re:Why doubt something better would exist? (0)

VortexCortex (1117377) | about 3 months ago | (#45926033)

Programs written in Java or any other modern managed language are still much more secure than code written in C++. There are no stack or heap overflows to worry about, no double frees.

Well, in C I replaced malloc with my GC allocator, and free is now optional -- it can decrement a ref count to automatically free at zero, but mark/sweep is used to bust reference chains anyway; The GC runs on free after a customizable percent (12.5% default) of total program memory has been freed, or instead of failing from a malloc (before requesting more system RAM -- The system GC is a slower kernel call, so it's last ditch effort). In C++ I overloaded the allocator interface to wrapp this GC, and RAII handles the free()s; Also gave it a slab sub-allocator for various smaller step sizes so it acts like a pooling OBCache too. Best part is I can allocate from global or thread local GC, and even tell the GC mark/sweep not to run at all unless out of memory -- only do the refcounted reclaimation, which is O(1). That way, unlike with Java, I don't have to preallocate everything, create and maintain my own caches, to fight the GC when I'm trying to do something that requires realtime performance -- It won't just up and decide to chug in the middle of an animation, level, etc., because I lost a reference to something in another thread. Java's GC is dumb, literally, it's a loose cannon that heeds nobody.

Your argument that Java code is more secure is unfounded. Java compiles bytecode into machine code -- It marks that data as code, then runs it. If you have a program that is marking data as code and executing it, then you have a vital component needed to create the exploits with. Now you just have to arrange for some of your data to get mixed in with that data before it's routinely marked code and executed. A purely interpreted system could be far more secure, but that's not what Java does.

Nope, instead Java brings a huge attack surface to the table for every program -- Not just the stuff you're using, like in C or C++, etc. Given you can classload dynamically to pull in the kitchen sink after getting just an Applet level exploit going, the whole Java API is exposed for exploitation. Java also makes software firewalling programs a PITA. Say you grant a C program access to the web through the firewall, but other C programs you don't -- Neat, eh? You have to tell your OS firewall to let Java access the web or other features, and so all Java programs then can do those things. Yes, Java has a security manager, but that's emulated security -- it doesn't have hardware enforced barriers for protections like the OS does. It's like putting rats in charge of cheese: If the user mode VM is compromised, then Java's user mode security manager is too; Not true with C or C++, the user mode process can be compromised while not compromising the OS (that requires privilege escalation). Java's updater clutters your drive with every past version -- so it doesn't matter if you get the updates, exploits can specifically target your old version Java's updater leaves installed. (Protip: Now go to add/remove or programs/features and uninstall all your damn past versions of Java @ 100MB a pop).

Java Sucks. The language is meh (so Android's not too bad), but the VM and API and platform suck -- even the sophomoric stack-based VM design is sucky. It could have been a tight little platform abstraction layer VM that has programs distributed in cross platform bytecode but compiled into machine code ONCE, on install... but it isn't. It could have been a lean mean embeddable language great for use in webpages because it could offer only the resources the browser pulls in and/or provides... but it isn't. Any move towards these ends now is too little too late. Now we have GC in compiled languages. We have FLOSS libraries for whatever feature we need. We have abstraction layers for cross platform compiled code -- We can compile our code on the few platforms we need to. Java is Android's programming language, but I wouldn't be surprised if Google's NaCL succeeds where I mentioned Java failing, and becomes a defacto bytecode target for other compiled languages like C, C++. JIT is for dummies. Compile on install is where it's at. Been doing it in my hobby OSs for a decade, and the big guys have taken notice of the screaming fast and more secure trick (you can sign the compiled machine code on install, the OS can thus inspect everything the binary will be doing, you can compile the code to leverage all the native architecture features).

Java is big in enterprise, but Java had a chance to be the whole damn web and desktop, and failed. Instead it took forever to load, dragging the kitchen sink into the browser instead of being lighter (like the J2ME stuff), Now we're stuck with the slow dynamic language that was only meant to glue Applets into HTML forms pages: JavaScript, and it's bastard child ASM.j/k. NaCl is the right stuff. I hope Google pours it all over the rest of these disgusting slugs.

Re:Why doubt something better would exist? (1)

steelfood (895457) | about 3 months ago | (#45926275)

Sun, despite their excellent engineering reputation, never figured out how to make money off Java. Lots of other companies did but Sun didn't.

That pretty much sums up Sun in a nutshell. Brilliant engineers, but couldn't make money if their life depended on it.

web browsers routinely patch exploits in their core rendering or JavaScript engines, and that's HTML5

Ever since the NSA scandal broke, I've been suspecting that the complexity of HTML5 was an attempt to keep browsers insecure.

we should understand these stories as "sandboxing malicious code is incredibly hard".

Implementing a "write once, work anywhere" language is hard. Hell, implementing a write once, work once language is hard enough. To have it not just work anywhere, but work well everywhere, is an engineering nightmare.

Re:Why doubt something better would exist? (0)

Anonymous Coward | about 3 months ago | (#45926395)

I don't remember any java update including crap-ware until oracle.

Why doesn't oracle get around to an auto-updater that runs as a service? The reason is that you can't update using a service and also get users to accept a EULA for ask.com or whatever. It's not automatic if you have to issue that popup window. Oracle gets paid for each unchecked accept so they issue as many as they can. Rather than keep things as secure as possible, they are more interested in the payout for bundling.

Do you think they bought java with good intentions (from the perspective of the end users)? It's oracle - regarding motive, need more be said?

Hell, even adobe got around to auto updates.

Re:Why doubt something better would exist? (0)

Anonymous Coward | about 3 months ago | (#45926501)

Should you be trusting auto updates that much?

Adobe had one of their code signing certs stolen last year, not used for Flash though, IIRC. Also, Adobe's updater helpfully installed McAfee's crap last time it updated - without any visible way to opt-out.

Opera had their auto-update serving Opera-signed malware last year - just for few hours, thankfully, but just think about this.

Do you really trust them not to send you malware, or at least crapware as an update, or at least update that'll brick your auto-updated PC?

Re:Why doubt something better would exist? (0)

Anonymous Coward | about 3 months ago | (#45925739)

It only happens on windows, likely their costly enterprise software package wont have it (yes oracle sells Java licenses with better tooling) and rumor has it that they can't get rid of the ask toolbar until a contract signed between Sun and ask.com runs out. Also they are not alone, "free" windows software is a breeding ground for toolbars, limited time free test installations, etc. among other software the flash installer also pulls in crap ware and Adope isn't exactly hurting for money either. In other words the software culture on windows sucks and almost everything free comes with strings attached.

Re:Why doubt something better would exist? (0)

Anonymous Coward | about 3 months ago | (#45925565)

This seems like revisionist or at least incorrect history. I've owned and managed Sun products and worked in Java as well a very long time.

Sun had a reputation for solid, but overpriced hardware even from the beginning. After the late 90s and early 2000s as Linux on the server to catch up to Solaris and at least an improved Linux desktop, Sun really was in trouble. They didn't do very much to justify the prices of their hardware vs. cheaper PC server hardware that could run Linux, and buying Sun just for the OS wasn't getting you much either other than perhaps a vendor backed nix.

On the Java end, the need they were responding to was a somewhat of a perfect storm for them, but it wasn't a computing need so much as something that came as a result of better products killing themselves. At the time, there were many tools and languages that allowed you to write cross-platform code. Most of them had more mature, better IDEs than Java, and usually they were also faster. Lucky for Sun, there were a few major issues:

1. Some of the vendors of related languages were too greedy and the markets too fragmented. The most obvious example is Smalltalk, which in many ways is still arguably better than Java, and at the time was far superior technically.

2. Nerds. Lisp had been around a long time, but wasn't "cool" and had a huge, unwelcoming, and unforgiving nerd culture. It didn't help that there were powerful IDEs that were completely inaccessible to your average garbage business programmer.

3. Promises by some of the front-runners based on nonsense or promising too much. COBOL is one example.

4. Lots of C-style programmers that weren't getting stuff done fast enough and lacked the skills and tools to write cross-platform code.

5. RAD/Microsoft. People wanted a response to things like Visual Basic as the Java market started to develop more. No reason another language, especially Smalltalk couldn't be the answer, but greed + nerd culture really screwed that one up.

6. Boredom and lack of silver bullets (see #3), so the search for another. Fortran and others didn't really do much to make people fall in love long-term.

So Sun came in, over promised, delivered something that didn't perform, but hey you could learn it in a few hours if you knew a C-style language and you didn't have to pay at least to get started. I used the first few versions of Java (of course Java 7 and the JVM today) and they really really sucked. It was actually a miracle anything ran, especially when people "tried" (operative word) to write GUI apps with it. One only need look at the earlier Sun namespaces and of course previous versions of Java to see what a terrible mess Sun inflicted on the world all these years. Meanwhile various Lisps and Smalltalks still have great standard libraries with code now several decades old that still put Java to shame.

Interesting aside: there were studies and data collected for years and an overwhelming majority of Java systems that Sun and others pushed on large contracts to replace Lisp, Smalltalk, Fortran, and other older systems failed miserably. There's many prominent examples in the case of Smalltalk in particular and those same systems often still haven't been replaced after many tries in some cases. Such is the tech world.

Anyway, Java already was DOA long before Oracle. It took insane sums of money, various acquisitions (ex: hotspot), and a lot of talent to make Java even something 1/2 of what was promised, fast, and usable. It still has plenty of issues today. Sun was always very greedy but smarter about it and at least liked to pretend they were doing something good. The upside was that they at least had interesting if not non-practical visions of computing. Oracle is just boring and greedy. As far as I'm concerned, I'm happy Sun is gone and I will be even happier if Oracle is gone too. It's a shame either company was able to take so much money from the IT world. They deserve to rot together. I hope they join the various greedy Smalltalk vendors they replaced.

Re:Why doubt something better would exist? (0)

Anonymous Coward | about 3 months ago | (#45925843)

Yes you are one of those irrational haters. We laugh at you as we take your job.

Re:again? (1)

Mashiki (184564) | about 3 months ago | (#45925533)

Java could have been fixed when they found out that their sandbox execution back in the early 2000's had so many holes that it made a sieve look like a glass. And by fix, I mean nuke it from orbit and rebuild it from the ground up instead of issuing bandage after bandage, on something they knew was already a mess.

Re:again? (1)

Urkki (668283) | about 3 months ago | (#45925659)

Java could have been fixed when they found out that their sandbox execution back in the early 2000's had so many holes that it made a sieve look like a glass. And by fix, I mean nuke it from orbit and rebuild it from the ground up instead of issuing bandage after bandage, on something they knew was already a mess.

Coulda Woulda Shoulda...

It's interesting how technical debt has interest, sometimes so high you can only keep doing the equivalent of "pressing more money" and see where that takes you (as if everybody didn't know).

Re: again? (0)

Anonymous Coward | about 3 months ago | (#45925795)

I have seriosu doubts whether there will ever be a high-performance and secure implementation of a JVM. Java itself is systematically inefficient and they need to do massively complex buttfucks to make it fast. Complexity normally equates to insecurity in computer science.

Re: again? (0)

Anonymous Coward | about 3 months ago | (#45925725)

There are lots of alternatives from FreePascal to Perl. Or Sappeur. SUN have played the sales whore instead of doing proper engineering. They nicely fit into Oracle.

Re:again? (0, Interesting)

Anonymous Coward | about 3 months ago | (#45925299)

*Javascript.

Java applets are way nicer than Javascript "apps": they're easier to program, they have a decent set of libraries, they're more fluid, and they have a more consistent UI. The only problem here is that a dying Sun and then Oracle left Java to rot, while the hundreds of bugs found in DHTML+Javascript over the last decade have been fixed at a pace steady enough to please people.

You want to know why there's a reduction in PC sales? Because Google+Apple have won the war of turning the PC into a lowest common denominator web browsing platform, even while more native platform specific software - in the form of "apps" - has been written than ever before, just not for Windows. Even Oracle doesn't seem to like the idea of Java on the desktop, hence meaningless changes to make it harder to run (e.g. requiring purchase of security certs now even though that does nothign to improve security). Because Oracle also wants you to keep everything in the "cloud", as that means someone somewhere purchasing its database engine.

Don't be fooled by the propaganda of salesmen.

Re: again? (0)

Anonymous Coward | about 3 months ago | (#45925729)

JS is an untyped crapola. But that doesn't mean Java is good.It's merely a bit better. Go for Pascal, Ada, Sappeur and even FORTRAN if you want engineering-quality instead of "lastest and greatest brainfart of random hipster"

Re:again? (1)

myowntrueself (607117) | about 3 months ago | (#45925391)

Java, one of the worst things to happen to computing, ever.

Unless you make/sell RAM.

Re:again? (0)

Anonymous Coward | about 3 months ago | (#45925405)

Who knew anyone could make a bytecode interpreter even more bloated than Emacs?

Re:again? (0)

Anonymous Coward | about 3 months ago | (#45925613)

Java, one of the worst things to happen to computing, ever.

Unless you make/sell RAM.

Large hard drives are another culprit. Without a shitload of storage space to write bloatware, code would have to be efficient, as it used to be due to system restrictions.

A single install of the most popular PDF reading program will likely be larger in size than the entire collection of PDFs a person might ever view in their lifetime.

That's fucking ridiculous.

Re: again? (0)

Anonymous Coward | about 3 months ago | (#45925745)

You are referring to Adobe who are very likely in the pay of the intel overlords, so that they have an avenue into your computer in case they don't have a windows or linux exploit for a certain time frame.

Re:again? (2)

Richard_at_work (517087) | about 3 months ago | (#45925417)

Its amazing how Java went from being the favoured child here on Slashdot to something generally reviled and hated over the past decade.

Re:again? (0)

Anonymous Coward | about 3 months ago | (#45925453)

Its amazing how Java went from being the favoured child here on Slashdot to something generally reviled and hated over the past decade.

Why? Do you just assume that slashdotters are incapable to change their point of view given more information?
Perhaps Java has gotten worse over the years? More bloat and more security holes compared to when it started out.

Re:again? (0)

Anonymous Coward | about 3 months ago | (#45925455)

JavaScript is the new darling.

Re:again? (5, Insightful)

Sesostris III (730910) | about 3 months ago | (#45925541)

Its amazing how Java went from being the favoured child here on Slashdot to something generally reviled and hated over the past decade.

I don't think this is unique to Java; the same thing has happened here with Ubuntu/Canonical. Love can easily turn to hate whereas indifference rarely does.

Concerning Java, I don't think it is Java per se that is the cause of the 'hatred', it is more (1) the insecurity of the browser plug-in, (2) the attempt to install the ask.com toolbar when installing the JRE and (3) a general distrust of Oracle.

I don't have a problem with any of these. For #1 this can be disabled, for #2 I just download the JDK .tar.gz for Linux and just unpack it to install, and for #3 there is always OpenJDK in the background to keep Oracle on the straight an narrow.

The only real alternative to Java is .NET, which for me (using Linux) would mean using Mono. Interestingly, open-source Mono seems to generate more hatred here on Slashdot than the closed-source and proprietary .NET does.

Re:again? (1)

IamTheRealMike (537420) | about 3 months ago | (#45925559)

A lot of people can't/won't distinguish between "Java sandboxing isn't good", "Java the language isn't good" and "Java the platform isn't good".

Java sandboxing is clearly not good enough for real world use and most browser makers have realised this and disabled it. On the other hand, it's only in very recent times that browsers got sandboxes and some common ones like Firefox still don't. That fact was exploited recently to de-anonymize Tor users. So it's not like Java is alone here. Pretty much every attempt to sandbox malicious code has failed badly.

Java the language is mediocre at best, though its strength is not to be fun or pleasant but good for large projects with large teams. Lots of people try to build enormous codebases in PHP, JavaScript or Python which are dramatically worse for the task, so apparently that message hasn't really got through (unfortunately by the time a project notices this it's usually too late to switch to anything else).

Java the platform has got a lot better in recent years. The worst excesses of the "enterprise Java" world, with its ridiculously over-engineered libraries and XML config files everywhere, have largely been left behind. There are now quite a lot of slick and modern frameworks. The JVM has come to support other languages much better in recent years and there are now quite a few very cool and interesting languages like Scala, Ceylon or Kotlin targeting the JVM that have really good Java interop, so you have access to lots of libraries. There's an apt-get style dependency management system and central repository so depending on those libraries is a breeze, and Java IDEs (IntelliJ in particular) finally became really fast and slick. Also, JavaFX is turning into a really nice replacement for Swing, so your Java GUIs can finally feel modern and fit in natively amazingly well [aquafx-project.com]. JavaFX can be OpenGL/DX accelerated when the hardware supports it so you can get a consistent 60fps, it's got a great animation framework, a nice GUI builder tool, lots of visual effects along with the basics like charting components. And even an embedded WebKit if you want that. I've been playing with JFX in the Java 8 previews and it's really quite impressive.

Re:again? (1)

war4peace (1628283) | about 3 months ago | (#45925575)

Because Oracle got it, and Oracle is evil, therefore now Jave MUST be evil too.

Re: again? (0)

Anonymous Coward | about 3 months ago | (#45925755)

oracle products are indeed evil, as you can shoot down the ora listener by merely telneting into it and then typing some random characters. At least that was the state of affairs in 1998. I bet they got only superficially better.

Larry is a commerce whore.

Re:again? (2)

Joce640k (829181) | about 3 months ago | (#45925591)

Its amazing how Java went from being the favoured child here on Slashdot to something generally reviled and hated over the past decade.

Why? Changing your mind when presented with strong evidence is a sign of intelligence.

You should only be "amazed" when this doesn't happen (ie. religion, politics...)

Re:again? (2)

Kjella (173770) | about 3 months ago | (#45925645)

It's more of a "there and back again" story really. Ten years ago RMS published his Java Trap [gnu.org] and the open source community was rather weary of making anything depending on a JRE blob. In 2006 Sun announced they'd open source [slashdot.org] Java and all hearts rejoiced. Except it took a really long time, here's an article [slashdot.org] on how it might finish in 2008.

Perhaps of biggest imporance is that Java ME never got freed, Sun and later Oracle always wanted a fee if you wanted to put it on your mobile phone. Then Sun got bought by Oracle [slashdot.org] in 2009, and where Sun had been admicable about the existance of Android Oracle instead chose to sue Google [slashdot.org] in 2010, claiming patent violations and copyright to the APIs. Particularly the latter is anathema in the open source community.

Due to Android being a runaway success driving Java ME out of the market and Oracle fighting it all the way in court they got branded with "stopped innovating, started suing" and the divide between Oracle with OpenOffice and the open source community with LibreOffice didn't help either. Whatever Sun and Java might have been, a friend bought out by your enemy is now your enemy.

Not that this is what's bothered the rest of the world though. For them it's all the constant critical security exploits which has turned Java into the security bad boy. It used to be ActiveX, it used to be Flash but these days the #1 security advice seems to be "disable Java". They should have just pulled support for applets because it's tar and feathering the whole brand, even for software that doesn't suffer from remote exploits.

Re: again? (0)

Anonymous Coward | about 3 months ago | (#45925779)

I have a CS degree and about 15 years of developer experience. I designed a language myself (Sappeur). From my P.O.V. Java has not been much more than a Sales Tool for SUN. Nothing in Java is brilliant or elegant.

Rather it is clunky, energy-wasting, RAM-devouring, non-realtime-capable, overly complex and thereby a massive security risk.

I hope Oracle will "defend" Java and all the assorted patents with fervour, so that the world can move on. So that Java can die a proper death in a corporate graveyard.

Pascal, Ada, Fortran - take these any time over this creation of commerical-men.

Re:again? (2)

drinkypoo (153816) | about 3 months ago | (#45925881)

Its amazing how Java went from being the favoured child here on Slashdot to something generally reviled and hated over the past decade.

Having actually been here for the last decade, I don't know what you're on about. Java has never been the favorite son of Slashdot. There has always been a massive contingent that holds that Java is slow and stupid. Sure, there's always been a group that opposes it, but it's always been smaller. Where do you think you are, anyway?

Re:again? (0)

Anonymous Coward | about 3 months ago | (#45926521)

It's because Java has become extremely popular as a language, and the generally prevailing opinion on Slashdot is that only hip things are cool.

There's also a HUGE amount of misunderstanding about what's exactly "insecure" about Java. This is to the point that a "security expert" told me he was nervous about Java code written by internal developers because Java isn't "secure". For code written by internal developers running outside a browser, that's like saying "C++ isn't secure". This was the opinion of someone hired at a Fortune 100 company as the security expert holding high level security certifications. Now, I'm not terribly impressed with either of those things, but it goes to show the level to which the missinformation has risen.

There's a big difference between Java the language, Java the runtime environment, and Java the browser plugin designed to run untrusted code in a sandbox environment. Only the last one isn't secure, and for the most part people have abandoned these apps long ago (with sadly some exceptions). Java the browser plugin is about as insecure as Flash is/was (which is pretty damn insecure), though Flash was/is far more popular and hard to get rid of than Java ever was.

Java the runtime environment, and Java the language are about as secure as any other runtime environment. If you trust the person who wrote the code to not do nasty things, it's secure. We could have a discussion about whether Java is more secure than C++ because of the inability to perform buffer exploits in Java, or if it's more secure than PHP because PHP is..... well broken. But that's at least something that's debatable.

Personally, I think the big thing that's changed on Slashdot over the last 10 years is that it's gotten far dumber and more reactionary. I see more inflated article, more inflamatory responses, less intelligent criticism, and less facts than I ever have. About 3 years ago I decided it'd gotten bad enough that it wasn't even worth logging in and posting anymore.

Who needs (0)

Anonymous Coward | about 3 months ago | (#45925211)

Native code now

Discontinuing Java - what will it take? (0)

Anonymous Coward | about 3 months ago | (#45925225)

nt

Re:Discontinuing Java - what will it take? (0)

Anonymous Coward | about 3 months ago | (#45925265)

Flash is more fun.

Re:Discontinuing Java - what will it take? (0)

Anonymous Coward | about 3 months ago | (#45925301)

Let's all go back to using BCPL O-code!

concerning is ... (3, Interesting)

Selur (2745445) | about 3 months ago | (#45925227)

that of the 36 Java related bugs, "34 of them (are) exploitable remotely without authentication".

"Java 6 users who use equipment or programs that rely on older versions are SOL unless they sign up for a very expensive support contract, as these patches are for Java 7 only."
+
"Oracle Java JDK and JRE, versions 5.0u55 and earlier, 6u65 and earlier, 7u45 and earlier"
-> Muhahahaha,...

Re:concerning is ... (0)

Anonymous Coward | about 3 months ago | (#45925791)

programs that rely on older versions

Any Java program that wont run on a new JVM is already questionable - even breaking language changes will not affect compiled bytecode. You might however need more RAM (or most likely less) since Java 7 changes implementation details of substring to fix some memory leaks.

Re:concerning is ... (2)

drinkypoo (153816) | about 3 months ago | (#45925865)

Any Java program that wont run on a new JVM is already questionable

Yeah, the majority of big Java programs ship with a JRE specifically because switching to a new one may well break something. That doesn't really detract from your statement, but most big Java programs are questionable. Or perhaps the question is why anyone thinks Java is a good idea to begin with.

Re:concerning is ... (3, Insightful)

mrmeval (662166) | about 3 months ago | (#45925793)

ADP forces the use of an ancient and bug infested version of java for it's timecard application. We've been infected SO MANY times they finally decided to setup a dedicated PC that has no other access.

This of course removes all the benefit of having web acdess to time card entry, eats up time employees could be working but the gossip and knife fights are good entertainment.

Re:concerning is ... (0)

Anonymous Coward | about 3 months ago | (#45926345)

No more concerning than usual.

"Exploitable remotely without authentication" doesn't mean "install Java, get remotely pwnd", it's just a common classification for all bugs exploitable via the Java plugin in this case. There's also a question of what attacker can achieve by succesful exploit: from crashing plugin thru reading data he shouldn't be able to and to privilege escalation and arbitrary code execution.

For example, a bug in HTML renderer that crashes your browser, or bug in DNS server that makes it slow to a crawl on an incorrect request would be "exploitable remotely without authentication" as well.

Re:concerning is ... (0)

Anonymous Coward | about 3 months ago | (#45926375)

To clarify, it's not "meh, it's nothing!", it's "not enough data, but likely just keep that Java browser plugin disabled and you're safe".

Wimpy (0)

Anonymous Coward | about 3 months ago | (#45925231)

I will gladly patch you Tuesday for an exploit today.

Oh No Not Java! (0)

Anonymous Coward | about 3 months ago | (#45925311)

I use Java for everything! I'm so screwed.............

Oracle and Java What the hell happened? (3, Interesting)

Tim99 (984437) | about 3 months ago | (#45925337)

Oracle and Java exploits - An anecdote:-
A couple of weeks ago I tried to log into my superannuation account, the browser fired back an authentication error, so I notified the company (MLC) who asked me to send them as many technical details as I could. After a little bit of looking around, I noted that the Oracle Access Management system that gave me the error code was was at version (11.1.1.5.0). Oracle's currently version was 11.1.2.1.0. Not too surprising, a supplier that had not patched to the current version.

What did surprise me was that Oracle's Identity Management Patch Set that was available for the version displayed was >2GB - A compressed Java application and framework for a database authentication application that was over 2 Gigabytes in size .

It has been a few years since I wrote any Oracle stuff, but that is ridiculous, what the hell have web based script kiddy/Java type developers been up to. Admittedly I started with Oracle in the Stone Age (V3) and actually shipped an application that used V4. By V6 the C interface which included all the necessary external validation code was small enough to be easily understood and modifiable by a single programmer. My memory is going now, but I seem to remember that in the 1990s all of the code for an early web CGI Oracle interface, including user validation would fit on a floppy.

Re:Oracle and Java What the hell happened? (0)

Anonymous Coward | about 3 months ago | (#45925437)

. My memory is going now, but I seem to remember that in the 1990s all of the code for an early web CGI Oracle interface, including user validation would fit on a floppy.

What's a "floppy"?

Re:Oracle and Java What the hell happened? (0)

Anonymous Coward | about 3 months ago | (#45925461)

What's a "floppy"?

There are several meanings, both you'd understand if you were older.

Re:Oracle and Java What the hell happened? (0)

Anonymous Coward | about 3 months ago | (#45925555)

> several
> both

Choose one.

Re:Oracle and Java What the hell happened? (0)

Anonymous Coward | about 3 months ago | (#45925651)

Try a source with some authority (0)

Anonymous Coward | about 3 months ago | (#45926063)

http://www.oxforddictionaries.com/definition/english/several

Re:Oracle and Java What the hell happened? (1)

tenco (773732) | about 3 months ago | (#45925601)

What's a "floppy"?

Less than you can download in a second.

Re:Oracle and Java What the hell happened? (1)

c0lo (1497653) | about 3 months ago | (#45925859)

What's a "floppy"?

Less than you can download in a second.

Something that took a day to download in the mid '90 over a dialup connection (if it stayed connected that long).

Re:Oracle and Java What the hell happened? (0)

Anonymous Coward | about 3 months ago | (#45925505)

In the Oracle world, patching does not affect version numbers. A different version means different or new functionality, even if it is the last part of the version.
Based on the version, you cannot determine if it is patched or not.

Re:Oracle and Java What the hell happened? (1)

Rich0 (548339) | about 3 months ago | (#45926433)

In the Oracle world, patching does not affect version numbers. A different version means different or new functionality, even if it is the last part of the version.
Based on the version, you cannot determine if it is patched or not.

Makes sense - if they wanted to actually show patch level they'd need a more complex version numbering scheme. Just how much information do you think can really be communicated in 5 separate version numbers?

Re:Oracle and Java What the hell happened? (0)

Anonymous Coward | about 3 months ago | (#45925543)

My memory is going now, but I seem to remember that in the 1990s all of the code for an early web CGI Oracle interface, including user validation would fit on a floppy.

You should try writing a plugin for Atlassian Bamboo. Here's the ~120MB worth of dependencies you'll take on:

/javax/activation/activation/1.1.1/activation-1.1.1.jar
/javax/jms/jms/1.1/jms-1.1.jar
/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar
/javax/mail/mail/1.4.1/mail-1.4.1.jar
/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar
/javax/xml/stream/stax-api/1.0-2/stax-api-1.0-2.jar
/org/acegisecurity/acegi-security/1.0.4/acegi-security-1.0.4.jar
/org/apache/activemq/activemq-core/5.6.0/activemq-core-5.6.0.jar
/org/apache/activemq/activemq-pool/5.6.0/activemq-pool-5.6.0.jar
/org/apache/activemq/protobuf/activemq-protobuf/1.1/activemq-protobuf-1.1.jar
/org/apache/activemq/activemq-ra/5.6.0/activemq-ra-5.6.0.jar
/com/atlassian/activeobjects/activeobjects-spi/0.19.11.bamboo.4/activeobjects-spi-0.19.11.bamboo.4.jar
/org/sonatype/aether/aether-api/1.13.1/aether-api-1.13.1.jar
/org/sonatype/aether/aether-connector-wagon/1.13.1/aether-connector-wagon-1.13.1.jar
/org/sonatype/aether/aether-spi/1.13.1/aether-spi-1.13.1.jar
/org/sonatype/aether/aether-util/1.13.1/aether-util-1.13.1.jar
/com/atlassian/analytics/analytics-api/2.29/analytics-api-2.29.jar
/com/intellij/annotations/6.0.5/annotations-6.0.5.jar
/org/apache/ant/ant/1.8.4/ant-1.8.4.jar
/org/apache/ant/ant-launcher/1.8.4/ant-launcher-1.8.4.jar
/antlr/antlr/2.7.7/antlr-2.7.7.jar
/org/antlr/antlr-runtime/3.4/antlr-runtime-3.4.jar
/aopalliance/aopalliance/1.0/aopalliance-1.0.jar
/com/atlassian/applinks/applinks-api/4.0.5/applinks-api-4.0.5.jar
/com/atlassian/applinks/applinks-host/4.0.5/applinks-host-4.0.5.jar
/com/atlassian/applinks/applinks-spi/4.0.5/applinks-spi-4.0.5.jar
/com/atlassian/annotations/atlassian-annotations/0.4/atlassian-annotations-0.4.jar
/com/atlassian/aws/atlassian-aws/1.0.45/atlassian-aws-1.0.45.jar
/com/atlassian/bamboo/atlassian-bamboo-agent-bootstrap/5.2/atlassian-bamboo-agent-bootstrap-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-agent-classserver/5.2/atlassian-bamboo-agent-classserver-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-agent-core/5.2/atlassian-bamboo-agent-core-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-agent-elastic/5.2/atlassian-bamboo-agent-elastic-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-agent-elastic-server/5.2/atlassian-bamboo-agent-elastic-server-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-agent-elastic-shared/5.2/atlassian-bamboo-agent-elastic-shared-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-agent-local/5.2/atlassian-bamboo-agent-local-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-agent-remote/5.2/atlassian-bamboo-agent-remote-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-api/5.2/atlassian-bamboo-api-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-api-agent-bootstrap/5.2/atlassian-bamboo-api-agent-bootstrap-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-charts/5.2/atlassian-bamboo-charts-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-core/5.2/atlassian-bamboo-core-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-core-agent-bootstrap/5.2/atlassian-bamboo-core-agent-bootstrap-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-deployments-api/5.2/atlassian-bamboo-deployments-api-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-language/5.2/atlassian-bamboo-language-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-license/5.2/atlassian-bamboo-license-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-maven-embedder/5.2/atlassian-bamboo-maven-embedder-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-migration/5.2/atlassian-bamboo-migration-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-persistence/5.2/atlassian-bamboo-persistence-5.2.jar
/com/atlassian/bamboo/plugins/scripttask/atlassian-bamboo-plugin-scripttask/5.2/atlassian-bamboo-plugin-scripttask-5.2.jar
/com/atlassian/bamboo/plugins/atlassian-bamboo-plugin-ssh/5.2/atlassian-bamboo-plugin-ssh-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-test-utils/5.2/atlassian-bamboo-test-utils-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-upgrader/5.2/atlassian-bamboo-upgrader-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-web/5.2/atlassian-bamboo-web-5.2.jar
/com/atlassian/bamboo/atlassian-bamboo-xml-utils/5.2/atlassian-bamboo-xml-utils-5.2.jar
/com/atlassian/bandana/atlassian-bandana/3.1/atlassian-bandana-3.1.jar
/com/atlassian/bonnie/atlassian-bonnie/3.4.1/atlassian-bonnie-3.4.1.jar
/com/atlassian/bucket/atlassian-bucket/1.3/atlassian-bucket-1.3.jar
/com/atlassian/cache/atlassian-cache-api/1.0/atlassian-cache-api-1.0.jar
/com/atlassian/config/atlassian-config/0.16/atlassian-config-0.16.jar
/com/atlassian/security/atlassian-cookie-tools/2.0/atlassian-cookie-tools-2.0.jar
/com/atlassian/core/atlassian-core/4.6.2/atlassian-core-4.6.2.jar
/com/atlassian/event/atlassian-event/2.2.1-20120119/atlassian-event-2.2.1-20120119.jar
/com/atlassian/extras/atlassian-extras/2.4/atlassian-extras-2.4.jar
/com/atlassian/hibernate/atlassian-hibernate-extras/2.2/atlassian-hibernate-extras-2.2.jar
/com/atlassian/image/atlassian-image-consumer/1.0.1/atlassian-image-consumer-1.0.1.jar
/com/atlassian/ip/atlassian-ip/2.0/atlassian-ip-2.0.jar
/com/atlassian/johnson/atlassian-johnson/1.0/atlassian-johnson-1.0.jar
/com/atlassian/mail/atlassian-mail/2.4.1/atlassian-mail-2.4.1.jar
/com/atlassian/security/atlassian-password-encoder/3.0/atlassian-password-encoder-3.0.jar
/com/atlassian/plugins/atlassian-plugins-core/2.13.5-m4/atlassian-plugins-core-2.13.5-m4.jar
/com/atlassian/plugins/atlassian-plugins-osgi/2.13.5-m4/atlassian-plugins-osgi-2.13.5-m4.jar
/com/atlassian/plugins/atlassian-plugins-osgi-events/2.13.5-m4/atlassian-plugins-osgi-events-2.13.5-m4.jar
/com/atlassian/plugins/atlassian-plugins-servlet/2.13.5-m4/atlassian-plugins-servlet-2.13.5-m4.jar
/com/atlassian/plugins/atlassian-plugins-spring/2.13.5-m4/atlassian-plugins-spring-2.13.5-m4.jar
/com/atlassian/plugins/atlassian-plugins-webfragment/2.13.5-m4/atlassian-plugins-webfragment-2.13.5-m4.jar
/com/atlassian/plugins/atlassian-plugins-webresource/2.13.5-m4/atlassian-plugins-webresource-2.13.5-m4.jar
/com/atlassian/utils/atlassian-processutils/1.5.12/atlassian-processutils-1.5.12.jar
/com/atlassian/profiling/atlassian-profiling/1.8.1/atlassian-profiling-1.8.1.jar
/com/atlassian/security/atlassian-secure-random/2.2/atlassian-secure-random-2.2.jar
/com/atlassian/seraph/atlassian-seraph/2.5.2/atlassian-seraph-2.5.2.jar
/com/atlassian/spring/atlassian-spring/2.0.0/atlassian-spring-2.0.0.jar
/com/atlassian/testtools/atlassian-testtools/1.8/atlassian-testtools-1.8.jar
/com/atlassian/security/auth/trustedapps/atlassian-trusted-apps-core/2.5.2/atlassian-trusted-apps-core-2.5.2.jar
/com/atlassian/security/auth/trustedapps/atlassian-trusted-apps-seraph-integration/2.5.2/atlassian-trusted-apps-seraph-integration-2.5.2.jar
/com/atlassian/tunnel/atlassian-tunnel/0.20/atlassian-tunnel-0.20.jar
/com/atlassian/user/atlassian-user/1.9.1/atlassian-user-1.9.1.jar
/com/atlassian/bamboo/atlassian-user-crowd-provider/5.2/atlassian-user-crowd-provider-5.2.jar
/com/atlassian/util/concurrent/atlassian-util-concurrent/2.4.1/atlassian-util-concurrent-2.4.1.jar
/com/atlassian/velocity/atlassian-velocity/0.5/atlassian-velocity-0.5.jar
/com/atlassian/xwork/atlassian-xwork-12/1.13-xwork2-4/atlassian-xwork-12-1.13-xwork2-4.jar
/com/atlassian/xwork/atlassian-xwork-core/1.13-xwork2-4/atlassian-xwork-core-1.13-xwork2-4.jar
/com/atlassian/aui/auiplugin-spi/5.2-m6/auiplugin-spi-5.2-m6.jar
/com/amazonaws/aws-java-sdk/1.4.0.1/aws-java-sdk-1.4.0.1.jar
/backport-util-concurrent/backport-util-concurrent/2.1/backport-util-concurrent-2.1.jar
/org/bouncycastle/bcpkix-jdk15on/1.48/bcpkix-jdk15on-1.48.jar
/bouncycastle/bcprov-jdk14/138/bcprov-jdk14-138.jar
/org/bouncycastle/bcprov-jdk15/1.44/bcprov-jdk15-1.44.jar
/org/bouncycastle/bcprov-jdk15on/1.48/bcprov-jdk15on-1.48.jar
/org/bouncycastle/bcprov-jdk16/1.46/bcprov-jdk16-1.46.jar
/biz/aQute/bndlib/1.43.0-atlassian-1/bndlib-1.43.0-atlassian-1.jar
/com/atlassian/botocss/botocss/3.0/botocss-3.0.jar
/c3p0/c3p0/0.9.1.2/c3p0-0.9.1.2.jar
/cglib/cglib-nodep/2.1_3/cglib-nodep-2.1_3.jar
/classworlds/classworlds/1.1/classworlds-1.1.jar
/commons-beanutils/commons-beanutils/1.8.3/commons-beanutils-1.8.3.jar
/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
/commons-codec/commons-codec/1.4/commons-codec-1.4.jar
/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
/org/apache/commons/commons-compress/1.4.1/commons-compress-1.4.1.jar
/commons-configuration/commons-configuration/1.4-atlassian-1/commons-configuration-1.4-atlassian-1.jar
/commons-dbutils/commons-dbutils/1.3/commons-dbutils-1.3.jar
/commons-digester/commons-digester/1.8/commons-digester-1.8.jar
/commons-fileupload/commons-fileupload/1.2.2/commons-fileupload-1.2.2.jar
/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar
/commons-io/commons-io/2.4/commons-io-2.4.jar
/commons-jxpath/commons-jxpath/1.2/commons-jxpath-1.2.jar
/commons-lang/commons-lang/2.6/commons-lang-2.6.jar
/org/apache/commons/commons-lang3/3.1/commons-lang3-3.1.jar
/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
/commons-pool/commons-pool/1.3/commons-pool-1.3.jar
/com/atlassian/crowd/crowd-integration-api/2.3.0-rc2/crowd-integration-api-2.3.0-rc2.jar
/com/atlassian/crowd/crowd-integration-client-common/2.3.0-rc2/crowd-integration-client-common-2.3.0-rc2.jar
/com/atlassian/crowd/crowd-integration-client-rest/2.3.0-rc2/crowd-integration-client-rest-2.3.0-rc2.jar
/com/atlassian/crowd/crowd-integration-seraph25/2.3.0-rc2/crowd-integration-seraph25-2.3.0-rc2.jar
/dom4j/dom4j/1.4/dom4j-1.4.jar
/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar
/org/easymock/easymock/2.4/easymock-2.4.jar
/org/easymock/easymockclassextension/2.4/easymockclassextension-2.4.jar
/net/sf/ehcache/ehcache/1.2.3/ehcache-1.2.3.jar
/com/atlassian/crowd/embedded-crowd-api/2.3.0-rc2/embedded-crowd-api-2.3.0-rc2.jar
/exml/exml/7.0/exml-7.0.jar
/com/jhlabs/filters/2.0.235/filters-2.0.235.jar
/org/freemarker/freemarker/2.3.16-atlassian-23/freemarker-2.3.16-atlassian-23.jar
/com/atlassian/fugue/fugue/1.1/fugue-1.1.jar
/org/apache/geronimo/specs/geronimo-j2ee-connector_1.5_spec/2.0.0/geronimo-j2ee-connector_1.5_spec-2.0.0.jar
/org/apache/geronimo/specs/geronimo-j2ee-connector_1.6_spec/1.0/geronimo-j2ee-connector_1.6_spec-1.0.jar
/org/apache/geronimo/specs/geronimo-j2ee-management_1.1_spec/1.0.1/geronimo-j2ee-management_1.1_spec-1.0.1.jar
/org/apache/geronimo/specs/geronimo-jms_1.1_spec/1.1.1/geronimo-jms_1.1_spec-1.1.1.jar
/org/apache/geronimo/specs/geronimo-jta_1.1_spec/1.1.1/geronimo-jta_1.1_spec-1.1.1.jar
/org/apache/geronimo/components/geronimo-transaction/3.1/geronimo-transaction-3.1.jar
/com/google/code/gson/gson/2.2.2/gson-2.2.2.jar
/com/google/guava/guava/10.0.1/guava-10.0.1.jar
/org/hamcrest/hamcrest-all/1.3/hamcrest-all-1.3.jar
/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
/hibernate/hibernate/2.1.8-atlassian-12/hibernate-2.1.8-atlassian-12.jar
/hsqldb/hsqldb/1.8.0.7/hsqldb-1.8.0.7.jar
/org/apache/httpcomponents/httpclient/4.1.2/httpclient-4.1.2.jar
/org/apache/httpcomponents/httpcore/4.1.2/httpcore-4.1.2.jar
/com/ibm/icu/icu4j/3.8/icu4j-3.8.jar
/isorelax/isorelax/20020414/isorelax-20020414.jar
/org/codehaus/jackson/jackson-core-asl/1.8.9/jackson-core-asl-1.8.9.jar
/org/codehaus/jackson/jackson-mapper-asl/1.8.9/jackson-mapper-asl-1.8.9.jar
/org/fusesource/jansi/jansi/1.9/jansi-1.9.jar
/org/jasypt/jasypt/1.8/jasypt-1.8.jar
/javacvs/javacvs/atlassian-20080407/javacvs-atlassian-20080407.jar
/javassist/javassist/3.11.0.GA/javassist-3.11.0.GA.jar
/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar
/com/octo/captcha/jcaptcha/2.0-alpha-1/jcaptcha-2.0-alpha-1.jar
/com/octo/captcha/jcaptcha-api/2.0-alpha-1/jcaptcha-api-2.0-alpha-1.jar
/net/jcip/jcip-annotations/1.0/jcip-annotations-1.0.jar
/org/slf4j/jcl-over-slf4j/1.6.4/jcl-over-slf4j-1.6.4.jar
/jfree/jcommon/1.0.12/jcommon-1.0.12.jar
/jdom/jdom/1.0/jdom-1.0.jar
/jfree/jfreechart/1.0.9/jfreechart-1.0.9.jar
/net/java/dev/jna/jna/3.4.0/jna-3.4.0.jar
/net/java/dev/jna/jna-platform/3.2.7/jna-platform-3.2.7.jar
/joda-time/joda-time/2.3/joda-time-2.3.jar
/com/jcraft/jsch/0.1.44-1/jsch-0.1.44-1.jar
/org/jsoup/jsoup/1.7.2/jsoup-1.7.2.jar
/com/google/code/findbugs/jsr305/1.3.9/jsr305-1.3.9.jar
/jtidy/jtidy/4aug2000r7-dev/jtidy-4aug2000r7-dev.jar
/junit/junit/4.8.2/junit-4.8.2.jar
/org/apache/activemq/kahadb/5.6.0/kahadb-5.6.0.jar
/net/sf/ldaptemplate/ldaptemplate/1.0.1/ldaptemplate-1.0.1.jar
/org/logicblaze/lingo/lingo/1.3/lingo-1.3.jar
/log4j/log4j/1.2.15/log4j-1.2.15.jar
/logkit/logkit/1.2/logkit-1.2.jar
/org/apache/lucene/lucene-analyzers/2.2.0/lucene-analyzers-2.2.0.jar
/org/apache/lucene/lucene-core/2.3.2/lucene-core-2.3.2.jar
/org/apache/maven/maven-artifact/2.0.7/maven-artifact-2.0.7.jar
/org/apache/maven/maven-artifact-manager/2.0.7/maven-artifact-manager-2.0.7.jar
/org/apache/maven/maven-compat/3.0.4/maven-compat-3.0.4.jar
/org/apache/maven/maven-core/2.0.7/maven-core-2.0.7.jar
/org/apache/maven/maven-embedder/3.0.4/maven-embedder-3.0.4.jar
/org/apache/maven/maven-error-diagnostics/2.0.7/maven-error-diagnostics-2.0.7.jar
/org/apache/maven/maven-model/3.0.4/maven-model-3.0.4.jar
/org/apache/maven/maven-model-builder/3.0.4/maven-model-builder-3.0.4.jar
/org/apache/maven/maven-monitor/2.0.7/maven-monitor-2.0.7.jar
/org/apache/maven/maven-plugin-api/3.0.4/maven-plugin-api-3.0.4.jar
/org/apache/maven/maven-plugin-descriptor/2.0.7/maven-plugin-descriptor-2.0.7.jar
/org/apache/maven/maven-plugin-parameter-documenter/2.0.7/maven-plugin-parameter-documenter-2.0.7.jar
/org/apache/maven/maven-plugin-registry/2.0.7/maven-plugin-registry-2.0.7.jar
/org/apache/maven/maven-profile/2.0.7/maven-profile-2.0.7.jar
/org/apache/maven/maven-project/2.0.7/maven-project-2.0.7.jar
/org/apache/maven/reporting/maven-reporting-api/2.0.7/maven-reporting-api-2.0.7.jar
/org/apache/maven/maven-repository-metadata/2.0.7/maven-repository-metadata-2.0.7.jar
/org/apache/maven/maven-settings/3.0.4/maven-settings-3.0.4.jar
/org/apache/mina/mina-core/2.0.5/mina-core-2.0.5.jar
/org/mockito/mockito-core/1.8.5/mockito-core-1.8.5.jar
/msv/msv/20020414/msv-20020414.jar
/org/objenesis/objenesis/1.0/objenesis-1.0.jar
/odmg/odmg/3.0/odmg-3.0.jar
/ognl/ognl/3.0.6/ognl-3.0.6.jar
/org/apache/felix/org.apache.felix.framework/3.0.2/org.apache.felix.framework-3.0.2.jar
/oro/oro/2.0.8/oro-2.0.8.jar
/opensymphony/oscore/2.2.7/oscore-2.2.7.jar
/opensymphony/osuser/1.0-20060106/osuser-1.0-20060106.jar
/com/tek42/perforce/p4java/0.7.5-atlassian-9/p4java-0.7.5-atlassian-9.jar
/org/twdata/pkgscanner/package-scanner/0.9.5/package-scanner-0.9.5.jar
/pjl-comp-filter/pjl-comp-filter/1.4/pjl-comp-filter-1.4.jar
/org/sonatype/plexus/plexus-cipher/1.7/plexus-cipher-1.7.jar
/org/codehaus/plexus/plexus-classworlds/2.4/plexus-classworlds-2.4.jar
/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
/org/codehaus/plexus/plexus-container-default/1.0-alpha-9-stable-1/plexus-container-default-1.0-alpha-9-stable-1.jar
/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
/org/codehaus/plexus/plexus-utils/2.0.6/plexus-utils-2.0.6.jar
/opensymphony/propertyset/1.3-21Nov03/propertyset-1.3-21Nov03.jar
/opensymphony/quartz/1.6.5/quartz-1.6.5.jar
/relaxngDatatype/relaxngDatatype/20020414/relaxngDatatype-20020414.jar
/rome/rome/1.0/rome-1.0.jar
/com/atlassian/sal/sal-api/2.10.2/sal-api-2.10.2.jar
/com/atlassian/sal/sal-spi/2.10.2/sal-spi-2.10.2.jar
/com/atlassian/sal/sal-spring/2.10.2/sal-spring-2.10.2.jar
/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar
/de/regnis/q/sequence/sequence-library/1.0.2/sequence-library-1.0.2.jar
/org/sonatype/sisu/sisu-guice/3.1.0/sisu-guice-3.1.0-no_aop.jar
/org/sonatype/sisu/sisu-inject-bean/2.3.0/sisu-inject-bean-2.3.0.jar
/org/sonatype/sisu/sisu-inject-plexus/2.3.0/sisu-inject-plexus-2.3.0.jar
/opensymphony/sitemesh/2.5-atlassian-6/sitemesh-2.5-atlassian-6.jar
/org/slf4j/slf4j-api/1.5.6/slf4j-api-1.5.6.jar
/org/slf4j/slf4j-log4j12/1.6.4/slf4j-log4j12-1.6.4.jar
/org/igniterealtime/smack/smack/3.3.0/smack-3.3.0.jar
/org/igniterealtime/smack/smackx/3.3.0/smackx-3.3.0.jar
/com/atlassian/soy/soy-template-renderer-api/2.0.0-m1-bamboo-2/soy-template-renderer-api-2.0.0-m1-bamboo-2.jar
/org/springframework/spring-aop/2.5.6.SEC02/spring-aop-2.5.6.SEC02.jar
/org/springframework/spring-beans/2.0.7/spring-beans-2.0.7.jar
/org/springframework/spring-context/2.0.7/spring-context-2.0.7.jar
/org/springframework/spring-core/2.0.7/spring-core-2.0.7.jar
/org/springframework/spring-dao/2.0.6/spring-dao-2.0.6.jar
/org/springframework/spring-hibernate2/2.0.6/spring-hibernate2-2.0.6.jar
/org/springframework/spring-jdbc/2.0.6/spring-jdbc-2.0.6.jar
/org/springframework/spring-jms/2.0.7/spring-jms-2.0.7.jar
/org/springframework/spring-mock/2.0.6/spring-mock-2.0.6.jar
/org/springframework/spring-remoting/2.0.7/spring-remoting-2.0.7.jar
/org/springframework/spring-support/2.0.6/spring-support-2.0.6.jar
/org/springframework/spring-web/2.5.6.SEC02/spring-web-2.5.6.SEC02.jar
/org/tmatesoft/sqljet/sqljet/1.1.5/sqljet-1.1.5.jar
/org/apache/sshd/sshd-core/0.8.0/sshd-core-0.8.0.jar
/org/codehaus/woodstox/stax2-api/3.0.4/stax2-api-3.0.4.jar
/org/codehaus/staxmate/staxmate/2.0.0/staxmate-2.0.0.jar
/org/antlr/stringtemplate/3.2.1/stringtemplate-3.2.1.jar
/org/apache/struts/struts2-core/2.3.15.1-atlassian-4/struts2-core-2.3.15.1-atlassian-4.jar
/org/apache/struts/struts2-sitemesh-plugin/2.1.8.1/struts2-sitemesh-plugin-2.1.8.1.jar
/org/tmatesoft/svnkit/svnkit/1.7.6/svnkit-1.7.6.jar
/com/trilead/trilead-ssh2/1.0.0-build215/trilead-ssh2-1.0.0-build215.jar
/de/schlichtherle/truezip/truezip-driver-file/7.6/truezip-driver-file-7.6.jar
/de/schlichtherle/truezip/truezip-driver-zip/7.6/truezip-driver-zip-7.6.jar
/de/schlichtherle/truezip/truezip-file/7.6/truezip-file-7.6.jar
/de/schlichtherle/truezip/truezip-kernel/7.6/truezip-kernel-7.6.jar
/de/schlichtherle/truezip/truezip-swing/7.6/truezip-swing-7.6.jar
/org/tuckey/urlrewritefilter/4.0.3/urlrewritefilter-4.0.3.jar
/velocity/velocity/1.4/velocity-1.4.jar
/velocity-tools/velocity-tools/1.2/velocity-tools-1.2.jar
/org/apache/maven/wagon/wagon-file/2.2/wagon-file-2.2.jar
/org/apache/maven/wagon/wagon-http/2.2/wagon-http-2.2.jar
/org/apache/maven/wagon/wagon-http-lightweight/1.0-beta-2/wagon-http-lightweight-1.0-beta-2.jar
/org/apache/maven/wagon/wagon-http-shared/1.0-beta-2/wagon-http-shared-1.0-beta-2.jar
/org/apache/maven/wagon/wagon-http-shared4/2.2/wagon-http-shared4-2.2.jar
/org/apache/maven/wagon/wagon-provider-api/2.2/wagon-provider-api-2.2.jar
/org/apache/maven/wagon/wagon-ssh/1.0-beta-2/wagon-ssh-1.0-beta-2.jar
/org/apache/maven/wagon/wagon-ssh-common/1.0-beta-2/wagon-ssh-common-1.0-beta-2.jar
/org/apache/maven/wagon/wagon-ssh-external/1.0-beta-2/wagon-ssh-external-1.0-beta-2.jar
/com/atlassian/webwork-compat/1.23/webwork-compat-1.23.jar
/org/jvnet/winp/winp/1.17-atlassian1/winp-1.17-atlassian1.jar
/org/codehaus/woodstox/woodstox-core-asl/4.1.2/woodstox-core-asl-4.1.2.jar
/org/apache/xbean/xbean-spring/3.2/xbean-spring-3.2.jar
/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1.jar
/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar
/xmlpull/xmlpull/1.1.3.1/xmlpull-1.1.3.1.jar
/xmlunit/xmlunit/1.3/xmlunit-1.3.jar
/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.jar
/com/thoughtworks/xstream/xstream/1.4.4/xstream-1.4.4.jar
/org/apache/struts/xwork/xwork-core/2.3.15.1-atlassian-7/xwork-core-2.3.15.1-atlassian-7.jar

Bloat everywhere (1)

multimediavt (965608) | about 3 months ago | (#45926285)

Oracle and Java exploits - An anecdote:- A couple of weeks ago I tried to log into my superannuation account, the browser fired back an authentication error, so I notified the company (MLC) who asked me to send them as many technical details as I could. After a little bit of looking around, I noted that the Oracle Access Management system that gave me the error code was was at version (11.1.1.5.0). Oracle's currently version was 11.1.2.1.0. Not too surprising, a supplier that had not patched to the current version.

What did surprise me was that Oracle's Identity Management Patch Set that was available for the version displayed was >2GB - A compressed Java application and framework for a database authentication application that was over 2 Gigabytes in size .

It has been a few years since I wrote any Oracle stuff, but that is ridiculous, what the hell have web based script kiddy/Java type developers been up to. Admittedly I started with Oracle in the Stone Age (V3) and actually shipped an application that used V4. By V6 the C interface which included all the necessary external validation code was small enough to be easily understood and modifiable by a single programmer. My memory is going now, but I seem to remember that in the 1990s all of the code for an early web CGI Oracle interface, including user validation would fit on a floppy.

Why are/were you surprised at the size of the package? I, and many other /.ers remember days when a 30 MB (no kids, that's not a typo) hard disk held dozens of applications, the GUI-based OS, and all our data files. Somewhere along the line APIs, OS frameworks and data files got less compact and then grew as the size of hard drives grew. More features, larger frameworks to accommodate those features and WHAM! you have a 2GB patch set. Sure, I still grumble when I see how big a small application (from a raw code standpoint) turns into a rather large binary, but if the features are needed then we have to just grit our teeth and accept that the underpinnings of those features in the APIs are asymmetric to the amount of text to implement them in the function call. Times they are ever a changin'.

Patch has leaked early (-1)

Anonymous Coward | about 3 months ago | (#45925377)

The patch in full

#!/bin/sh
if [ -e /usr/bin/apt ]; then
apt-get purge sun-java6-jre
elif [ -e /usr/bin/rpm ]; then
rpm -e jre-7u7-linux-x64
fi

# Fix bug #5826106: make sure it's fully patched
rm -f $(which java)

exit 0

Java 6 on Mac (0)

Anonymous Coward | about 3 months ago | (#45925385)

"Java 6 users who use equipment or programs that rely on older versions are SOL unless they sign up for a very expensive support contract, as these patches are for Java 7 only."

Anyone know if that includes Java for Mac OS X? I know Apple rolls Java 6 on Mac, and receives those updates (source) as part of their contract with Oracle.

Re: Java 6 on Mac (0)

Anonymous Coward | about 3 months ago | (#45925471)

Not anymore. These days Java are treated as a virus on OS X.

Re: Java 6 on Mac (2)

IamTheRealMike (537420) | about 3 months ago | (#45925531)

Mac browsers (Chrome, Safari, Firefox) don't run Java applets automatically anyway, so it doesn't matter what version of Java you have installed. Remember these exploits are all getting in because you run malicious code inside a sandbox and the sandbox fails. Don't download and run malicious code and you're OK.

Re: Java 6 on Mac (1)

multimediavt (965608) | about 3 months ago | (#45926315)

Mac browsers (Chrome, Safari, Firefox) don't run Java applets automatically anyway, so it doesn't matter what version of Java you have installed. Remember these exploits are all getting in because you run malicious code inside a sandbox and the sandbox fails. Don't download and run malicious code and you're OK.

Depends on what version of the OS and Java you are running and whether the user has already acknowledged the site as "safe". Weather.gov uses a mix of Java and other tech to display satellite and radar loops, for instance. The local radar loops (Base and Composite) are Java and after one acknowledgement will load without user intervention another time.

right up the ass like the flash plugin (0)

Anonymous Coward | about 3 months ago | (#45925409)

enjoy

Re:right up the ass like the flash plugin (0)

Anonymous Coward | about 3 months ago | (#45925427)

Tell me about my polyps.

only secure personal data is off line and off site (0)

Anonymous Coward | about 3 months ago | (#45925441)

? so the notion of storing (big (farce)) data about ALL of us on (easy to) open servers was already technically & ethically obsolete? are we daft? free the innocent stem cells. never a better time to consider ourselves in relation to our mom based new clear options...

ASK (1)

Arith (708986) | about 3 months ago | (#45925445)

How about that vulnerability where they package crap with the install? I had to clear a few spyware incursions on my father's machine resulting from the crap they stowed in the install including the ask toolbar. I don't care how many actual bugs there are. If you try to slide this shit by regular users like this, I just have zero respect for companies who do that.

it would be good if.... (0)

3seas (184403) | about 3 months ago | (#45925987)

web developers provided alternative site access without JAVA.
Why? Simply because JAVA is a product designed to always have things that need patched.
Its not safe, and never will be.

Re:it would be good if.... (1)

iggymanz (596061) | about 3 months ago | (#45926317)

you think any other language framework also does not have horrendous security issues?

Don't you know? (0)

Anonymous Coward | about 3 months ago | (#45926081)

Don't you know that Java is an exploit by itself, exploited by Oracle?

In related news... (1)

gmuslera (3436) | about 3 months ago | (#45926555)

All those having internet facing java services had remote vulnerabilities known by oracle and the NSA for months (at least if Oracle does the same as Microsoft [techweekeurope.co.uk], something very probable if not worse), and if your internal network had some value for the NSA or people working for it, it is already backdoored.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...