Weird Static Issue

java-programmer, Weird Static Issue Please take a look at the following code section. In this module the
static "qt" becomes null when the constuctor is fired, very similar
code works find in other places in my program. I don't think the
QueryTools class is a problem because I can use the code elsewhere.

public class Authorization
{
static public String TABLE ="authorization";
static private String POOL_NAME = "mysql-invoice-system";
static private QueryTools qt;

static
{
System.out.println("Static Section " + POOL_NAME);
QueryTools qt = new QueryTools(POOL_NAME);
System.out.println(qt);
System.out.println("Static Section End " + POOL_NAME);
}

public Authorization()
{
System.out.println("Authorization Constructor");
System.out.println("QT=" + qt);
}

Here is the output from Netbeans:

run:
Static Section mysql-invoice-system
com.ciorent.HFCConnectionPool.QueryTools@18e2b22
Static Section End mysql-invoice-system
Authorization Constructor
QT=null

Here is the calling code:

Authorization a = new Authorization();
try
{
a.createAccount("email***@***.com", "test4200", 10000);
}
catch (Exception e)
{
System.out.println(e);
}
System.exit(1);

I am going to bet this is something simple that I am missing, hopefully
someone will be able to point out my error.

Thanks
HFC

java-programmer >> Weird Static Issue Well, well,

The very same minute I hit post, I saw the error,

static
{
QueryTools qt = new QueryTools();
}

Should be

static
{
qt = new QueryTools();
}

java-programmer >> Weird Static Issue knightowl coughed up:
> Well, well,
>
> The very same minute I hit post, I saw the error,
>
> static
> {
> QueryTools qt = new QueryTools();
> }
>
> Should be
>
> static
> {
> qt = new QueryTools();
> }

It can be very hard to see things like this.

When I've been hit with an bug that I just cannot figure out, I always go
for the mistaken assumption errors. The kind of errors you just hit on.

One of the ways I've discovered actually helps give your code a "new look"
so that you can read it in a fresh light is to, get this, drum roll please,
actually change the font used by your IDE. And if you can shift the
formatting over from newline-bracket to K&R-bracket (or vice versa) it can
help even more.

It's as if there is a pattern recognition circuit that grabs a glimpse of
code its seen over and over, and then feeds to the brain that it is
something that "works". Having it /look/ different forces you to reparse it
again.

YMMV a lot.

--
"So I just, uh... I just cut them up like regular chickens?"
"Sure, just cut them up like regular chickens."

java-programmer >> Weird Static Issue In article <email***@***.com>,
"knightowl" <email***@***.com> wrote:

> Well, well,
>
> The very same minute I hit post, I saw the error,
>
> static
> {
> QueryTools qt = new QueryTools();
> }
>
> Should be
>
> static
> {
> qt = new QueryTools();
> }

Your IDE might be able to warn you about hiding variables from an outer
scope. I find it very valuable in catching stupid yet stealthy mistakes
like that.

java-programmer >> Weird Static Issue knightowl wrote:

> Well, well,
>
> The very same minute I hit post, I saw the error,
>
> static
> {
> QueryTools qt = new QueryTools();
> }
>
> Should be
>
> static
> {
> qt = new QueryTools();
> }
>

It may or may not be relevant to your particular case, but I am more and
more recognizing the value of making class and instance variables
"final" when I don't foresee need for them to be changeable. The
finality can always be removed later, if necessary. With final members
there are more avenues for optimization in JIT, but more importantly,
the compiler (and IDE if you use one) can recognize many problems. In
your particular case, it would have told you that the variable qt was
not initialized.

--
John Bollinger
email***@***.com

java-programmer >> Weird Static Issue John C. Bollinger coughed up:
> knightowl wrote:
>
>> Well, well,
>>
>> The very same minute I hit post, I saw the error,
>>
>> static
>> {
>> QueryTools qt = new QueryTools();
>> }
>>
>> Should be
>>
>> static
>> {
>> qt = new QueryTools();
>> }
>>
>
> It may or may not be relevant to your particular case, but I am more
> and more recognizing the value of making class and instance variables
> "final" when I don't foresee need for them to be changeable. The
> finality can always be removed later, if necessary. With final
> members there are more avenues for optimization in JIT, but more
> importantly, the compiler (and IDE if you use one) can recognize many
> problems. In your particular case, it would have told you that the
> variable qt was not initialized.

That is not a terrible idea, and one that many support, *however* I have
personal trouble with adopting this MO only because of the clutter that
appears with all them "finals" showing up in declarations.

--
Onedoctortoanother:"Ifthisismyrectalthermometer,wherethehell'smypen???"