Of course not. But that was my point. The OP was wrong. Many headaches - and I was simply using our situation as an example. ;-)

And you guessed correctly. So... IBM WAS, Oracle App Server/WebLogic with IBM Java, and Oracle (pre-Sun purchase) Java - plus good ol Sun Java in the mix. Each (of the first two) to use specific libraries written by FileNet (not IBM - IBM cleaned things up in later releases *after* they bought FileNet) or for OAS. :-/

What part of "we inherited this disaster during a company buy-out" did you miss? Nor are most of the issues not "follow(ing) the guidelines" - some of the Java 1.3/1.4 calls have been totally removed, or revised.

First, as someone else said...

Second, some of Sun's old add on libraries use functions that were deprecated and will no longer compile on Java 7. Not give "warnings" - but won't compile because the calls are no longer in Java 7. I mean really... all you need to do is look at the deprecated functions list and see which have been totally removed (and replaced) to see that the problem is different than what you think.

I HAD forgotten the bugs... until I took on this project. That too has been part of the problem. I remember all too clearly now. :-/

And since the original project actually started in January 2002, a bunch of the code was actually written for Java 1.3 (and then, 3 years later, when the project was complete and in testing, ran on Java 1.4 and eventually a combo of 1.4.2 and 1.5).

LoL, I stand corrected!!! And now, I can't get Monty Python skits outta my head - this is going to make the work day a lot more fun! :-P

(1) Try Java 7 - more breaks there than in 6

(2) 80,000 lines of code is a joke compared to 74 GIGABYTES of code with tons of shared custom and outside vendor libraries, running to interconnect FIVE DOZEN servers running a multitude of server daemons, spread across RHEL, RHAS, RHES, Solaris (multiple versions), CentOS, Windows (multiple versions), on x86/64 and non x86/64 hardware - and those run on multiple Java versions in various Java engines (Sun, Oracle, IBM) and in various Java application servers (WebLogic, WebSphere, Tomcat, Covalent, and more). And since it covers virtually everything (in scope of calls and libraries), both Sun and outside vendor wise, we've run into a lot of deprecated calls - and numerous other issues.

(3) Some of the infrastructure components will need to be "upgraded" onto a new OS - for instance, components of IBM FileNet P8 that used to "run best" on Solaris are now being "upgraded" onto RHEL 7 ("upgraded" is in quotes, because it's an upgrade migration where the actual installed version isn't really being upgraded - its settings and data are being migrated onto the newer FileNet version).

(4) Numerous of the outside libraries (for instance the ancient FileNet libraries that *FileNet* (not IBM) wrote) are not compliant with Java 6 or above (IBM for instance, fixed that in later releases - doesn't help us until the rest of the code is corrected to work with the new libraries and Java 7).

I think comparing a tiny (in comparison) 80,000 line project to the scope of our infrastructure is where and why you're seeing different results. I envy you.

Oh so horrendously neglected. Gigabytes of it. Good news is, me and my team are guaranteed a job for ages to come. ;-)

Bad news is, ugh... bringing gigabytes of inter-related Java code up to snuff is oh so much fun. :-P

It's amazing how they "found" these... I would have thought that computers would make it impossible to "lose" such funds - even with the most simplistic of accounting programs. The more I hear, the more it sounds like something else is going on (like the principles of Mt Gox trying to run off with as many BitCoins as they can). It's like watching a soap opera.

No, they most definitely do NOT. We inherited an infrastructure (from a company we bought) that relies heavily on Java 1.4.2 and Java 1.5 (both on the server end and on the client end). Many of the (entirely internal) apps and servlets will not run in Java 6, much less Java 7. Believe me, we've tried. Too much deprecated stuff (not to mention security keys from Sun that haven't been changed in over half a decade).

We've got a two year long project going on to upgrade everything - but because so many libraries are shared (including *SUN* libraries that don't work in Java 6/7) across hundreds of projects, it's going to be an upgrade nightmare. In total, we have GIGABYTES of code, spread across a pretty large infrastructure (comprised of over a hundred servers and 5 racks of SAN).

Of course, our plans are to ensure that all code is up to snuff so we never run into this again - but we had no choice in this matter, since we neither wrote nor planned the original code bases. But what WE do going forward doesn't resolve what we have to do in order to move forward.

Perhaps you simply haven't done any real Java coding on an Enterprise level? If you had, you'd never had made such a post.

Except, especially with all wheel drive and two to four motors, such is no longer true - as Tesla has proven with motors that aren't particularly large in a car that's considerably heavy compared to its gas counterparts.

The correct statement would have been " the car needed to have a certain minimal acceleration that couldn't be delivered (by GM) by an electric engine (as GM has no interest in doing anything that leads credence to the viability of any electric vehicles." The same would apply to other automakers - but more especially to the EV1 destroying, battery technology suppressing GM.

Considering the size of the vehicle (figure mega-Suburban, extended, if you don't recognize the truck platform mentioned), plenty of battery power could be put into it, and four larger motors (than the ONE motor in the Model S) could also fit - as would Subaru's concept 3 motor (two rear, one front) design. As a matter of fact, with all wheels independently driven via computer, there's also the increase in traction to consider for quick (from stop or slow speed) acceleration.

Anyone who can't see the yellow box with the word "Ad" in it shouldn't be in the Internet. My opinion on this, is that this new method actually makes it far easier to see which ones are ads, since each such result is clearly labeled right at the beginning of the link-out.

The people who would miss this or be confused by it are the same ones who'd already have so many infections on their computer from clicking idiotic things that it's unlikely their browser would even load Google. ;-)

Obviously, if you think that, then the education system failed you.

Sadly, you are only correct if you are equating "the ability to read (anything)" as literacy. There are states where the functionally illiterate rate is staggering. The figures on the DOE sites are very misleading, since they consider the ability to read "basic prose" to indicate "literacy" - when in reality, the "deeper numbers" indicate "21 percent of adults in the U.S. read below a 5th grade level, and 19 percent of high school graduates can't read.". The numbers are even worse if one expects an adult to read at what's considered an adult level - someplace decently over 50%.

The true situation does indeed impact how well society (in this country) works. And we can see that ignorance, lack of education and lack of literacy driving some lunatic policies.

My monthly bill has been going down. Three times in the last year, and, during that same time frame, the services I am provided have increased (either during a drop in my bill, or outside of a drop in my bill where my bill didn't change). But T-Mobile's been pretty good about that.