We Keep Coding

Overloading java

I have a question about overloading in Java.
I have these functions in a class:
public class DefaultMmfgCustomerFacade extends DefaultCustomerFacade {
private MmfgUserService mmfgUserService;
private MmfgSessionService mmfgSessionService;
private UserProfileConfigurator userProfileConfigurator;
#Override
public void forgottenPassword(final String email) {
Assert.hasText(email, "The field [email] cannot be empty");
final CustomerModel customerModel = (CustomerModel) getMmfgUserService().getUserForEmail(email.toLowerCase(),
null);
// getUserService().getUserForUID(uid.toLowerCase(), CustomerModel.class);
getCustomerAccountService().forgottenPassword(customerModel);
}
public void forgottenPassword(final String email, final String uid) {
Assert.hasText(email, "The field [email] cannot be empty");
Assert.hasText(uid, "The field [uid] cannot be empty");
final CustomerModel customerModel = (CustomerModel) getMmfgUserService().getUserForEmail(email, uid);
// getUserService().getUserForUID(uid.toLowerCase(), CustomerModel.class);
getCustomerAccountService().forgottenPassword(customerModel);
}
}
I would call the forgottenPassword(String, String) function in another class in this way:
getCustomerFacade().forgottenPassword(form.getEmail(), form.getUid());
but I obtain an error at compilation time.
The forgottenPassword(String) function is an #Override. The second function instead is an overload. How I have to call the second function?
Thank you all, but I didn't ever use overloading in Java.

In java if you have two methods with same names but different arguments lists, they are really two different methods. Like if you had two methods with different names. It makes no difference for the compiler. The arguments lists differ => these are two different methods.
In your case you have a base class/interface DefaultCustomerFacade with one method declared in it. You have an implementation DefaultMmfgCustomerFacade that overrides that declared method. When you overload that method in DefaultMmfgCustomerFacade, it will behave the same way as if you added any other method with different name. There's no way for compiler to know that the method is overloaded in the implementation of DefaultCustomerFacade.
So you have two choices:
Overload the method in the base class/interface: just declare both methods in DefaultCustomerFacade.
Use DefaultMmfgCustomerFacade instead of DefaultCustomerFacade as a return type of your getCustomerFacade() method.
The first one is more preferable of course, because you will be able to change the implementation without modifying/recompiling client code. And it's generally a good rule to use interfaces instead of concrete implementations where possible. This will make your code less coupled and easier to maintain.

The problem is that forgottenPassword(String) is a function in DefaultCustomerFacade that you are overriding. To override, you need to match the function signature exactly.
I would suggest choosing a different name for both functions, and have the overriding function call the other one.
eg:
#override forgottenPassword(String) (calls resetPassword)
resetPassword(String)
resetPassword(String, String)

java #Nonnull annotation in a method that returns null

I have a method that gets something from a hashmap, a simplified example (that doesn't make much sense but is good enough for now) is:
private Map<String,String> map = new HashMap<String,String>();
public String get(String key) {
return map.get(key);
}
This method can return a null when an entry doesn't exist for a given key obviously. The thing is, I want to annotate this method with #NonNull (because it is used in a gazillion places and I don't like Intellij spamming me with inspection warnings about producing a NPE and I don't want to turn off that inspection, and I also don't want to check whether the value returned is different than null everywhere I call this method. This is because I always use this method with a bunch of keys that are ALWAYS in the map. So due to the program logic this method is bound to return a #NonNull value.
I am tempted to just annotate it with a #NonNull, but who knows someone may call it with something other than the defined keys somewhere and actually cause a NullPointerException.
What would you do? An assertion sounds tempting to me.. Or would you just change the method to throw a RuntimException ? Or an AssertionError?
Thanks.
Edit:
here's the actual implementation:
/**
* Typesafe heterogeneous container pattern - implementation
*/
public class HandlersMap {
private final Map<Class<? extends TableHandler>, TableHandler> handlers;
public HandlersMap() {
handlers = new HashMap<Class<? extends TableHandler>, TableHandler>();
putHandler(RolesTableHandler.class, new RolesTableHandler());
putHandler(UsersTableHandler.class, new UsersTableHandler());
putHandler(DevicesTableHandler.class, new DevicesTableHandler());
}
private <T extends TableHandler> void putHandler(#NonNull final Class<T> type, #NonNull final T instance) {
handlers.put(type, type.cast(instance));
}
#NonNull
public <T extends TableHandler> T getHandler(#NonNull final Class<T> type) {
assert handlers.get(type) != null;
return type.cast(handlers.get(type));
}
public Collection<TableHandler> values() {
return handlers.values();
}
public int size() {
return handlers.size();
}
public Map<Class<? extends TableHandler>, TableHandler> getMap() {
return this.handlers;
}
}

Annotating with #Nonnull without verifying if the given key exists is definitely the wrong thing to do.
Since you seem to indicate that the given key is expected to exist, this means a missing key is an invalid argument, so checking for this case and throwing an IllegalArgumentException for missing elements would be the proper thing to do.
Alternatively, depending on how your map is initialized, you might want to consider creating an enum for your key values, use an EnumMap instead of a HashMap, and have your get() method take this enum rather than a free-form String. That way, you would have some compile-time checking to ensure proper values are used as well.
Even in that case though, you'd still need to check for existence, just in case the requested enum value is not yet added to the map.

Do we need an interface/contract if we cannot generalize method parameters

I want to create an interface having two methods, say uploadFile and downloadFile. While I only need the implementors to just implement these two methods, I am not sure and want to care about what arguements these methods need to take. I mean, different implementors may ask for different parameters. In that case, should I still go ahead by creating an interface by making the above methods as var-arg methods, like below
boolean uploadFile(Object ... parameters)
OutputStream downloadFile(Object ... parameters)
Or is there even a better approach than this? Is it even right to create an interface if I cannot generalize method parameters? I am only sure about the method names and say return types.

This might be a use case for generics. Consider the following arrangement of classes - here we define an abstract "parameter" type and reference this in the interface. Concrete classes work with a particular parameter set.
abstract class HandlerParams {
}
interface FileHandler<T extends HandlerParams> {
boolean uploadFile(T parameters);
OutputStream downloadFile(T parameters);
}
Example implementations:
class URLParams extends HandlerParams {
// whatever...
}
class URLFileHandler implements FileHandler<URLParams> {
#Override
public boolean uploadFile(URLParams parameters) {
// ...
}
#Override
public OutputStream downloadFile(URLParams parameters) {
// ...
}
}
I must admit, I'm struggling to imagine scenarios where this arrangement would be that helpful. I suppose you could have something that works with file handlers, but it feels a little artificial:
class SomethingThatUsesFileHandlers {
public <T extends HandlerParams> void doSomething(FileHandler<T> handler,
T params) {
handler.downloadFile(params);
}
}

If you have to call with different parameter types / counts based on the implementor's type, you have two common choices:
Generalize parameters themselves into a separate type - This helps you unify interfaces at the cost of static type checking
Forego the interface altogether - If you need static type checking, the choice that you suggest (leaving the interface out) is valid.
Here is how you implement the first approach:
interface HandlerParameters {
void setValue(String mame, Object value);
Object getValue(String name);
String[] getNames();
}
interface UploadDownloadHandler {
boolean uploadFile(HandlerParameters parameters);
OutputStream downloadFile(HandlerParameters parameters);
HandlerParameters makeParameters();
}
The caller can call makeParameters to make an empty parameter block, populate parameter values as needed, and proceed to calling uploadFile or downloadFile.

I think this is still OK as you at least have the uploadFile and downloadFile methods defined in your contract. But it allows too many possibilities because you define Object... as parameters of the two methods. Maybe a better approach is to define a few concrete options for these parameters and stick to them. You can do this through several overloaded versions of these two methods e.g.
boolean uploadFile(File)
or
boolean uploadFile(File...)
or
boolean uploadFile(File[])
and then do the same for the
downloadFile method.

Perhaps You should use generic interface?
public interface XXXX< T > {
boolean uploadFile(T... parameters)
OutputStream downloadFile(T... parameters)
}

Java - Alternatives to forcing subclass to have a static method

I often find I want to do something like this:
class Foo{
public static abstract String getParam();
}
To force a subclasses of Foo to return a parameter.
I know you can't do it and I know why you can't do it but the common alternative of:
class Foo{
public abstract String getParam();
}
Is unsatisfactory because it requires you to have an instance which is not helpful if you just want to know the value of the parameter and instantiating the class is expensive.
I'd be very interested to know of how people get around this without getting into using the "Constant Interface" anti pattern.
EDIT: I'll add some more detail about my specific problem, but this is just the current time when I've wanted to do something like this there are several others from the past.
My subclasses are all data processors and the superclass defines the common code between them which allows them to get the data, parse it and put it where it needs to go.
The processors each require certain parameters which are held in an SQL database. Each processor should be able to provide a list of parameters that it requires and the default values so the configuration database can be validated or initialised to defaults by checking the required parameters for each processor type.
Having it performed in the constructor of the processor is not acceptable because it only needs to be done once per class not once per object instance and should be done at system startup when an instance of each type of class may not yet be needed.

The best you can do here in a static context is something like one of the following:
a. Have a method you specifically look for, but is not part of any contract (and therefore you can't enforce anyone to implement) and look for that at runtime:
public static String getParam() { ... };
try {
Method m = clazz.getDeclaredMethod("getParam");
String param = (String) m.invoke(null);
}
catch (NoSuchMethodException e) {
// handle this error
}
b. Use an annotation, which suffers from the same issue in that you can't force people to put it on their classes.
#Target({TYPE})
#Retention(RUNTIME)
public #interface Param {
String value() default "";
}
#Param("foo")
public class MyClass { ... }
public static String getParam(Class<?> clazz) {
if (clazz.isAnnotationPresent(Param.class)) {
return clazz.getAnnotation(Param.class).value();
}
else {
// what to do if there is no annotation
}
}

I agree - I feel that this is a limitation of Java. Sure, they have made their case about the advantages of not allowing inherited static methods, so I get it, but the fact is I have run into cases where this would be useful. Consider this case:
I have a parent Condition class, and for each of its sub-classes, I want a getName() method that states the class' name. The name of the sub-class will not be the Java's class name, but will be some lower-case text string used for JSON purposes on a web front end. The getName() method will not change per instance, so it is safe to make it static. However, some of the sub-classes of the Condition class will not be allowed to have no-argument constructors - some of them I will need to require that some parameters are defined at instantiation.
I use the Reflections library to get all classes in a package at runtime. Now, I want a list of all the names of each Condition class that is in this package, so I can return it to a web front end for JavaScript parsing. I would go through the effort of just instantiating each class, but as I said, they do not all have no-argument constructors. I have designed the constructors of the sub-classes to throw an IllegalArgumentException if some of the parameters are not correctly defined, so I cannot merely pass in null arguments. This is why I want the getName() method to be static, but required for all sub-classes.
My current workaround is to do the following: In the Condition class (which is abstract), I have defined a method:
public String getName () {
throw new IllegalArugmentException ("Child class did not declare an overridden getName() method using a static getConditionName() method. This must be done in order for the class to be registerred with Condition.getAllConditions()");
}
So in each sub-class, I simply define:
#Override
public String getName () {
return getConditionName ();
}
And then I define a static getConditionName() method for each. This is not quite "forcing" each sub-class to do so, but I do it in a way where if getName() is ever inadvertently called, the programmer is instructed how to fix the problem.

It seems to me you want to solve the wrong problem with the wrong tool. If all subclasses define (can't really say inherit) your static method, you will still be unable to call it painlessly (To call the static method on a class not known at compile time would be via reflection or byte code manipulation).
And if the idea is to have a set of behaviors, why not just use instances that all implement the same interface? An instance with no specific state is cheap in terms of memory and construction time, and if there is no state you can always share one instance (flyweight pattern) for all callers.
If you just need to couple metadata with classes, you can build/use any metadata facility you like, the most basic (by hand) implementation is to use a Map where the class object is the key. If that suits your problem depends on your problem, which you don't really describe in detail.
EDIT: (Structural) Metadata would associate data with classes (thats only one flavor, but probably the more common one). Annotations can be used as very simple metadata facility (annotate the class with a parameter). There are countless other ways (and goals to achieve) to do it, on the complex side are frameworks that provide basically every bit of information designed into an UML model for access at runtime.
But what you describe (processors and parameters in database) is what I christened "set of behaviors". And the argument "parameters need to be loaded once per class" is moot, it completely ignores the idioms that can be used to solve this without needing anything 'static'. Namely, the flyweight pattern (for having only once instance) and lazy initialization (for doing work only once). Combine with factory as needed.

I'm having the same problem over and over again and it's hard for me to understand why Java 8 preferred to implement lambda instead of that.
Anyway, if your subclasses only implement retrieving a few parameters and doing rather simple tasks, you can use enumerations as they are very powerful in Java: you can basically consider it a fixed set of instances of an interface. They can have members, methods, etc. They just can't be instanciated (as they are "pre-instanciated").
public enum Processor {
PROC_IMAGE {
#Override
public String getParam() {
return "image";
}
},
PROC_TEXT {
#Override
public String getParam() {
return "text";
}
}
;
public abstract String getParam();
public boolean doProcessing() {
System.out.println(getParam());
}
}
The nice thing is that you can get all "instances" by calling Processor.values():
for (Processor p : Processorvalues()) {
System.out.println(String.format("Param %s: %s", p.name(), p.getParam()));
p.doProcessing();
}
If the processing is more complex, you can do it in other classes that are instanciated in the enum methods:
#Override
public String getParam() {
return new LookForParam("text").getParam();
}
You can then enrich the enumeration with any new processor you can think of.
The down side is that you can't use it if other people want to create new processors, as it means modifying the source file.

You can use the factory pattern to allow the system to create 'data' instances first, and create 'functional' instances later. The 'data' instances will contain the 'mandatory' getters that you wanted to have static. The 'functional' instances do complex parameter validation and/or expensive construction. Of course the parameter setter in the factory can also so preliminary validation.
public abstract class Processor { /*...*/ }
public interface ProcessorFactory {
String getName(); // The mandatory getter in this example
void setParameter(String parameter, String value);
/** #throws IllegalStateException when parameter validation fails */
Processor construct();
}
public class ProcessorA implements ProcessorFactory {
#Override
public String getName() { return "processor-a"; }
#Override
public void setParameter(String parameter, String value) {
Objects.requireNonNull(parameter, "parameter");
Objects.requireNonNull(value, "value");
switch (parameter) {
case "source": setSource(value); break;
/*...*/
default: throw new IllegalArgumentException("Unknown parameter: " + parameter);
}
}
private void setSource(String value) { /*...*/ }
#Override
public Processor construct() {
return new ProcessorAImpl();
}
// Doesn't have to be an inner class. It's up to you.
private class ProcessorAImpl extends Processor { /*...*/ }
}

Passing a class ("Country.class") as an argument in Java

I'm trying to make a method that takes an argument of Country.class, User.class etc, and returns argument.count().
All the possible classes that I would give to this method extend from Model and have the method count().
My code:
private static long <T> countModel(Model<T> clazz)
{
// there is other important stuff here, which prevents me from
// simply by-passing the method altogether.
return clazz.count();
}
Called by:
renderArgs.put("countryCount", countModel(Country.class));
However this just doesn't work at all.
How do I do this, please?

I think you want to do
private long countModel(Class<? extends Model> clazz) throws SecurityException, NoSuchMethodException, IllegalArgumentException, IllegalAccessException, InvocationTargetException
{
Method countMethod = clazz.getDeclaredMethod("count", null);
return (Long) countMethod.invoke(null, null);
}
Hopefully something like this would work (my reflection skills are not really that good).

Don't fully understand what you are trying to achieve. Did you mean this?
private static long <T> countModel(Model<T> model)
{
return model.count();
}
renderArgs.put("countryCount", countModel(country));
EDIT: If count is a static method, it has nothing to do with model. The static method is not inherited. So all you have to do is to call it directly,
renderArgs.put("countryCount", Country.count());

Clarifying, you want a class (A) that is constrained to have a particular class method (B) and you want to pass that class as an argument to some other method (C) and have that method (C) invoke that class method on that class (A.B())?
The first part, the type constraint, that can't be done. Java's type system just does not work that way.
The second part, passing a class as an argument and invoking a class method on it, that can be done using reflection. This is how to do it, correcting from your code (though you should be more careful with the exceptions than I've been in this).
private static <T extends Model> long countModel(Class<T> clazz) throws Exception
{
return (Long) clazz.getMethod("count").invoke(null);
}
The null is the instance to invoke this on (no instance; it's a class method). The cast to Long is required as the result of invoke() is an Object. The type parameter must go before the result type. And the whole thing can take any class that is a subclass of Model as a parameter; it will just fail at runtime if the count method isn't present. Them's the breaks.
(Also note that if you wanted to pass arguments to count(), you'd have to specify the classes of those arguments to getMethod and the values themselves to invoke, in both cases as subsequent arguments. Both support Java5 variable argument lists.)

In the line
renderArgs.put("countryCount", countModel(Country.class));
you call countModel with a Class<Country>, but you have to call it with an instance of Country like this:
Country country = new Country();
renderArgs.put("countryCount", countModel( country );

In reply to your comment to ZZ Coder; a static method in Java is called in the namespace context of a class, like Model.count() for a static method count() in the class Model, but the method does not become part of Model.class, Model.class is an instance of Class describing the class Model. (I can see where the confusion originates, it would be logical to have a specialised Model.class that includes the static methods, but Java isn't desinged that way.)
Your way out is to use reflection to call the static count() for the class that you pass to your code.

You are not passing an instance of country here, you are passing a Class object:
renderArgs.put("countryCount", countModel(Country.class));
You need to instantiate A model and pass it as an argument:
Model model = new Country();
renderArgs.put("countryCount", countModel(model));
or
Country country = new Country();
renderArgs.put("countryCount", countModel(country));
In this case, Country.class is an object of the Class<Country> type.

You are passing Country.class which is a Class object. How is it a Model object?