(yup)

"Cisco, Dell, HP, Fiery," FileNet (pre-IBM), Oracle (pre-Java purchase).

The Java component is just one piece of the puzzle. The system uses (not IBM) FileNet P8 v3.5 which needs to be upgraded to the radically different IBM FileNet P8 5.2 (which resolves the issues of having various Java versions and code likely to be deprecated) across multiple clustered servers duplicated in a Dev environment, a QA environment, the Production environment and the off site Disaster Recovery environment. The new FileNet environment will run on 8 clustered servers.

There are two separate clustered application servers running various components each in 6 different Java Server environments (spanning WebLogic, Covalent, Tomcat and more)

There are also 9 document generation and print servers, 2 business services servers, 5 scanning, indexing, validating servers, multiple fax servers, one big message server (ancient version of MQ), 7 dedicated scan stations with customized scan and release software, five racks of SAN storage (in old EMC2 SANS that are getting decommissioned during this project), 5 additional web interface servers, four dozen client stations that utilize some or all of those, and a collection of miscellaneous servers that provide other functionality. Each of those sets is replicated in (besides the production versions I described) Dev, QA and DR.

Our industry requires a development cycle, a QA testing cycle, and then migration into production AND the disaster recovery location.

Now, to top it off, various non-compliant third party libraries have been replaced with brand new ones for various of the software we use - meaning code changes above and beyond dealing with deprecated stuff in Java. Oh, and switching everything to Oracle Java 7. And switching almost a dozen servers from the no longer supported Solaris to RHEL.

So, yes, two years. Somehow I think a lot of the ACs here have never dealt with a big infrastructure before.

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.