Troy Travis

Greenhorn
+ Follow
since Jun 15, 2009
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Troy Travis

I thought I would add the de-compiled class files to prove my claim:

Here is the generated class file with null explicitly set (example 1, above), more specifically I show the constructor:
Note lines 5 and 10.


, and here is the generated class file with null NOT explicitly set (example 2, above), more specifically I show the constructor:
Note that the null assignment DOES NOT occur in the constructor as it does above, which is the reason why the values do not get overridden and hence no null-pointer!!!


14 years ago
Ernest Friedman-Hill is exactly right. Here's an example and a little explanation:

You can't just willy-nilly do anything in Java because it 'looks good' - aside from formatting of course - and even certain ways of formatting can have an effect on code initialization, such as ordering of class/instance variables and static initialization blocks.

Here is an example where understanding what actually happens when an instance variable is explicitly initialized to null will cause a null-pointer to occur even though it is initialized to a non-null value in an implemented abstract method that is called by the super constructor.

In the following example, the abstract class has one abstract method, doConcreteStuff1, that is intended to be invoked in the constructor of the same class: concrete classes need only implement doConcreteStuff1(). Here we have explicitly set instance variables 'one' and 'two' to null and we initialize them in the implemented doConcreteStuff() method.


What do you think will happen when the code is executed?

When the code is executed the following occurs:

B:One is one
B:Two is two
Exception in thread "main" java.lang.NullPointerException
at base.InstanceVarNull$ConcreteInstanceVarNull.<init>(InstanceVarNull.java:16)
at base.InstanceVarNull.main(InstanceVarNull.java:28)

UGhhh!! A null-pointer!!!

Is that what you expected? After all, we did initialize them to non-null values, but it appears that they were overwritten back to null! What gives?

Let's demonstrate another example. I'll remove the explicit null initialization from the instance variables.


What do you think will happen this time when the new code is executed?

When the code is executed the following occurs:

B:One is one
B:Two is two
A:One is one
A:Two is two

No null-pointer!!!

The question here is, why?

As Ernest Friedman-Hill stated above, by explicitly assigning null to the instance variables (in example 1), the compiler will insert the assignment in the constructor of the concrete class and due to the order of operations, doConcreteStuff1() will indeed get executed BEFORE this assignment. So we will see 2 statements being printed, but after that the concrete class will then initialize and re-assign those variables to null.

However, in the second example, we DO NOT explicitly assign null to the instance variables and the compiler does not assign them as null in the constructor. So when we execute example 2, the only assignment for those variables occurs in the doConcreteStuff1() method, and we have NO null-pointers.

Check out the byte-code of each example if you don't believe me.

Cheers and happy coding!
14 years ago
I know this is an old thread, but here is how I am implementing MVC.

Since I have a client-remote, client-local, and server, I have 3 controllers with an appropriately designed hierarchy.
Views contain no business logic aside from what is needed to manipulate the GUI: the views are merely the components that are displayed.
The models back the views. Whatever data I need to propagate around the client is stored in the model. So, if any text field is updated or row is selected, or if a result set is returned from a search, these values are stored in the appropriate model.

All views instantiate their own models, but not all views have an associated model. For instance, I have a status bar whose displayable data is pushed to it from various view and controller events.

Each view and model is registered on the controller.
When an event occurs from a view, the event with appropriate data is sent to the controller and the controller notifies each registered model via reflection. If, a model is interested in listening to a particular event from a view it will be invoked. Once the model changes, all other views that are interested in the change will update accordingly.

For example, when I press 'search' on my search view, it invokes the controller. The controller, since it contains all the business components, will query the database (locally or remotely.) Upon returning with the results a Vector<E> is sent to the appropriate model, the model then passes the data to the search results view and updates the table: the model also passes the results to the status bar view and it updates it's status for number of records returned.

The controller, can also initiate an update to view components when it sees fit. If for example the network is inaccessible, it will push this information to the status bar, and disable the CSR main screen for all user inputs.

Hopes this helps someone.