There are different questions already available related to this error, but none is realted to this specific class i.e BaseEncoding
When i am extending BaseEncoding on my class, I am getting this error,
The constructor BaseEncoding() is not visible
here is the code,
import com.google.common.io.BaseEncoding;
public class TheRace extends BaseEncoding{
public TheRace() {
super();
}
}
from this answer, Constructor not visible
I understand that BaseEncoding() constructor must be expecting some parameters, but when I visit its official documentation, there is no constructor defined.
How can I pass the parameters to solve my issue when there is no parametrized constructor in the BaseEncoding class ?
BaseEncoding isn't meant to be subclassed; its constructor is deliberately made private and not visible outside the class. You're supposed to acquire instances of it using its factory methods like base16().
BaseEncoding is an abstract class. It cannot be instantiated! Therefore defining a constructor isn't necessary (Although possible).
In order to acquire (static) objects of type BaseEncoding, the class does define some factory methods (e.g., BaseEncoding.base16()).
Related
I am creating an interface with many implementing classes and there is an attribute they must all have;
I guess it's better to put that attribute in their interface than writing many constructor lines, but attributes can only be static final and require to be immediately initialized.
public interface Interface{
static final AttrType attribute = new AttrType( *something* );
I have 2 problems: this attribute is a class and its constructor needs some other type parameters not just ints, and also it shouldn't be initialized here, I need all implementing classes of the interface to work on the same instance of AttrType which as i said I won't instantiate in the interface.
So, as I am not expert enough, is there a way to do this in the interface or I should just write a line in every subclass' constructor to put in the one AttrType instance they need?
Java interfaces describe what a class can do, rather than what a class is. Therefore, an interface only describes methods.
You could handle this in a few ways:
Using an interface, you could have a getter for the variable, which would force the implementing classes to have the variable. Something like "public AttrType getAttribute();"
Or you could create a class, probably abstract, which implements the interface and has the variable, and its getter and setter. The subclasses all would inherit this variable and behavior.
Would it be possible to add also a common base class to go with your common interface which all the classes could inherit? Then the common base class constructor could contain the attribute instance. Also you could consider using an abstract class instead of interface.
I'm wondering what is behind the Lint's advice of making the constructor of an abstract class protected?
Non-child classes can't call the constructor of an abstract class (it's not possible). The only classes that can call that constructor are children of the abstract class. Setting the constructor as protected only allows child classes to see the constructor.
Edit: For more information, see this question.
Also, Joop is correct about anonymous implementations (I didn't even know you could do that in Java). However, I have never seen anyone do that.
Seemingly to prevent anonymous implementations:
new AbstractClass() { ... };
I have an abstract superclass with a property that must be set by the subclass for proper operation of instances...
abstract SuperClass {
// this list must be initialized by the subclass
List<? extends SavedSearch> savedSearches;
}
This abstract superclass has methods that operate on the savedSearches but it's up to the subclass to ensure that list is properly initialized.
What's the best way to do this?
It's easy with Java create superclass methods that must be implemented by subclasses, but not properties. I thought about requiring an abstract initSavedSearch method like this in the superclass...
abstract initSavedSearchList();
... but that seemed strange, the subclass implementer is under no obligation to do anything in their method implementation, they could just do nothing.
I know I can code up some runtime checks to make sure the savedSearch list is init'd before running code in the superclass, but I'm hoping for compile-time checks (akin to to abstract methods) not runtime checks.
I saw a C# answer to a similar question which suggests hiding the default (zero-arg) constructor and creating a constructor in the abstract class that requires the list as an arg. That sounds decent for Java, too. But my particular class is a JSF 1.x managed bean. I'm a JSF newbie, but AFAIK there's no easy way to get JSF to call a non-standard constructor for Managed Beans.
Is there a way to do this where I get some compile-time help to ensure that implementing subclasses are properly initializing a superclass property?
Thanks!
Gary
One of the ways is to provide a constructor which takes that as argument.
public abstract class SuperClass {
private List<SavedSearch> savedSearches;
protected SuperClass(List<SavedSearch> savedSearches) {
this.savedSearches = savedSearches;
// You can do additional checks here on null, size(), etc.
}
}
The subclasser is required to invoke that constructor.
public class SubClass extends SuperClass {
public SubClass() {
super(initAndGetSavedSearchesSomehow());
}
}
in other words, can someone explain to me the purpose of this:
Consumer(Producer p) {
producer = p;
}
in the context of:
class Consumer extends Thread {
Producer producer;
Consumer(Producer p) {
producer = p;
}
}
as I understand, it appears to be a method with no signature, or a constructor since it shares the class name, yet it doesn't show up in my IDE as such. Can someone explain what it is and what it does?
Any help would be hugely appreciated.
You are looking at a constructor of class Consumer. The only problem I can see is it is not given a access level (public, private, etc...), so it looks like it will default to package-protected, meaning only classes within the same package can see it.
Consumer(Producer p) { ... } is a constructor for the Consumer class.
You typically see constructors as public, e.g.:
public Consumer(Producer p) { ... }
However, when the public (or any access modifier, e.g. protected, or private) is not specified (for any method or member, including constructors), the constructor is only available to the package the class is declared in.
Have a look at Oracle's tutorial on access control.
Yes, that's a constructor. It may look like a "method with no signature" syntactically (more specifically, a constructor cannot have a return type, but may have access modifiers and of course parameters), but it's really quite different from a method in several ways.
The purpose of a constructor is to create instances (objects) of the class. With some relatively exotic exceptions (cloning and deserialization), every Java object is created by calling a constructor. Every class has at least one constructor, but if none is declared an the superclass has a constructor with no parameters, the compiler implicitly adds a parameterless constructor that does nothing except call the superclass constuctor. Similarly, the first thing any constructor does is call a superclass constructor. Again, this can be implicit if there is a parameterless constructor in the superclass.
As for why constructors don't show up in your ide: it's probably a configuration option. To say more, we'd have to know which IDE that is.
As already mentioned, that is a package protected constructor, i.e. it can only be called from methods of the class itself or other classes in the same package. I'm not sure what benefit that has over the more commonly used protected or private constructors, which prevent a class from being directly instantiated and are commonly used to implement the Singleton pattern.
as for my observation when the class itself is having default access modifier, what is the use of having public methods in it. the java compiler could have stopped using public methods in default class. is there any reason for that?
The non-public class might implement a public interface. This would mean that classes outside of the package could not create an instance of this class or create references of that type, but they would still be able to invoke methods on it if passed an instance.
For example, a public factory class might create an instance of an non-public class in its package and return it.
One reason: if your class implements some interface (or extends some abstract class with abstract public methods), then you may not reduce the visibility of those implemented methods.
It is a beautiful combination of Security and Usability packed in one.
I would mark a Class with default access if I want it to have a, well, package access (so that no other package can use it or better change the code) and marking a method public, I am making the method accessible to all other classes regardless of the package they belong to.
How does that help? A class which is secure enough to perform all the complex code implementation and usable enough to give the output to the user who wants to use it.
How can anyone use that? Well you write code to help them use it by creating a public class which extends this default class. You Instantiate this public Subclass in any package (after importing of-course) and this has all the methods marked public.
You have a class which does your magic which everyone can use without giving anyone else a hint of how you got it done!