0

I'm facing a frustrating problem with static variables in an application I'm debugging (I did not code it myself).

I have a mysql database table called Transits. Transits has a string column (varchar) that holds a date (eventdt) of the format "yyyy/MM/dd HH:mm:ss".

In my corresponding hibernate class I have a Date variable that will store the value of eventdt. Thus when eventdt is read, the code converts it from a string to a Date.

The code uses SimpleDateFormat in order to do the conversion. The programmer used a static variable to hold the format, but unfortunately made a formatting error:

private static DateFormat df = new SimpleDateFormat("yyyy/MM/dd hh:mm:ss");

Leaving it as is, every date stored in the eventdt column that is on the noon hour gets stored in the corresponding Date variable as midnight. Obviously this is undesirable, so I attempted to fix it:

private static DateFormat df = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");

However, the code continues to retain the previous format "yyyy/MM/dd hh:mm:ss".

I have done some reading up on static variables and did everything I could think of to clear it. I recompiled the code, then redeployed (on Glassfish 3.1.1). I restarted Netbeans (7.1.1) and then rebuilt/redeployed again. I cleared the Netbeans caches and repeated the same process. Then I deleted the entire Glassfish install, rebooted, recreated the domains, cleared the cache again, and went through the same rebuild/redeploy.

I also tried changing the code itself. I thought maybe it could be a threading issue, so I changed the variable to static final: 

private static final DateFormat df = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");

Then I changed it so that the static final variable is the format string, and instantiated the DateFormat object in each method where it was needed:

// In class variable block
private static final String DATETIME_FORMAT_PATTERN = "yyyy/MM/dd HH:mm:ss";

// In class methods
DateFormat df = new SimpleDateFormat(DATETIME_FORMAT_PATTERN);

No matter what I've done, the same erroneous format "yyyy/MM/dd hh:mm:ss" is retained.

The only thing I can think of that I've NOT done yet, is remove and reinstall Netbeans. I've read somewhere that updating it helped too. Do I need to go that far in order to clear the old static variable?

I also haven't tried putting the code in a synchronized block or initializing it ThreadSafe (though I'm not even sure threading is the issue here...)

I would appreciate any guidance in the right direction, as I am running out of ideas. Thanks!

Edit: As requested here is code that uses the DateFormat. lpr is another Hibernate object consolidating Transits table and some other needed tables.

    Date activityDate = null;
    try {
        activityDate = df.parse(getEventdt());
        lpr.setActivityDateTime(activityDate);
    } catch (Exception e) {
        logger.warn("Unable to parse " + getEventdt() + " as a date.");
    }
cali-spc
  • 37
  • 2
  • 9
  • I should also add that I tried searching the entire source code for another place where the DateFormat might have been set, but did not find a single other occurrence of the erroneous format. Help would be much appreciated! – cali-spc May 30 '12 at 16:19
  • 2
    How did you check that "*the code continues to retain the previous format "yyyy/MM/dd hh:mm:ss"*"? SimpleDateFormat **is not** thread safe [see this post for example](http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety). – assylias May 30 '12 at 16:22
  • 1
    It's essentially impossible that NetBeans is the issue, that doesn't even make sense. Also be aware that `SDF`s aren't thread-safe, although it depends on the app if that's important--it's not related to the issue you're seeing. – Dave Newton May 30 '12 at 16:23
  • @assylias I checked by running the code through a debugger, setting a breakpoint at the code using the formatter, and checking the value of df. – cali-spc May 30 '12 at 16:34
  • @Dave I'm also aware they're not threadsafe so tried a few workarounds but they don't seem to work. Though, I've not even done a multithreaded test yet. I would imagine that it shouldn't be such a problem if I've only got one thread I'm testing at a time? (I'm not incredibly knowledgeable with threading, I admit.) – cali-spc May 30 '12 at 16:36
  • show us the code that uses the DateFormat? – matt b May 30 '12 at 16:36
  • 2
    @Caliris As I said, the non-thread-safeness of `SDF` is not related to the issue you're seeing. That it's static is almost certainly unrelated. You are either not deploying the code you think you are, or not running the code you think you are. – Dave Newton May 30 '12 at 16:49
  • @DaveNewton, I believe you, but I wish I knew how to fix it. Would it have to do anything with the fact I've not yet committed to version control (svn in my case)? I really wouldn't think so, though. – cali-spc May 30 '12 at 16:54
  • @Caliris Without knowing how you're deploying, it's impossible to say. If your build and/or deploy script pulls from svn, then sure, that could do it. You could disassemble the jar using `javap -verbose` to see if the string is as you expect in the jar, I suppose, then at least you'd know it was something with GF caching or a deployment path issue, or something along those lines. – Dave Newton May 30 '12 at 17:55
  • @DaveNewton My test deployment is through the Netbeans plugin for Glassfish. I'll try some of the command line Java options to examine the jar, thanks! – cali-spc May 30 '12 at 19:42

1 Answers1

3

NetBeans is not likely the culprit. I would guess that the problem lies in deployment, most likely that the jar the static date format is compile to isn't being deployed.

You could also have that jar somewhere in the classpath and it's getting picked up instead of the one you've changed.

Another possibility is that this isn't the date formatter responsible for the date. I would put a breakpoint on the line and see if you hit it. If you do hit it, is it using the right formatting string?

Jim Barrows
  • 3,586
  • 1
  • 23
  • 35
  • I've run the code through the debugger several times and it always comes up with the wrong formatting string. I'm just mystified as to where the string is coming from. I've searched the source code repeatedly for another declaration of the wrong formatter and I keep coming up empty. That's why I was thinking it might have to do with the fact the variable is static. – cali-spc May 30 '12 at 16:26
  • Have you checked for duplicate jar files? – Jim Barrows May 30 '12 at 16:28
  • I accessed the glassfish admin and there's only one jar there. I even tried redeploying it manually (instead of through netbeans) and have the same problem. – cali-spc May 30 '12 at 16:37
  • You're going to have to go looking manually, in the lib directories and and anywhere there is a jar. You're making code changes and not seeing them when you deploy, there's only two reasons for that 1) the original version of the class is on the classpath, keeping the changed one from being seen by the classloader 2)You aren't deploying what you think you're deploying. – Jim Barrows May 30 '12 at 18:55
  • I see what you mean. I'm headed out of the office early today but first thing tomorrow I'll look at the classpath thoroughly. I'm pretty sure you and Dave must have the right of it though. – cali-spc May 30 '12 at 19:45
  • It ended up being a silly mistake. I forgot to compile a component module. However, both your comments and @DaveNewton put me on the right path to figure out the problem. Thank you both! – cali-spc May 31 '12 at 18:33