Comment Wow... (Score 1) 316
It's like they didn't even try to come up with a defensible or plausible reason. Reminds me of the old TV commercial parody with Lily Tomlin in it "We're the phone company..."
It's like they didn't even try to come up with a defensible or plausible reason. Reminds me of the old TV commercial parody with Lily Tomlin in it "We're the phone company..."
Bravo to Google and Wikipedia for trying to be transparent about this. The law used seems absurd, and is open for much abuse (think politics, for one).
So much for "Whale Wars" and the gang of the Sea Shepard. Ah well.
Seriously though, laudable as the decision (that would require others to enforce) is, I'm baffled that it took this long (almost 4 years) to make a decision on something that clearly wasn't scientific in nature.
Gears-Plural, more than one Gear-Singular, only one
It has a gear. It does not have gears.
I'm sure you'll now come in asking about reverse.
Wow, so many of you who can't count to two? A gear is useless without ANOTHER gear coupled to it. A single ratio gear driven coupling transmission system requires at least TWO gears to work. One connected to the output. One connected to the input. Those gears are coupled (teeth of one drive the teeth of the other).
Yet there are a dozen posts by transmission and gear experts who seem to think that one free floating gear magically transfers power to someplace without another gear meshed to it. Wow. Just... wow.
That doesn't demonstrate that it's all about the money. Some preachers know that they're selling BS, others actually believe their derp. I think Ham is an emotional thinker, and actually believes the nonsense he spouts.
I don't. He cherry picks too much - especially when confronted with conflicting biblical "evidence" where he either ignores the conflict or cherry picks himself off into a different direction.
Very cool! I wrote a script a long while ago which you might like (or find a use for).
https://web.archive.org/web/20...
It's a next-gen script but could be adapted. It's got good pacing and it's an easy read.
Cool - please contact me via the Facebook link in my sig or via our startreknewvoyages.com website's contact page.
"(including *SUN* libraries that don't work in Java 6/7)"
You know that com.sun.* was never intended to be a stable API, right? You were using private APIs, now complaining that they broke, and blaming Java? That's some misdirected anger IMHO.
I used no such thing. I inherited the code when the company I work for bought another company and their infrastructure.
Cool. It just reminds me of a talk someone gave about a big project in C++ which had a hellish 20 hour build.
It's great stuff. One of the things I am enjoying the most about it is cutting the number of needed interlinking systems and technology down to a bare minimum using methods in one messaging system that everything can connect to (with MQ once again giving the assist where needed). Also wrapping EVERY vendor function from EVERY vendor library I deal with - in the end, with everything compiled with that one new wrapping library, it means all we ever have to do is deploy a new vendor library with an updated wrapper library - instead of changing code across hundreds of projects.
What's your relationship with Star Trek Phase II? It looks like you write a number of articles for them on their site.
One of the producers and the lighting guy (Gaffer). One new episode out this past Dec 31st, and another coming soon (once we manage the daunting task of color correcting from the original raw footage).
And here's more...
...was deprecated in J2SE 5.0. It has been disabled in Java SE 6, and it will be removed in the next release.
There are a lot of those if you step through the Java versions. Most people don't realize it ever. I ran into it first hand.
Either way, I love this job, especially since part of my project is to make sure this gets done correctly (instead of what happened under the previous code owners).
Well dude if you're maintaining an app this complex what do you want? To be baby sat or something? Java is the least awful thing about your situation.
I'm NOT complaining. I love this job - when I am done, this problem will never happen again. I was pointing out that the OP was grossly wrong. That's all. Nothing more. And the ACs comparing what we have to some little dinky web app or 80,000 lines of code (after I spelled out how large this project was) is ridiculous at best.
Actually:
(1) The earlier compiler logs show no errors or warnings (neither does compiling it with the target version of Java).
(2) This seems to indicate all sorts of problems, and doesn't even touch Java 7: http://www.oracle.com/technetwork/java/javase/compatibility-137541.html
(3) Some Java 1.3 and earlier functions that were earlier deprecated have been removed (in Java 7) for security reasons (the reasons they were deprecated to begin with).
I believe your organisation is doing something strange.... You should either pay for Oracle support, and receive bug fixes early, or pay developers who can quickly fix JRE bugs themselves, and that will be still a tiny fraction of your IT budget.
WE didn't create the problem, and we are well versed on fixing it. When the previous code owners had to pay IBM to fix custom code for FileNet (written by a company kicked off the project), it cost half a million. I think you missed the part above where I mentioned we got stuck with this disaster during a purchase of another company and their antiquated infrastructure. Also, what I didn't note was that the project was actually started around 2002 on Java 1.3 and possibly earlier.
That's not been my experience. We've been maintaining a large web app under tomcat with Struts for 12 years and have upgraded from Java 3 though Java 7 without any significant compatibility issues. Basically at the beginning of our release cycle we put in the new Java and the new Tomcat and deploy and get to work....
a large web app - how nice. Half of FileNet is a massive collection of FileNet provided, and previous company modified Java Server apps - not a web app. Much of the underlying server stuff are Java Server apps running across a multitude of servers and Java Application Servers, on various operating systems and very diverse hardware.
Waking up in today's world with a Java 1.4 code base would be one big hangover. Mix in a large helping of early Struts/JSP from the same period and, well, life would suck. Rather then a problem with Java, it's really a code issue; without diligent oversight code gets pretty damn ugly. My day job is dealing with this problem - 10 year old code where 95% of the JSP are made up of Java code instead of tags. Business needs are finally forcing a rewrite. My architecture for the replacement is based on components. Small blocks of code distributed as jars with an expected live of around 2 years. Maybe that''s the lesson Java updates...
I'm looking at a similar method. And since our vendor supplied libraries seem to tend to change, I want to wrap the heck out of those in simple class files that can be easily modified so that I only have a dozen or two files to worry about code changes in, instead of files spread out all over the place, across a variety of projects that all rely on the vendor supplied shitware.
The problem I'm fighting is that we have vendor-supplied applets (SSL VPN stuff, workflow stuff in advertising) that when it runs, explicitly implies Java 6. That may have been a good idea when Java 6 first came out, but now it's a damn nightmare.
Ugh, I feel for you. That's our problem too (except our requirements are Java 1.4 or Java 1.5), and the vendor supplied stuff needs to be replaced with newer versions that require code revisions.
Good luck.
THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE
