Comment On The Annual Reboot

I pity the fool who disses the cache.

Truly Mr. T can do it all.....I never knew, why don't people attribute more to him?

"whenever the fist new user session started."

Intentional typo?

Oh well, just 244 days until the next reboot...

Okay, I'm too stupid. One year != 245 days... So what joke/reference am I missing?

Days from now until Jan, 1 2009 maybe?

Confused...:

Oh well, just 244 days until the next reboot...

Okay, I'm too stupid. One year != 245 days... So what joke/reference am I missing?

You said it, not me! :)

As of today, 2008-05-01, it is 244 days until 2008-12-31.

should be a simple fix?

public class CommonVars {
private final static CommonVars instance = new CommonVars();
public static CommonVars getInstance() {
return instance;
}
private CommonVars() {
currentYear = Calendar.getInstance().get(Calendar.YEAR);
}

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

to.. I know this is Java, but I'm going to go a bit c# .net here

public class CommonVars {
private final static CommonVars instance = new CommonVars();

public static CommonVars getInstance()
{
return instance;
}
private CommonVars()
{
}

public int getCurrentYear()
{
return DateTime.Now().Year;
}
}

Saddly though, having had much experience with similar applications with over zelous caching, I know the fix at first seems simple, yet minor alterations like that have the same effect as removing the corner stone of a delapidated house

This is a terrible idea but maybe the poor guy figured the system would be rebooted every night? He's not wrong in thinking that the Java Date/Time API is a horrible nightmare, so I give him points for trying. I often wish it had things like getCurrentYear() and getMidnight() built in, but I guess it's not meant to be.

Around these parts we typically roll our own Date/Time classes that do some mojo on the value returned by System.currentTimeMillis() without having to go through DateFormats and Calendars. *fingers crossed for Java7*

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.

Wow! Caching is a really easy problem to fix if you can throw that whole coherency thing out the window! I think I'm gonna start adding some caches to my project, now!

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.

I pity the fool who disses Jake Vinson.

Mr T

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...

The Real WTF is that the class doesn't appear to declare the "currentYear" member.

also,

public class CurrentYearHolder {
private CurrentYearHolder() {}
public static final int currentYear = Calendar.getInstance().get(Calendar.YEAR);
}

System.out.println("current year: " + CurrentYearHolder.currentYear);

....on second thought maybe its better not to encourage them

Am I the only one that thought that Alex was serious about Mr. T, in as far as the "Mr. T Ate My Balls" meme is concerned (web pages locally cached, etc)

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.

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.

This seems more like CodeSOD material than featured.

Reasonable solution on a highly loaded system.
How often does the year change - rarely and fairly predictably.
How often do you need to calculate the year - on every transaction, many times a second.

Especially since Java probably checks the locale and I8N settings for each data request. Just in case the defn of 'first day of the week' has changed since the last packet arrived.

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

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.

Which all get promptly and quickly removed from the heap about 10 seconds later by the "small GC".

I can't see what's all the fuss about object creation. If you have an object creation phobia, don't use Java. It's like being an airliner pilot and complaining about how high these planes fly.

You're free to use C and then you don't have to deal with all this pesky and mucky object stuff.

An oppressed mass:

Reasonable solution on a highly loaded system.
How often does the year change - rarely and fairly predictably.
How often do you need to calculate the year - on every transaction, many times a second.

Especially since Java probably checks the locale and I8N settings for each data request. Just in case the defn of 'first day of the week' has changed since the last packet arrived.

Then put the value in a config file. A "solution" that requires a reboot is not a good one.

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

Down on the farm, we spell it M O R G A N

suzilou:

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.

I pity the fool who disses Jake Vinson.

Mr T

I couldn't agree more.

Outlaw Programmer:

This is a terrible idea but maybe the poor guy figured the system would be rebooted every night? He's not wrong in thinking that the Java Date/Time API is a horrible nightmare, so I give him points for trying. I often wish it had things like getCurrentYear() and getMidnight() built in, but I guess it's not meant to be.

Around these parts we typically roll our own Date/Time classes that do some mojo on the value returned by System.currentTimeMillis() without having to go through DateFormats and Calendars. *fingers crossed for Java7*

This is something that seems like a bit of a premature optimization (OH NOES TEH JAVAS DATE API IS TEH SUQ!). They say that you've gotta code first, profile, then optimize later in that order. A friend of mine, who isn't a programmer, had an interesting take on that sort of thing. He pointed out that focusing on a task that may be secondary to the task at hand (e.g. creating a caching class for seemingly everything in an application) is just a form of procrastination.

An oppressed mass:

Reasonable solution on a highly loaded system.

No, it isn't. Outrageous stupidity is the proper expression.

No caching is reasonable unless it removes a proven bottleneck. (Or in a generalized form: if it ain't broke, don't fix it.)

And I've never ever seen a system in which the CPU time spent on getting the current year properly caused any kind of performance problems.

Caching in Java? That's what we (ab)use Hibernate for.

lulz.

Patrick:

Outlaw Programmer:

This is a terrible idea but maybe the poor guy figured the system would be rebooted every night? He's not wrong in thinking that the Java Date/Time API is a horrible nightmare, so I give him points for trying. I often wish it had things like getCurrentYear() and getMidnight() built in, but I guess it's not meant to be.

Around these parts we typically roll our own Date/Time classes that do some mojo on the value returned by System.currentTimeMillis() without having to go through DateFormats and Calendars. *fingers crossed for Java7*

This is something that seems like a bit of a premature optimization (OH NOES TEH JAVAS DATE API IS TEH SUQ!). They say that you've gotta code first, profile, then optimize later in that order. A friend of mine, who isn't a programmer, had an interesting take on that sort of thing. He pointed out that focusing on a task that may be secondary to the task at hand (e.g. creating a caching class for seemingly everything in an application) is just a form of procrastination.

I don't disagree with your point, but just to make sure we're clear on this, TEH JAVAS DATE API IS TEH SUQ.

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.

What do you mean that Mr. T didn't invent caching? Don't you know that Mr. T IS the "T" in "I.T."?

"Intelligence is in the controller, never in the network, sucka!"

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!)

Farmie:

Grovesy:

anonymous:

Grovesy:

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

Down on the farm, we spell it M O R G A N

In Trinidad they drink it with coke-ah co-lah.

An oppressed mass:

Reasonable solution on a highly loaded system ... How often do you need to calculate the year - on every transaction, many times a second.

Oh yes you're so right, calculating the current year is soooo complicated! </sarcasm>

I would put money down that doing Calendar.YEAR is faster than calling this WTF code!

Pretty sure this wouldn't be caching, you would be retrieving it on every call.

Grovesy:

should be a simple fix?

public class CommonVars {
private final static CommonVars instance = new CommonVars();
public static CommonVars getInstance() {
return instance;
}
private CommonVars() {
currentYear = Calendar.getInstance().get(Calendar.YEAR);
}

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

to.. I know this is Java, but I'm going to go a bit c# .net here

public class CommonVars {
private final static CommonVars instance = new CommonVars();

public static CommonVars getInstance()
{
return instance;
}
private CommonVars()
{
}

public int getCurrentYear()
{
return DateTime.Now().Year;
}
}

Saddly though, having had much experience with similar applications with over zelous caching, I know the fix at first seems simple, yet minor alterations like that have the same effect as removing the corner stone of a delapidated house

Pretty sure this wouldn't be caching your calling DateTime.Now() every time.

Amen!

Patrick:

This is something that seems like a bit of a premature optimization (OH NOES TEH JAVAS DATE API IS TEH SUQ!). They say that you've gotta code first, profile, then optimize later in that order. A friend of mine, who isn't a programmer, had an interesting take on that sort of thing. He pointed out that focusing on a task that may be secondary to the task at hand (e.g. creating a caching class for seemingly everything in an application) is just a form of procrastination.

For the record, the systems that I work on are designed to be super high performance because they need to handle something like 2000+ requests a second. It's possible (maybe even likely) that this system has similar requirements, given that this guy was so cache crazy.

I'm not try to defend this guy, but as far as WTFs are concerned, not only is this a minor bug, it's easily fixable without even changing their API. The easiest solution was already suggested above (don't bother caching).

No, the real WTF is that the team's solution was to reboot the server every year instead of just applying the simplest refactoring ever needed by a Daily WTF.

Yes the Java date API is a WTF. Use Joda Time instead.

http://joda-time.sourceforge.net/

suzilou:

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.

I pity the fool who disses Jake Vinson.

Mr T

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

Actually, that would be a particularly useful plug-in for an IDE.

On other matters, this is simply the most astonishingly beautiful use of the Singleton Pattern that I've ever seen. Saves a single call into the kernel (400 cycles or so), guarantees that the returned value will eventually be wrong, and is essentially impervious to testing.

Brillant!

Grovesy:

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

EVERYONE ON THE INTERNET IS FROM USA BITCH

BammBamm:

Grovesy:

public int getCurrentYear()
{
return DateTime.Now().Year;
}

Pretty sure this wouldn't be caching your calling DateTime.Now() every time.

Yeah.

public int getCurrentYear() 

{ 

  if (currentYear != DateTime.Now().Year)

    currentYear = DateTime.Now().Year;

  return currentYear;

} 

Vastly better.

duplicity:

Yes the Java date API is a WTF. Use Joda Time instead.

http://joda-time.sourceforge.net/

The client highly frowns upon open source, or any solution that doesn't cost 6-7 figures to purchase and maintain.
Might be able to sneak it in if you call it IBM JodaTime ;)

biziclop:

... No caching is reasonable unless it removes a proven bottleneck. ...

I first read that sentence as if it had a comma after "No".

duplicity:

Yes the Java date API is a WTF. Use Joda Time instead.

http://joda-time.sourceforge.net/

When 2.84012334 x 10^13 milliseconds old you reach, look as good you will not. Hmm!

Spectre:

Yeah.

public int getCurrentYear() 

{ 

  if (currentYear != DateTime.Now().Year)

    currentYear = DateTime.Now().Year;

  return currentYear;

} 

Vastly better.

You're kidding right?

Spectre:

BammBamm:

Grovesy:

public int getCurrentYear()
{
return DateTime.Now().Year;
}

Pretty sure this wouldn't be caching your calling DateTime.Now() every time.

Yeah.

public int getCurrentYear() 

{ 

  if (currentYear != DateTime.Now().Year)

    currentYear = DateTime.Now().Year;

  return currentYear;

} 

Vastly better.

No you're still calling it every time, you have to do it in the constructor which leaves you exactly where WTF started.

The key point is never create a cache without understanding a policy of how that cache is going to be kept coherent with other caches (e.g. in a server farm) and how long the cached data is valid for. If it is valid forever - none of the prerequisites ever change - great! You don't need a removal or refresh policy. Most of the time you do.

Conversely I see people who always want the 'latest' data from the database. The latest data is still a cache. It's just a cache that's a few milliseconds old. As soon as you've retrieved the data, someone else can change it, unless you invoke transaction semantics to stop them.

In addition, many programmers massively overestimate the speed of memory compared to the speed of the processor. Recalculating something can often be quicker than accessing a cached copy of the result on modern systems. See Herb Sutter's presentation Machine Architecture: Things Your Programming Language Never Told You
to understand what the relative speeds and latencies of components in your computer are.

BammBamm:

Spectre:

BammBamm:

Grovesy:

public int getCurrentYear()
{
return DateTime.Now().Year;
}

Pretty sure this wouldn't be caching your calling DateTime.Now() every time.

Yeah.

public int getCurrentYear() 

{ 

  if (currentYear != DateTime.Now().Year)

    currentYear = DateTime.Now().Year;

  return currentYear;

} 

Vastly better.

No you're still calling it every time, you have to do it in the constructor which leaves you exactly where WTF started.

take every post on these comments with a grain or spoon of salt. i'm 99% sure he was joking... i laughed at least.

unless you're joking about not knowing that he was joking... then i'm the fool. unless of course i'm just joking about not knowing that you are joking about not knowing that he was joking. which i'm not, so let me know.

Confused...:

Oh well, just 244 days until the next reboot...

Okay, I'm too stupid. One year != 245 days... So what joke/reference am I missing?

:|

BammBamm:

No you're still calling it every time, you have to do it in the constructor which leaves you exactly where WTF started.

See this.

8=]

duh:

Spectre:

Yeah.

public int getCurrentYear() 

{ 

  if (currentYear != DateTime.Now().Year)

    currentYear = DateTime.Now().Year;

  return currentYear;

} 

Vastly better.

You're kidding right?

I would assume so.

I half expected somebody to write a snippet like this:

public int getCurrentYear() 

{ 

  if (currentYear != DateTime.Now().Year)

    return DateTime.Now().Year;

  else

    return currentYear;

} 

That would get rid of that memory-write-intensive assignment operator.

I'm sure it's possible to make it even more perverse (and yet still plausible) but I'll be damned as to how.