We Keep Coding

Why is subclass field initialized to its default value within super constructor? [duplicate]

I ran into an interesting problem yesterday and while the fix was quite simple, I'm still a bit fuzzy on the "why" of it.
I have a class that has a private member variable that is assigned when it is instantiated, however if it is used in an abstract function that is called by the super class's constructor, the variable does not have a value. The solution to the problem was quite simple, I simply had to declare the variable as static and it was assigned correctly. Some code to illustrate the problem:
class Foo extends BaseClass
{
private final String bar = "fooBar!";
public Foo()
{
super();
}
#Override
public void initialize()
{
System.out.println(bar);
}
}
And the base class:
abstract class BaseClass
{
public BaseClass()
{
initialize();
}
public abstract void initialize();
}
In this example, when we call new Foo(); it will output (null) instead of the expected fooBar!
Since we're instantiated an object of type Foo, should its members not be allocated and assigned prior to calling its (and consequently its super class's) constructor? Is this specified somewhere in the Java language or is it JVM specific?
Thanks for any insight!

The assignment of bar = "fooBar!"; is inlined into the constructor during compile time.
The superclass constructor runs before the subclass constructor, hence it would only be natural that the statement is executed afterwards.
Generally though, it's bad practice to call overridable methods from a constructor.

It is as defined by the Java Language Specification. Changing it to static will almost never be and acceptable solution in real world situation.
See JLS 4.12.5 Initial Values of Variablesand JLS 8.3.2 Initialization of Fields
Overall, it is bad practice to call a non-final method from a constructor. the reason being that it could (and if the method is abstract then definitely does) call method in the class that has not yet been initialized: When new Foo() is executed, the BaseClass initializer (constructor) gets called before the Foo constructor, so Foo.initialize is essentially working on an Object that has not been fully constructed yet.

There's just one thing I would like to add to the accepted answer, because I don't entirely agree with his conclusion.
We've all done this.
class Engine {
public Engine() {
init();
}
void init() {
lockDoors();
releasePressure();
tightenSeatbelts();
launchRocket();
}
...
}
Now the question is, which access modifier should we add to our init() function. Should it be private or protected.
make it private <-- keeps subclasses out
make it protected <-- allows subclasses in
Before you make a choice
Now first of all, you should realize that (almost) all code in the Engine class can be replaced by a subclass.
code in a public function, can easily be overridden
code in a protected function, can easily be overridden
code in a private function, can be replaced by overriding all methods that call it.
Well, there is just one exception:
you can never modify the code of a constructor
you can never avoid a private method being called from the constructor of a super class.
(and of course, you cannot replace a final method)
Protected init() - the wrong way
Let's say the init() method is protected there is indeed a pitfall. It is tempting to override it to add features as follows. That would indeed be a mistake.
class SubEngine extends Engine {
int screws = 5;
void init() {
tightenScrews();
super.init();
}
void tightenScrews() {
// this won't print 5, but it will print 0.
System.out.println("tightening " + screws + " screws");
}
}
Protected init() - the right way
So, basically, you should just disable the parents code and postpone execution to your own constructor instead.
class SubEngine extends Engine {
int screws = 5;
public SubEngine() {
initSubEngine();
}
void init() {
// disable parent code
}
void initSubEngine() {
tightenScrews();
super.init();
}
void tightenScrews() {
// this will print 5 as expected
System.out.println("tightening " + screws + " screws");
}
}
Private init() - you may need a phonecall
Now, what if the init() method is private ?
Like mentioned above, there is no way to disable the code of a parent constructor. And if init() is private you simply cannot disable it.
You'll end up copying the entire Engine class, perhaps just to add 1 line of code.
And that may not be the end of it. Even after copying your class, your copied object won't be an Engine meaning that you won't be able to use your EngineUtil#inspectEngine(Engine engine) function.
Perhaps somebody knew this in advance and made an IEngine interface. Then you can get away with it.
In practice it means you'll have to take your phone, and call to that other department that made the Engine class, and ask them to change their code a little to take away some restrictions.
Intelligent design
There is another way. Constructors are for setting variables. They shouldn't activate anything. Everytime you see a class creating a new Thread from their constructor (or through a private method) that should be a red flag.
class Engine {
public Engine() {
}
public void init() {
lockDoors();
releasePressure();
tightenSeatbelts();
launchRocket();
}
// and you probably also want one of these
public void shutdown() { ... }
...
}
Intention
Of course, your intention may very well be not to open up your code. Perhaps you really don't want to allow others to extend your classes. There certainly can be cases where you want to lock people out.
Be aware that it will also make it harder to write tests for your code.
Anyway that's a different scenario.

Polymorphism with Static Methods

I'm creating a Mario clone where everything on the screen is an instance of ScreenElement. A ScreenElement is Landable if it can be landed on by Mario.
public class ScreenElement {
public boolean isLandable() {
return false;
}
}
Some classes override isLandable, for example:
public class GrassBlock extends ScreenElement {
#Override
public boolean isLandable() {
return true;
}
}
And classes that don't override isLandable should inherit it from the closest super class that does. That is to say, I need polymorphism.
Now this all works fine as long as isLandable is an instance method. However whether or not a given ScreenElement is Landable depends on the class, not the instance. So isLandable should really be static. But if I make it static, I cannot override it or inherit in sub classes that don't explicitly define it. Is there a simple workaround to this problem.
EDIT:
I do realize that the way I have it set up right now, it is working correctly but the reason I am bringing this up is because I have encountered a problem. Given a class that extends ScreenElement, I need to find out the result of isLandable. The only thing I could think of was this:
private <S extends ScreenElement> boolean isThisLandable(Class<S> category) {
return category.newInstance().isLandable();
}
I have to create a new instance to figure out something that doesn't depend on the instance, and this seems unnatural.
EDIT 2: Here's the specific piece of code that I'm dealing with.
private <S extends ScreenElement> S getGenericScreenElement(Mario mario, Class<S> category) {
for (ScreenElement element : screenElements) {
if (category.isInstance(element)) {
S elementToTest = category.cast(element);
if (elementToTest.isLandable()) {
//return elementToTest if it matches additional criteria
}
}
}
return null;
}

You're overthinking this.
In a nutshell, this code is doing exactly what you want it to do.
Here's what happens.
Your parent class, ScreenElement, defines by the isLandable() method by default, and it is always set to return false. By creating a new class that is a ScreenElement, if they wish to change this behavior, they must override that method to do so.
The fact that your GrassBlock does override this method is indicative that any instance of a GrassBlock will register true if its isLandable() property is checked.
With your code revision, you're still overthinking this.
All you need to do when you attempt to use an instance of ScreenElement - be that an instance of ScreenElement or any of its children - is to just call the method.
You shouldn't care about that property until you decide to check it, during its run. The way you're checking it now makes very little sense at all.
As an example:
ScreenElement vanillaElement = new ScreenElement();
GrassBlock block = new GrassBlock();
System.out.println(vanillaElement.isLandable()); // will print false
System.out.println(block.isLandable()); // will print true
More explicitly, with your sample code, you can greatly reduce it. Many of your statements to check against the type are unnecessary, especially when casting. You're guaranteed to have nothing more than a ScreenElement, and since isLandable() is defined on at least that, you will never run into a scenario in which you cannot call that method.
The above will turn your code into this. I leave the addition of your Mario parameter up to you since its purpose is unclear in this method.
private ScreenElement getGenericScreenElement(Mario mario) {
for (ScreenElement element : screenElements) {
if (element.isLandable()) {
//return element if it matches additional criteria
}
}
return null;
}

The fact that you need the methods to be overrideable and you want to do polymorphic dispatching means that they should not be static methods.
However whether or not a given ScreenElement is Landable depends on the class, not the instance.
So make the methods instance methods without using the instance state.

Questions on classes extending from a base class (Java)

I'm a beginner in Java trying to write a system of party quests for a game that I'm currently writing and I have a few questions I'd like to be answered. I've already gone around and asked other people, but they're not familiar in Java.
In the past I'd tried making a bunch of classes and accessing them with multiple get methods. I found that incredibly tedious to write and thought I could unify them under an abstract class/implemented class. Thus, the code looked more like this ...
DynastyPQInterface pq = new CustomPQ // or ....
DynastyPQInterface pq = new OtherCustomPQ
Of course, this presented difficulties such as being only able to use implemented methods. It didn't allow me to access the class' exclusive methods that I might want to use later on.
Ultimately, what I want to do is to be able to use a single get method to return any of these derived classes, but still retain the ability to just universally use the get method to call methods that they have in common, such as execute, create, end, while simultaneously allowing me to reach out to their exclusive methods specifically. Is there a way to do that, or is it impossible?
If it's still not clear ...
The code I have write now is a base class that is extended to the other classes in the manner ...
DynastyPQ (base) -> methods include (run(), execute(), end())
CustomAPQ (inherited from DynastyPQ) -> (has exclusive methods like getPoints())
CustomBPQ (inherited from DynastyPQ) -> (has exclusive methods like revivePlayer())
I want to write a get method so to rid myself of multiple. What I have right now is ...
DynastyPQ dynastyPQ;
DynastyPQ getPQ() {
return dynastyPQ;
}
void setPQ(DynastyPQ pq) {
dynastyPQ = pq;
}
Doing this ...
DynastyPQ pq = new CarnivalPQ();
I can only access DynastyPQ's methods rather than Carnival's methods.
Is there a way to access the exclusive methods while universally being able to execute the four base functions without regard to the type of class, or did I miss something earlier?
tl;dr -> I want one get method that universally returns all classes that inherit from class X; however, I want to be able to access each class's exclusive methods.

You can probably just cast the object to the derived class:
DynastyPQ pq = new CustomAPQ();
((CustomAPQ)pq).customAPQmethod();
If you don't know what is the dynamic type (the type you used after the new operator), you can use the instanceof keyword:
DynastyPQ pq = getPQ();
if (pq instanceof CustomAPQ) {
CustomAPQ a = (CustomAPQ)pq;
a.customAPQmethod();
} else if (pq instanceof CustomBPQ) {
CustomBPQ b = (CustomBPQ)pq;
b.customBPQmethod();
} else {
// Neither a CustomAPQ nor a CustomBPQ.
}
If you don't want to do that, you can use polymorphism:
class DynastyPQ {
final void run() {
// code.
}
final void execute() {
// code.
}
final void create() {
// code.
}
void specific1() {}
void specific2() {}
}
class CustomAPQ extends DynastyPQ {
#Override
void specific1() {
// do stuff specific to CustomAPQ.
}
#Override
void specific2() {
// do stuff specific to CustomAPQ.
}
}
class CustomBPQ extends DynastyPQ {
#Override
void specific1() {
// do stuff specific to CustomBPQ.
}
#Override
void specific2() {
// do stuff specific to CustomBPQ.
}
}
Now, you can do:
DynastyPQ pq = new CustomAPQ();
pq.specific1();
The called method will be CustomAPQ::specific1(). If specific1() was not declared in CustomAPQ, then, it will just do nothing.

Other than #CelineNOEL suggested it is not possible. Because you declared a class of type DynastyPQ, you can call only methods defined inside that class. In the moment you want to call specific method, not shared one, you know from which class it is and you can use casting to call that specific method.
((CustomAPQ)pq).customAPQmethod()
Shared methods you are using in code, when you don't know which class should execute same peace of code(or you want it to execute it different if you override share methods in every sub-class), and you delegate it to be resolved in runtime. So reconsider your design and in base class put methods that needs to be called dynamically. All other methods you are sure are specific for one class put only in that class. On that way your code will be cleaner and you will not mess thing that should be separated.

How to have a public void method that must be run at least once

Suppose I have a class ClassA whose getters and setters I use multiple times in my program. Suppose at the end of the program it is critical that I run the public void checkErrors() within the instance of ClassA that I've been working with, which will throw an exception or log an error if there is an error.
Is there a way I can set up ClassA that will throw a RuntimeException if checkErrors() isn't called at least once by the main method?
For example, hoping that you have an imagination, it would be good to have a method like: public compulsory void checkErrors() where compulsory means it must be run once by the main method.
This is an event driven programming context.
In my problem, the instance of ClassA might be needed for a few calculations then not needed any more (with the state of the class, resulting from various internal calculations and setters, being used in other parts of the program). Thus, at the end of the instance's life in the program, I would like to checkErrors() before continuing the program (thus stopping error propagation to later stages of the program).
This compulsory thing would just be to stop the error on behalf of the programmer to call this method at least once.

I want make it compulsory for the main method to checkErrors() on ClassA before ClassB uses ClassA's state in an event driven programming case.
Then you shouldn't design the program this way. Instead, you should introduce a class ValidState and pass an instance of this class to ClassB. And ClassA should have a method
ValidState produceValidState() throws IllegalStateException
which would check for errors and, if none, produce the valid state.
That way, it's completely impossible for the main method to pass invalid state to ClassB. It has to ask ClassA to check for errors in order to get the valid state that ClassB needs to work.

What you are requesting goes against the principle of object oriented programming, as individual classes should encapsulate specific behaviour, without having to be concerned with the flow of the whole program. The class itself shouldn't be aware, that something was supposed to happen with it, it should have been instantiated, etc., this should be monitored outside of the class, in the main flow.
Therefore if you need to do this badly, you can add a counter to ClassA that counts, how many times something was performed and then check this counter in the main.

Sure what you are talking about is the validity of the data in your class. At some point the data is valid. So you need to check the validity of your data every time it is changed and maintain the state of this validity.
private boolean isValid;
public void setSomeData() {
// set it
checkIfErrors();
}
public Data getSomeData() {
if (isValid) {
return someData;
} else {
throw new DataIsInvalidException();
}
}
private void checkIfErrors() {
if (isOk) {
isValid = true;
}
}

There's no certain way to guarantee that an object's method is called after it's constructed. You can, however, require that a method be called before another method; this pattern can be used to enforce a "lifecycle", for example.
boolean errorChecked = false;
public void checkForErrors() {
// do stuff and throw exception if there's a problem
errorChecked = true;
}
public void doSomething() {
if(!errorChecked)
throw new IllegalStateException("must call checkForErrors() first");
...
}

While this paradigm is not really suited for the purposes you are seeking, you could try something like this.
Create a class Monitor:
public class Monitor{
private static ArrayList<Object> checkList;
public static void addToList(Object a){ // implementation }
public static void removeFromList(Object a){ // implementation }
}
This class could have a timer thread that checks its contents every so often. Then you can build right into the class you need checked:
public class ClassA{
public ClassA(){
Monitor.addToList(this);
...
}
public void checkErrors(){
Monitor.removeFromList(this);
...
}
}
So all the timer needs to do is look at the list every so often and see if any of the objects in it are null. If one is null, something was freed without a call to checkErrors(), and you can throw your exception.

How to hide a public method?

I have a method in my static state machine that is only used once when my application is first fired up. The method needs to be public, but I still want it hidden. Is there a way to use an annotation or something that will hide the method from the rest of the project?

You cannot make a public method hidden (unless you can declare it private). You can however put in a subclass and only let the users of the object know the type of the superclass, that is:
class A {
//Externally visible members
}
class B extends A {
//Secret public members
}
Then you instantiate the class B, but only let the type A be known to others...

Once you declare public method it becomes part of your class's contract. You can't hide it because all class users will expect this method to be available.

You could use package level instead of public. That way it can only be called by your application.

If a method is public, it can't be hidden. What you may really be looking for is just a way to restrict access to calling a method. There are other ways to achieve a similar effect.
If there are some things that your state machine does that are "only used once when my application is first fired up" it sounds a lot like those are things that could happen in the constructor. Although it depends on how complex those tasks are, you may not want to do that at construction time.
Since you said your state machine is static, is it also a Singleton? You could maybe use the Singleton Pattern.
public class SimpleStateMachine {
private static SimpleStateMachine instance = new SimpleStateMachine();
private SimpleStateMachine() {
super();
System.out.println("Welcome to the machine"); // prints 1st
}
public static SimpleStateMachine getInstance() {
return instance;
}
public void doUsefulThings() {
System.out.println("Doing useful things"); // prints 3rd
}
}
Here's some code for a client of this Singleton:
public class MachineCaller {
static SimpleStateMachine machine = SimpleStateMachine.getInstance();
public static void main(String... args) {
System.out.println("Start at the very beginning"); // prints 2nd
machine.doUsefulThings();
}
}
Note that the SimpleStateMachine instance isn't built until the first time your class is accessed. Because it's declared as static in the MachineCaller client, that counts as a "first access" and creates the instance. Keep this tidbit in mind if you definitely want your state machine to perform some of those initialization tasks at the time your application starts up.
So, if you don't want to turn your state machine class into a true singleton... you can use a static initialization block do your one-time tasks the first time the class is accessed. That would look something like this:
public class SimpleStateMachine {
static {
System.out.println("First time tasks #1");
System.out.println("First time tasks #2");
}
public SimpleStateMachine() {
super();
System.out.println("Welcome to the machine");
}
public void doUsefulThings() {
System.out.println("Doing useful things");
}
}
While we're at it, since you mentioned that it's a state machine... the Head First Design Patterns book does a nice, easily understandable treatment of the State Pattern. I recommend reading it if you haven't already.

The idiomatic approach to doing this is to use interfaces to limit the visibility of your methods.
For example, say you have the following class:
public class MyClass {
public void method1() {
// ...
}
public void method2() {
// ...
}
}
If you want to limit some parts of the project to only see method1(), then what you do is describe it in an interface, and have the class implement that interface:
public interface Method1Interface {
public void method1();
}
...
public class MyClass implements Method1Interface {
public void method1() {
// ...
}
public void method2() {
// ...
}
}
Then, you can limit the visibility of the methods by choosing to pass the class around either as a MyClass reference, or as a Method1Interface reference:
public class OtherClass {
public void otherMethod1(MyClass obj) {
// can access both obj.method1() and obj.method2()
}
public void otherMethod2(Method1Interface obj) {
// can only access obj.method1(), obj.method2() is hidden.
}
}
A bonus of this approach is that it can also be easily extended. Say, for example, you now also want to independently control access to method2(). All you need do is create a new Method2Interface along the same lines as Method1Interface, and have MyClass implement it. Then, you can control access to method2() in exactly the same manner as method1().
This is a similar approach to that advocated in #MathiasSchwarz's answer, but is much more flexible:
The independent access control described in the preceding paragraph isn't possible with Mathias' technique, due to Java not supporting multiple inheritance.
Not requiring an inheritance relationship also allows more flexibility in designing the class hierarchy.
The only change required to the original class is to add implements Method1Interface, which means that it is a very low-impact refactor since existing users of MyClass don't have to be changed at all (at least, until the choice is made to change them to use Method1Interface).

An alternative solution: You can make it private and create a invokeHiddenMethod(String methodName, Object ... args) method using reflection.

You said that your public method is used only once when the application is started up.
Perhaps you could leave the method public, but make it do nothing after the first call?

There is a (non-)keyword level package level visibility. Instead of public, protected, or private, you use nothing.
This would make the method or class visible to the class and others in the package, but would give you a certain modicum of privacy. You may want to look at What is the use of package level protection in java?.

Hmm... You want a private method, but want to access it outside?
Try do this with reflection.
http://download.oracle.com/javase/tutorial/reflect/index.html

I have seen many Java programmers do something like this:
public static void main(String args[]) {
new MyClass();
}
So basically they create just one object of the class. If there is a method which should run only once, I guess this approach can achieve that. Your method will be called from inside the constructor. But since I don't know how your app works, what are the constraints, so it is just a thought.