Hello all ... back again ... another well confusing compiler error message i.e. "variable xxxxxxx might not have been initialized"
What, pray tell is meant by "...might not have been initialized.." I've been programming for 31 years now, and a variable is either initialized to some value
or it's not. (and in modern systems the storage set aside for variables is set to 0x00 unless one specifies another value)
I'm trying to define and "initialize" a set of file channels. I'm assumming the FileChannel Constructor does the initialization.
I hope someone can tell me where I'm "going wrong" with this.
This FileControl() method gets called from my "main" method initially to setup the various file-channels the program requires.
Once the program is "running" the FileControl Method gets called to perform reads and writes per the program's overall logic.
All of the case values and the ByteBuffer objects I've defined as members of the class that the "main" method and all the other methods are a part of.
All of my class variables have been defined as static (some final static)
Guy Rich wrote:...in modern systems the storage set aside for variables is set to 0x00 unless one specifies another value...
In Java, that's true of class and instance variables, which receive default values. But for local (method) variables, the programmer is responsible for making sure they're initialized prior to being used.
In your method, it looks like RespChnl is properly initialized only if case is PGR_START.
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Hi Marc, thanks much for your input...
Well what happens in my "main" method is this:
I've coded a series of if ( !file_name.exists()) statements with the result being either ALL files do exist (therefore set pgm_status to PGM_START)
otherwise issue an error message and abend (abort) the program.
Frankly I don't see why the Java compiler should throw this kind of error.
It should simply be a warning.
I don't know what else to do... I mean it would be ridiculous to define the file channels object anew every time I want to do some I/O ....
I've tried defining the file I/O streams within the class declaration for this program, but I get hit with a compiler error because I don't have any I/O exception handling, and the kicker is that I can't use those verbs within the class declaration (get a compiler error on that)
I tried initilizing the channel objects to null in the class declaration, That got past the compiler, but I got a nullpointerexception error at runtime.
If that case is executed, then the PGM_START case will not have been executed. And therefore the RespChnl variable will not have been assigned a value.
You could wish (as you have wished) for local variables to be assigned null if you don't explicitly assign them a value. But even if you got your wish, that line of code would then throw a NullPointerException. In other words, the compiler is trying to help you out with that error message. Don't push it away when it does that.
Actually I don't even see why that variable is local to that method. Surely you're first going to call it with the PGM_START case, which creates a bunch of file-related objects. If you assign them to local variables, then as soon as you exit that method, they're gone. Then when you later call the method with the WRITE_RESP case, there won't be any file-related object you can use. Shouldn't they be declared as class-level objects?
(Which leads on the question of why this is a static method, but one thing at a time...)
Hi Paul, thanks very much for your insightful comments.
The FileChannel objects I do have initially defined with nulls, with the class declaration
Now the FileStream objects are the only objects that are "local" to my understanding...
All other variables I've declared as static members of Class LU62XnsCvr ...
So are you then implying that once I "leave" the FileControl method, the filestream objects "go away"? (or the storage allocated is released in mainframe parlance)
Therefore, the other objects built from the file-stream objects ...such as the channel objects, will be "pointing" to "nothing" upon re-entering FileControl?
So how do I resolve this ??? How do I maintain a "persitent" set of filestream objects during the "life" of LU62XnsCvr ???
I thought that was the purpose of the static modifier ...
Would I have to run a separate Class such as LU62IOCntl to manage the filestream objects, channels & buffers, and pass data thru memory "pipes"
connecting LU62XnsCvr & LU62IOCntl ???
Is this at all feasible ??
Again any comments and/or suggestions are most welcome..
Okay, let's take this code fragment as an example:
It's contained inside a switch-block, so those two variables are local to that block. So when control leaves that block (right after "break" if I'm not mistaken), those two variables cease to exist. And the objects they refer to can now be garbage-collected.
However those two variables aren't used anywhere else in the code, so it's really pointless to assign anything to them. In fact the entire code fragment is pointless, because it does nothing but define two useless variables.
I can't tell what all that code is supposed to do (and to tell you the truth I haven't tried to find out, there's an awful lot of it). And besides you speak Java with such a heavy mainframe accent, it's hard to follow. But as a general rule: if you have a variable which is "permanent" then don't make it a local variable inside some method. If it's only going to be used in one call to a method, then it should be local.
Guy Rich wrote:Therefore, the other objects built from the file-stream objects ...such as the channel objects, will be "pointing" to "nothing" upon re-entering FileControl?
No, you have that backwards. Objects don't point to things. It's variables which "point" (the real word is "refer") to objects. So if you declare a local variable inside a method, you can make it refer to an object. But when control returns from the method, that variable gets popped from the stack and any object it referred to is now nowhere to be seen.
Hello Paul, thank you for the clarification ...and your patience.
Okay, so this variable which is local to the the method gets "popped" from the stack and the object it referenced is no longer accessable.
So is the object(and the "data" it represents) still in the storage allocated to the program ?
Do you have any suggestions as to how best read and write data via these channel objects without losing reference to them ?