Is there some way of using magic methods in Java like there is in PHP with __call?
For instance:
class foo {
#Setter #Getter
int id;
#Getter
Map <String, ClassInFoo> myMap;
protected class ClassInFoo {
#Setter #Getter
String name;
}
#Setter
String defaultKey;
}
I'm using Project Lombok annotations for getter and setter methods to simplify the code.
Let's consider that that my map contains several items mapped by String and the defaultKey defines the default one.
What I would like is to be able to call foo.getName() which would return the default name as foo.myMap.get(defaultKey).getName().
The reason I can't just write all the getters manually is that the Foo class is in fact inherited with generics and the the inner class might be different.
I sort of need something like:
function Object __call(method) {
if (exist_method(this.method)
return this.method();
else
return this.myMap.get(defaultKey).method();
}
Is this somehow possible in Java?
EDIT:
I made a more precise example of what I am trying to achieve here: https://gist.github.com/1864457
The only reason of doing this is to "shorthand" the methods in the inner class.
You absolutely can through reflection by using its features like
public Method getMethod(String name, Class<?>... parameterTypes)
that can be used to see if a class has some methods defined but I don't see how your problem couldn't be solved with a proper use of interfaces, inheritance and overriding of methods
Features like reflection are provided to manage certain, otherwise unsolvable, issues but Java is not PHP so you should try to avoid using it when possible, since it's not in the philosophy of the language.
Isn't it the whole point of inheritance and overriding?
Base class:
public Object foo() {
return this.myMap.get(defaultKey).method();
}
Subclass:
#Overrides
public Object foo() {
return whateverIWant;
}
Related
We're trying to figure out a robust way of persisting enums using JPA. The common approach of using #Enumerated is not desirable, because it's too easy to break the mappings when refactoring. Each enum should have a separate database value that can be different than the enum name/order, so that you can safely change the name or internal ordering (e.g. the ordinal values) of the enum without breaking anything. E.g. this blog post has an example on how to achieve this, but we feel the suggested solution adds too much clutter to the code. We'd like to achieve a similar result by using the new AttributeConverter mechanism introduced in JPA 2.1. We have an interface that each enum should implement that defines a method for getting the value that is used to store the enum in the database. Example:
public interface PersistableEnum {
String getDatabaseValue();
}
...
public enum SomeEnum implements PersistableEnum {
FOO("foo"), BAR("bar");
private String databaseValue;
private SomeEnum(String databaseValue) {
this.databaseValue = databaseValue;
}
public void getDatabaseValue() {
return databaseValue;
}
}
We also have a base converter that has the logic for converting enums to Strings and vice versa, and separate concrete converter classes for each enum type (AFAIK, a fully generic enum converter is not possible to implement, this is also noted in this SO answer). The concrete converters then simply call the base class that does the conversion, like this:
public abstract class EnumConverter<E extends PersistableEnum> {
protected String toDatabaseValue(E value) {
// Do the conversion...
}
protected E toEntityAttribute(Class<E> enumClass, String value) {
// Do the conversion...
}
}
...
#Converter(autoApply = true)
public class SomeEnumConverter extends EnumConverter<SomeEnum>
implements AttributeConverter<SomeEnum, String> {
public String convertToDatabaseColumn(SomeEnum attribute) {
return toDatabaseValue(attribute);
}
public SomeEnum convertToEntityAttribute(String dbData) {
return toEntityAttribute(SomeEnum.class, dbData);
}
}
However, while this approach works very nicely in a technical sense, there's still a pretty nasty pitfall: Whenever someone creates a new enum class whose values need to be stored to the database, that person also needs to remember to make the new enum implement the PersistableEnum interface and write a converter class for it. Without this, the enum will get persisted without a problem, but the conversion will default to using #Enumerated(EnumType.ORDINAL), which is exactly what we want to avoid. How could we prevent this? Is there a way to make JPA (in our case, Hibernate) NOT default to any mapping, but e.g. throw an exception if no #Enumerated is defined on a field and no converter can be found for the type? Or could we create a "catch all" converter that is called for all enums that don't have their own specific converter class and always throw an exception from there? Or do we just have to suck it up and try to remember the additional steps each time?
You want to ensure that all Enums are instances of PersistableEnum.
You need to set a Default Entity Listener (an entity listener whose callbacks apply to all entities in the persistence unit).
In the Default Entity Listener class implement the #PrePersist method and make sure all the Enums are instances of PersistableEnum.
This might sound stupid to you,
but why do I need to define an empty constructor in my #Entitys?
Every tutorial I saw said : every entity needs an empty constructor.
But Java always give you a default invisible empty constructor (if you don't redefine one).
Let me clarify..
What I understood by "need" was write.
Meaning: always write an empty constructor in your entity.
example:
#Entity
public class MyEntity implements Serializable {
#Id
private String str;
public MyEntity(){}
//here getter and setter
}
But Java always gives you this empty constructor when you don't redefine it (write an other one with parameters).
In this case writing this empty constructor seems useless.
An empty constructor is needed to create a new instance via reflection by your persistence framework. If you don't provide any additional constructors with arguments for the class, you don't need to provide an empty constructor because you get one per default.
You can also use the #PersistenceConstructor annotation which looks like following
#PersistenceConstructor
public Movie(Long id) {
this.id = id;
}
to initialise your entity if Spring Data is present in your project. Thus you can avoid the empty constructor as well.
But java always give you a default invisible empty constructor (if you
don't redefine one).
This statement is true only when you don't provide any constructor in your class. If an argument constructor is provided in your class, then JVM will not add the no-argument constructor.
Explicitly defining a default constructor is not necessary unless you provide another constructor for the entity. If you provide another constructor, aside from one with the default constructor's signature, the default constructor will not be created.
Since JPA implementations rely upon the existence of a default constructor it is then necessary to include the default constructor that will be omitted.
As you specified the "JPA" tag, I assume your question applies to JPA only and not empty constructors in general.
Persitence frameworks often use reflection and more specifically Class<T>.newInstance() to instantiate your objects, then call getters/setters by introspection to set the fields.
That is why you need an empty constructor and getters/setters.
See this StackOverflow question about empty constructors in Hibernate.
Actually you don't need to write it. You have it by default. Sometimes you can create private constructor to prevent users to use default
public class MyClass{
private MyClass(){}
}
For singelton patterns, for example you can block using default constructor.
Sometimes, when you use Gson plugin to convert String Json data to Object, it demands to write default constructor, otherwise it doesn't work
All the answers are fine.
But let's talk with code. Following snippets of code will give you more clarity.
PersonWithImplicitConstructor.java
public class PersonWithImplicitConstructor {
private int id;
private String name;
}
First we have to compile the .java file
javac PersonWithImplicitConstructor.java
Then class file will be generated.
Running the javap on top this class file will give you the following information.
javap PersonWithImplicitConstructor.class
Compiled from "PersonWithImplicitConstructor.java"
public class PersonWithImplicitConstructor {
public PersonWithImplicitConstructor();
}
NOTE: If you want more information, you can use -p flag on javap.
The next java file will have parameterised constructor only.
PersonWithExplicitConstructor.java
public class PersonWithExplicitConstructor {
private int id;
private String name;
public PersonWithExplicitConstructor(int id, String name) {
this.id = id;
this.name = name;
}
}
javac PersonWithExplicitConstructor.java
javap PersonWithExplicitConstructor.class
Compiled from "PersonWithExplicitConstructor.java"
public class PersonWithExplicitConstructor {
public PersonWithExplicitConstructor(int, java.lang.String);
}
PersonWithBothConstructors.java
public class PersonWithBothConstructors {
private int id;
private String name;
public PersonWithBothConstructors() {
}
public PersonWithBothConstructors(int id, String name) {
this.id = id;
this.name = name;
}
}
javac PersonWithBothConstructors.java
javap PersonWithBothConstructors.class
Compiled from "PersonWithBothConstructors.java"
public class PersonWithBothConstructors {
public PersonWithBothConstructors();
public PersonWithBothConstructors(int, java.lang.String);
}
Java not always give you a default invisible empty constructor if your class got argument constructor, you have to define the empty constructor by your own.
From the JPA tag, I suppose that you are working with Java beans. Every bean needs to have the following properties:
Getters and setters for all its main instance variables.
An empty constructor.
All its instance variables should preferably be private.
Thus the statement : "every entity needs an empty constructor".
What are the correct rules to write a JavaBean class?
I'm confused because some books use MUST while other user SHOULD or COULD to describe
the writing rule:
i.e.
a bean class MUST implements Serializable or SHOULD?
the instance variables MUST be private or SHOULD BE?
A JavaBean is defined by its properties (i.e. its getter and setter methods), not it's fields. Although the terms are used interchangably, that is actually not correct. The Introspector mechanism ignores fields completely.
Example
Take this (awfully designed) Javabean:
public class TestBean {
private int baz;
private char[] phleem;
public String getFoo() {
return new String(phleem);
}
public void setFoo(final String foo) {
this.phleem = foo.toCharArray();
}
public long getBar() {
return baz;
}
public void setBar(final long bar) {
this.baz = (int) bar;
}
}
You'd think the properties are:
"baz" (int)
"phleem" (char[])
but now let's inspect it with the Javabeans introspector:
for (PropertyDescriptor descriptor : Introspector
.getBeanInfo(TestBean.class, Object.class)
.getPropertyDescriptors()) {
System.out.println("Name: " + descriptor.getName() +
", type: " + descriptor.getPropertyType());
}
Here's the output:
Name: bar, type: long
Name: foo, type: class java.lang.String
Conclusion:
Getters and setters are what define a Javabeans property. It's a convention that they are backed by fields of the same name and type, but the fields are not actually part of the Javabean properties (although many documentations will suggest otherwise).
On re-reading my answer: it is meant as an addendum to the other answers. If you want a short and simple answer, go with skaffman's.
It is a public class.
It has a public parameterless constructor (though it may have other constructors
as well)
It implements Serializable interface (i.e. it can be made persistent, so its state can
be saved)
It has properties with “getter” and “setter” methods named by following
JavaBeans naming patterns
It has events which follow the standard Java event model with the registration
methods named by following the JavaBeans naming patterns
It may have other methods which do not follow the naming patterns. These
methods are not exposed by a builder tool.
Adding to the previous poster - skaffman. It is always a good practice to override, toString(), hashCode(), equals() and finally write a overloaded constructor that has all the fields (that this class has) as input.
Be sure not to use other references (like List, HashMaps etc) in the toString() and hashCode()'s implementation.
On a side note, eclipse has built-in functionality to generate them for you..
A Java Bean is a Java class that should follow the following conventions:
It should have a no-arg constructor.
It should be Serializable.
It should provide methods to set and get the values of the properties, known as getter and setter methods.
All the above and it should not cross the boundaries of Java API . It means it should not extend or implement any classes or interface,but one relaxation is there it can implement only one serializable interfce why because it is a marker interface
I've been playing around with getting rid of DAOs in favor of ActiveRecord like entities in Java, but generics won't allow me to have the full functionality that I want (like static finders). Somehow Groovy does, but I'm confused why. Given the following:
class ActiveRecord<T> {
static Class<T> genericType;
ActiveRecord() {
genericType = ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];
}
static T find(Serializable id) { return EntityManagerHolder.find(genericType, id); }
void save() { EntityManagerHolder.persist(this); }
}
#Entity #Table(name="TEST")
class FakeTable extends ActiveRecord<FakeTable> {
#Id #GeneratedValue(strategy = GenerationType.AUTO)
Long id;
String status;
String type;
static void main(args) {
FakeTable t = new FakeTable();
t.status = "TESTING";
t.save();
println FakeTable.find(t.id);
}
}
This code works (with the JPA stuff that's excluded), but I'm not sure why I'm able to declare
static Class<T> genericType;
Does the compiler do some magic before the actual Java class is compiled? Maybe the groovy compiler is replacing T with the actual class name in the generated Java class?
In strictly Java, I can access the generic type from the find method return type and the class declaration, but both are erased to Object. That makes sense, and Groovy does the same, but in Java, the above line errors out with a message similar to 'Cannot reference non-static T'.
Groovy is not statically typed. I think you'll find it erases the T at compile time, and doesn't even bother to work out that it's not in scope; it's just irrelevant to Groovy.
The main problem that you will run into is that in Java and in Groovy, static methods are NOT inherited. Grails (and other Java frameworks) get around this problem by manipulating byte-code to generate those methods at runtime.
Using groovy, at program start up you could try looping through all the ActiveRecord subclasses and attaching the static finders to their meta class. If you use the ActiveRecord class both to find the sub-classes and to get the static finders at least you can still tell what methods they inherited by looking at the ActiveRecord class itself.
EDIT:
It occurred to me that you could also implement methodMissing on the ActiveRecord class to try to look for the method in on the ActiveRecord object instead. You would just have to be careful not to setup an infinite loop.
I've been converting some code from java to scala lately trying to teach myself the language.
Suppose we have this scala class:
class Person() {
var name:String = "joebob"
}
Now I want to access it from java so I can't use dot-notation like I would if I was in scala.
So I can get my var's contents by issuing:
person = Person.new();
System.out.println(person.name());
and set it via:
person = Person.new();
person.name_$eq("sallysue");
System.out.println(person.name());
This holds true cause our Person Class looks like this in javap:
Compiled from "Person.scala"
public class Person extends java.lang.Object implements scala.ScalaObject{
public Person();
public void name_$eq(java.lang.String);
public java.lang.String name();
}
Yes, I could write my own getters/setters but I hate filling classes up with that and it doesn't make a ton of sense considering I already have them -- I just want to alias the _$eq method better. (This actually gets worse when you are dealing with stuff like antlr because then you have to escape it and it ends up looking like person.name_\$eq("newname");
Note: I'd much rather have to put up with this rather than fill my classes with more setter methods.
So what would you do in this situation?
You can use Scala's bean property annotation:
class Person() {
#scala.reflect.BeanProperty
var name:String = "joebob"
}
That will generate getName and setName for you (useful if you need to interact with Java libraries that expect javabeans)