I have a class U and in the constuctor of the class I call overridable method which is public.
NetBeans warns me: Overridable method call in constructor
However, I don't override the method in my project, since class U has no subclasses..
Is it OK to leave it like this? ....calling overridable method in the constructor in this case?
It is not an error. You can ignore it.
If you want to make the compiler happy, make either method, or the whole class final.
As already mentioned you can 'ignore' the warning.
However you do so at your own risk as bugs can creep in at a later date. The reason for the warning is that the compiler cannot prove that a reference to 'this' will not escape the constructor. Which can lead to bugs, as the object being created has not been fully constructed yet and thus the object can be in an invalid state.
It is a warning, not an error, so you can just leave it like this. If you would publish this code however, someone could extend your class U, override the method and get into a lot of trouble.
Related
I am working on a Java project and want to understand the source code before implementing mine into it. The problem im facing is, how can the source code uses the abstract method from an interface without actually overriding it?
At first, I came to this statement:
DeviceService deviceService = context.deviceService();
It is using 'context' to call the method deviceService(). Then, I went up to see where was 'context' being initialized. Then I found this:
private final LinkDiscoveryContext context;
So, 'context' is a type of LinkDiscoveryContext. But then, 'LinkDiscoveryContext' is actually an interface. and the deviceService() is actually an abstract method without having any concrete definition of how the method should do.
I thought we cannot call the method of an interface unless we override it, but why is it working? I may be lack in developer knowledge in Java, and might have provided not enough information. But if the community has any guessing that could result in this working, please share with me.
Thanks in advance.
The class you mention has the constructor that takes instance of LinkDiscoveryContext as argument. So basically you assign a specific implementation to that field using class constructor.
Look for constructor usages to check where it is called from. Hence you will know from which place(s) does that implementation come.
This question already has answers here:
Why should I call super() in Java?
(5 answers)
Closed 8 years ago.
What's the point in invoking super()-- the constructor of the super class from within a constructor when the super constructor is doing nothing?
Java APIs are doing it-- saw ArrayList for one,
invoking AbstractList's constructor in its own.
protected AbstractList() { }
is the only constructor of AbstractList.
without the super() call, it'll run anyway-- and with have the same effect.
TIA.
With the default superclass constructor, it's simply a matter of style. If you have no call to another constructor at the start of your constructor (either super(...) or this(...)), then the compiler automatically inserts a call to super(). (The only class that's exempt from this rule is java.lang.Object.)
I don't think there is a point. I've seen some IDEs auto-generate code that uses an explicit call to super() when it's not needed. I wish they wouldn't. It's a coding style I don't care for.
Your subclass will call superclass even if you will not call super() in constructor of subclass.
First of all, the call to super constructor is always made, unless you call another constructor with this(). If you don't type super() at beginning of your constructor, the compiler will type it there for you. (I mean it will compile the file as if you would type it there)
Moreover, if you ask why is the super constructor called at all if it does nothing, it is because (one of the reasons) the super class can change and the constructor can do something in the newer version, and without recompiling the subclass, you already call the super constructor.
I don't think there's any practical reason to use it, per se, because you are correct - it gets called automatically if no super() constructor call is made explicitly.
However, I'll play devil's advocate here and say that I like calls to super() simply because it's more clear with respect to how initialization is actually happening. I've found this to be especially true when you have newer Java developers who might be taking over that particular piece of the code after you get done with it - inexperienced developers down the road will be less prone to making incorrect assumptions about how things actually get initialized, and that's usually worth the minor cost of being overly specific.
Would you put the annotation in implementation class methods? Does it serve any purpose? If you mistype or don't have it, it is a compile error anyway.
While it's not required to use this annotation when overriding a method, it helps to prevent errors. If a method marked with #Override fails to correctly override a method in one of its superclasses, the compiler generates an error. Its better to fail fast, catch the error soon rather than later figure out you wrote hashcode() but you meant to write hashCode(). #Override helps in finding the problem sooner rather than later.
Similar questions on SO.
when-do-you-use-javas-override-annotation-and-why?
should-i-add-an-override-annotation-when-implementing-abstract-methods?
Also see this.
It's rather useful. If a method annotated with #Override doesn't really overrides method in a superclass you'll get a compilation error.
For example, if you have a class Foo and you create a method:
#Override
public boolean equals (Foo foo) { ... }
then you'll get compile-time error which will tell you that equals (Foo foo) doesn't override any method in Foo's superclass.
Modern IDEs (like IntelliJ) add this annotation automatically when you use some code-generation features of the IDE.
I assume you are asking about annotating methods which are defined in an implemented interface, or as abstract in a super class. In that case, you are correct that a typo in the method signature will result in a compile error with or without #Override. However, I think the annotation is still helpful to explicitly mark a method as implementing an interface. If the interface ever changes, having #Override annotations on all the implementing methods can help pinpoint which method signatures have changed and need to be updated.
More importantly, as mklhmnn mentioned in his answer, if a method is removed from the interface, the #Override annotation in your implementing class will cause a compile error. Without the annotation, you might not be aware that a method had been removed from the interface, which could lead to subtle bugs.
I don't use it and never had a problem. I don't know why suddenly everybody starts using it (Eclipse? which I don't use either).
Refactoring is not a problem, IDE checks that for you anyway.
#Override may help code readability though, so that it's clear to HUMANS what's going on, not compilers. Although my IDE will also mark override methods graphically, it is not very prominent, but the point remains, this is something tools can do for us automatically.
Marking a method as #Override will produce a compilation error if the API changes so no super method is available any more. Maybe that's the reason.
I think it's also nice to do this as an indication to yourself that the Javadoc is elsewhere, you didn't just forget it.
I have an object that I instantiate - it's quite nifty as it also extends a superclass and does some stuff in the constructor - in fact all the vital parameters and method calls are handled in the constructor.
After this I never call the object again to do something - I don't pass it to any other objects either - after it's instantiated it does it stuff and all is good. Is this the wrong way to do it?
Yes, doing significant work in the constructor is usually a bad idea.
Could you do this through a static method instead? The static method could create an instance of the superclass and then do whatever it needs to. The only problem with this approach would be if the superclass called virtual methods during its constructor, but that's a code smell in itself...
It may be a smell from the superclass, not the subclass.
Why do you need to do that? Is there functionality in the superclass that is publicly accessible only through the constructor? If so then you probably do need to create an instance to access that functionality. But it may be better to hide that behaviour behind a normal method rather than a subclass constructor.
But that's still not as good as fixing the superclass.
There should a purpose for the object to exist. Constructor is only a tool for preparing the object so it can work as needed after creation. If you don't use the object, you don't need to create it either.
Creation of unnecessary objects consumes memory and also makes garbage collector do more work, so you should consider rewriting code (possibly with a static method as it has already been suggested).
When I run static analysis on the following code:
public ExtractDBScripts(String resBundleName)
{
super();
m_mainBundle = ResourceBundle.getBundle(resBundleName);
}
I get the following error:
"JAVA 0058 Constructor 'ExtractDBScripts' calls super()".
What is wrong with calling super() from a constructor?
Probably just that it's completely unnecessary--that is java's default behavior (it will call super for you). You want to use the explicit call to super() if you need to pass a parameter to a non-default constructor.
A static analysis tool will often point out code that does absolutely nothing or is unnecessary to help you reduce clutter. It will also point out a=a; there is nothing wrong with saying a=a; but it's not actually doing anything.
Absolutely nothing wrong with it - although it is implicitly there as the first line of a constructor if you don't declare it yourself (i.e. there's no need to declare it)
I presume the tool you are using is objecting to that line of code because it is not required - if you remove it the compiler will automatically insert it.
See the "Subclass Constructors" section here.
There is nothing wrong with calling super() within a constructor so long as it is the first line in your constructor, so long as you are actually extending a class that has a non private constructor.
If the class you are extending has only one constructor, and it's private then you can't call super().
I would suggest calling super() in your code on purpose, so that it is obvious to other coders what you want to do. It is part of the programming practices where I work and seems to make sense. There may be a way for you to set up the static analysis tool to ignore calls to super() also depending on the software. IntelliJ has annotations for ignoring specific things when it does static analysis.