The Daily WTF: Curious Perversions in Information Technology

2008-05-02 Reply Admin

The WTF is fine and all, but why hasn't this problem been fixed after the first time it was caught? It's literally copy pasting one line of code into the return value.

real_aardvark · 2008-05-02 Reply Admin

vr602:
"That would be the French. Inventors of mayonaise..."
Mayonaise was invented by the Smashing Pumpkins. Mayonnaise, however, was invented by the Spanish in Port Mahon (mahonese). No sign of the French in either of those.

I pity the fool.

Except that Louis-Francois-Armand du Plessis de Richelieu sounds vaguely French. As does Marie-Antoine Careme. This is even giving you your dubious derivation of the word from Port Mahon. I seem to recall a tale of it being whipped up for Charles de Lorraine before a battle; although apparently it might also be down to Old French 'mayeu,' meaning egg-yolk, or possibly the French verb for blending, 'manier,' which seems to make a lot of sense to me since the sauce is about as bloody simple as you can get, and I use beurre manie as a short-hand fix whenever I need it.

Quite a lot of French there, really. But you go ahead with your fixation on Minorca -- Spanish cuisine needs all the help it can get.

Besides, any fule no that mayonnaise was, in fact, invented by Hellman's, and is thoroughly disgusting.

2008-05-04 Reply Admin

James A. Donald:
Java typically runs ten times slower, and takes up ten times as much memory as C.

Yeah, right. This might've been true years ago. In the meantime - depending on context and usage of course - you can have Java code that runs faster than C code on modern processors.

How can this be, you ask?

The JVM's JIT (Just In Time) compiler can optimize the instruction set for the processor it's running on.

You can't do this for natively compiled code, because you'd risk that your code won't run if not used on the, say, Pentium Dual Core it was compiled for. More likely you'd have to compile for the original Pentium or even in 386 mode to assure backwards compatibility. The only system where this does not hold true is probably Gentoo Linux, where everything is always built from scratch (and optimized for the present processor) :o)

2008-05-04 Reply Admin

Anon:
real_aardvark:
Anon:
Yes, really. One of the reasons you can't get a year from a Date object is because it would return invalid values on certain dates before 1583.
And that would, of course, be so incredibly difficult for standard Java Date classes to handle if they actually took the trouble to understand locales and the Gregorian/Julian calendar and ...
... hmmm.

Excuse me?

If all you've got (which thanks to Unix's brain-dead interpretation of the Multics ideal is all we've got) is "milliseconds since 1970," exactly how do you propose to represent, say, 12:30 PM on January 1st, 1583? Please show us teh Java codez.
I can't figure out WTF you're saying. So I'll just repeat the original point under the assumption that you're trying to suggest I'm defending Sun's overly excessive standard date implementation.

One of the reasons Sun deprecated all the useful methods from the Date class was because it didn't handle dates before 1583 "properly", which is completely braindead. The number of usecases where anyone cares about dates a century old let along half a fucking millennium old are so few that completely altering the API to accommodate them and not common usecase is a complete WTF.

But Sun, in their wisdom, just had to make sure that Java can properly form dates before 1583.

You are from the US and have never been outside them, right?

The most important reason for deprecating the getters of java.util.Date is that more than half of the people living on this planet are not using the gregorian calendar. This is a fact that somehow seems to escape many people, especially when they themselves come from so-called "gods own country"...

The most important reason for deprecating the setters is that Date was originally (and stupidly!) made mutable, despite the fact that it is thought of and used as a value object (i.e. nearly like a primitive value) by most people.

If you do not know why this is a problem (or why e.g. String thankfully is immutable in Java) I recommend the great book "Effective Java" by Josh Bloch.

2008-05-04 Reply Admin

Anon:
Farmie:
I don't disagree with your point, but just to make sure we're clear on this, TEH JAVAS DATE API IS TEH SUQ.
No it isn't. It's just somewhat overly specific.
Date is just a simple, plain old timestamp in milliseconds since 1970. Sun is even kind enough that Date ignores leapseconds, which they explain in several paragraphs complete with references in the Date documentation. A date is just an offset from a known reference time. Simple. It's not a calendar, it's a date.

If you want to be able to translate the Date into meaningful terms, you need a Calendar, which translates the timestamp into things a person might understand. After all, there is more than just the Gregorian Calendar out there. You might be dealing with the Jewish Calendar or the Chinese Calendar or some other calendar.

Just because Java doesn't actually offer any implementation except the Julian and Gregorian Calendars, doesn't mean that it doesn't make some kind of sense, in that liberal "think of the minorities!" sort of way.

(Yes, you can make a GregorianCalendar act like a Julian calendar. The documentation even explains how.)

After all, you should never optimize for the most common usecase. Just because almost everyone had need for dates in the Gregorian calendar doesn't mean you should make it easy to get dates in that format. After all, to do so might be considered insulting to minorities that use different calendars.

(And, yes, this entire thing is sarcastic. Java's date API is moronic. Allowing other calendars makes a sort of sense, but for the love of sanity, don't deprecate and remove easy access to things like the current year!)

If you're talking about read access (i.e. getters) to java.util.Date, you might have a point if not more than half of mankind (your "minorities"!) used other calendars than the gregorian one... and Date was not designed to support other calendar formats.

Anon:
Just because almost everyone had need for dates in the Gregorian calendar...

might be true for you and in this moment (and for a few years to come), but this is very likely to change. You can only pray that the average chinese or indian developers in the future will not be such ignorant blockheads, because otherwise you will have to learn their calendars, because they are "all almost everyone needs"...

The setters of java.util.Date are deprecated for a still better reason: Date (like String for example) should by all means be immutable. And by deprecating the setters it now thankfully is.

2008-05-05 Reply Admin

The proper way to invalidate the cache would be to set a timer to trigger at the change of year. This being Java, you'd naturally do this using another thread, and unavoidably somebody's going to either create one for every call, or forget to reset it for the next year...

2008-05-05 Reply Admin

// this is about as retarded i can make a caching of a integer representing the currentyear. // Sad thing is, I have almost made one of these to optimize an old crappy application. // You can actually use the HttpRuntime cache in a normal winforms app too :p

public static Cache Cache { get { if( HttpRuntime == null ) HttpRuntime = new HttpRuntime(); if( HttpRuntime == null ) return FILE_NOT_FOUND; return HttpRuntime.Cache; } }

private static object _cacheLock = new object(); public static int GetCurrentYear() { object o = Cache.Get("CurrentYear"); if( o == null ) { lock(_cacheLock) { o = Cache.Get("CurrentYear"); if( o == null ) { int currentYear = DateTime.Now.Year; DateTime nextYear = new DateTime(DateTime.Now.Year, 1, 1); Cache.Add("CurrentYear", currentYear, null, nextYear, TimeSpan.Zero, null, null); return currentYear; } } } return o as DateTime; }

2008-05-05 Reply Admin

Goplat:
The real WTF is that the "right" way to get the current year involves an object creation - and since this is Java, there are probably 100 other temporary objects created in the process.

...and all this crap just to get the year from the system date. They could actually open a cmd-window in the background, type in "date" and extract the year from there. That could be quite Javaish WTFery.

2008-05-05 Reply Admin

Grovesy:
anonymous:
Grovesy:
Someone You Know:
Jake Vinson:
According to Wikipedia, caching is a method of storing a collection of data for which the time it takes to compute said data is longer than the time it takes to retrieve from the cache.

That is a very weirdly-constructed sentence.

For some reason, I think while saying that sentance, one should be holding a bottle of rhum, doing a Jack Sparrow impression...

Here in the states, we use the word 'Rum'. Google tells me that 'Rhum' is common in french areas of the world, however.

Here on the internet, we are not all from the states. It is a common spelling in the UK

When will they ever find out that the world doesn't consist solely of The States. WTF!

2008-05-05 Reply Admin

real_aardvark:
On the other hand, Chuck Norris doesn't construct sentences. He just stares at them until the words reassemble themselves into the right order.

I would expect that from Bruce Schneier. But maybe by looking at that sentence the words would just disassemble to make the sentence more secure.

http://geekz.co.uk/schneierfacts/

CAPTCHA: bene - benvenuti in Italia

2008-05-05 Reply Admin

KenW:
Oh, come on! Everybody knows that there wasn't enough government in place back in 1583 to require an operating license for a mere nuclear plant. Anybody could build and run one. My great-great-great-great-great-great-great-great-great-great (somewhere in there) grandfather had a whole chain of nuclear reactors that he started building in 1582; the first one came on line on January 1, 1583.

Not entirely true. While regulation may not have been a problem per se, I believe he ended up avoiding the Spanish Inquisition (who felt that Cerenkov radiation was downright luciferous, even though Cerenkov wasn't born yet.)

He avoided them by booking passage with his equipment on a Portuguese sailing ship, transferring the entire region to Gabon.

However, after a spate of accidents in later years, the entire Oklo facility was abandoned.

2008-05-05 Reply Admin

James A. Donald:
Java typically runs ten times slower, and takes up ten times as much memory as C.

What are you smoking? I mean, you know *of* Python, so if you're a time traveller from 1996 you seem to have at least *somewhat* acclimatized to the current decade...

http://shootout.alioth.debian.org/gp4/benchmark.php?test=spectralnorm&lang=all

2008-05-06 Reply Admin

Google tells me that 'Rhum' is common in french areas of the world, however.

Here on the internet, we are not all from the states. It is a common spelling in the UK

That's probably because people who can't spell are almost as common here in the UK as in the USA. http://en.wikipedia.org/wiki/R%C3%B9m http://en.wikipedia.org/wiki/Rum#Etymology

2008-05-06 Reply Admin

Years ago, whilst working as tech support for a macintosh database system, I had a user who's date/time fields were not working.

It seems she was making a database of tombstones, some of which had dates before Jan 1st, 1900 (or was it 1901?)...

Just as the Y2K bug had to be delt with by banks in 1970, for 30 year mortgage end dates.

2008-05-12 Reply Admin

Anon:
And to think, I thought I had it bad when I worked on a J2EE webapp that on startup cached the entire database into a set of arrays because "database are slow".
I never was able to communicate just how brain dead it was to think that caching the entire database in a Java application would magically be faster at selecting rows than running queries again a natively optimized database running on the same machine.

ROFL! No kidding man. For any decent sized table doing an SQL query to MySQL is FASTER than looking it up in a hash... And 'decent sized' is surprisingly small, like maybe 10k rows.

real_aardvark · 2008-05-12 Reply Admin

Kaenneth:
Years ago, whilst working as tech support for a macintosh database system, I had a user who's date/time fields were not working.
It seems she was making a database of tombstones, some of which had dates before Jan 1st, 1900 (or was it 1901?)...

Just as the Y2K bug had to be delt with by banks in 1970, for 30 year mortgage end dates.

Technically, that isn't a bug.

What it boils down to is moron programmers.

They are common, and should be treated as such.

Peasants! Burn 'em!

2010-04-26 Reply Admin

This is correct. especially in today's dev enviornment. With parallel computing it might be easier to recalculate the value than to to wait for a release of a value used by another core.

2010-07-27 Reply Admin

Three pages, and no one found TRWTF:

Why didn't someone just fix the damn issue?

2014-01-16 Reply Admin

TRWTF is that if it's known that it needs rebooting every 1/1, why does someone spend hours tracking someone down to explain the problem and ask them to reboot? Why isn't there a note in someone's diary (or better yet a chronjob) to reboot ASAP after midnight on New Year's?

Better yet (assuming you want it to cache the year), is there any problem with adding another method to the class?

public class CommonVars {
    private final static CommonVars instance = new CommonVars();
    public static CommonVars getInstance() {
        return instance;
    }
    private CommonVars() {
        setCurrentYear();
    }

    ...
    
    public int setCurrentYear(){
        currentYear = Calendar.getInstance().get(Calendar.YEAR)
    }

    public int getCurrentYear() {
        return currentYear;
    }
    ...
}

Then it surely can't be that difficult to arrange for setCurrentYear() to be called once a year at 01/01 00:00 to fix it without a reboot

The Annual Reboot

Leave a comment on “The Annual Reboot”