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.
Related
I have a POJO like this:
public class Foo {
private String bar1;
private String bar2;
//...
public String getBar1() { return bar1; }
public void setBar1(String bar1) { this.bar1 = bar1; }
public String getBar2() { return bar2; }
public void setBar2(String bar2) { this.bar2 = bar2; }
//...
}
As an alternative to Java reflection (which is quite slow in general), I would like to define a class with static methods like this:
public class FooStatic {
public static String getBar1(Foo foo) { return foo.getBar1(); }
public static void setBar1(Foo foo, String bar1) { foo.setBar1(bar1); }
public static String getBar2(Foo foo) { return foo.getBar2(); }
public static void setBar2(Foo foo, String bar2) { foo.setBar2(bar2); }
//...
}
which enforces the creation/deprecation of a static method every time the Foo class is updated. For example, if the field bar2 is deleted in FooStatic, then the static methods getBar2() and setBar2() in FooStatic should be identified by the compiler to be removed. If a new variable bar3 is added to Foo with getters and setters, the compiler should enforce the creation of new static methods getBar3() and setBar3() in FooStatic. Moreover, I have multiple POJOs, and would like a solution which scales. Is this possible?
Yes... sort of. It's very complicated.
Annotation Processors are compiler plugins that run at certain times during the compilation process. It gets complex fast - IDEs and build tools are 'incremental' (they don't want to recompile your entire code base everytime you change a single character, of course), for example.
Annotation processors can do a few things:
They can run as part of the compilation processes. This can be done automatically - they just need to be on the classpath, is all
They can be triggered due to the presence of an annotation.
They can read the signatures of existing files (the names of fields and methods, the parameter names, parameter types, return type, and throws clause, and the type of fields, and the extends and implements clauses, and the param names and types of the constructors). They can't read the body content (initializing expressions, method and constructor bodies). But I think you just need the signatures here.
They can make new files. They can even make new java files which will then automatically get compiled along with the rest.
Thus, you have a route here: Make an annotation, then make an annotation processor. For example, you could set it up so that you manually write:
#com.foo.Hossmeister.Singletonify
class Example {
void foo1() {}
String foo2(String arg) throws IOException {}
}
and have an Annotation Processor (which also has that com.foo.Hossmeister.Singletonify annotation), which, if it is on the classpath, automatically generates and ensures that all other code can automatically see this file:
// Generated
class ExampleSingleton {
private ExampleSingleton() {}
private static final Example INSTANCE = new Example();
public void foo1() {
INSTANCE.foo1();
}
public static String foo2(String arg) throws IOException {
return INSTANCE.foo2(arg);
}
}
But, annotation processors are tricky beasts to write, and they can be quite a drag on the compilation process. Still, that's the only way to get what you want. Now you have something to search the web for / read up on :)
You start by making a separate project that defines the annotation, has the annotation processor (a class that extends AbstractProcessor), pack that into a jar, and make sure the manifest includes an SPI file that tells java that your class that extends AbstractProcessor is an annotation processor, and then it'll be picked up automatically. I'll give you the annotation definition:
In a file named Singletonify.java:
#Retention(RetentionPolicy.CLASS)
#Target(ElementType.TYPE)
public #interface Singletonify {}
But... wait!
The concept of singletons is often problematic. Singletons should be 'stateless' - and if they are stateless, why isn't your Foo class just filled with entirely static methods, obviating the need for your "static mirror class"? If it is stateful, you now have global state which is a virtually universally decried anti-pattern. You don't want global state, it makes reasoning about control flow impossible.
A second problem is testability - because static stuff doesn't 'do' inheritance, you can't (easily) make test implementations of static methods. With non-static stuff this is much easier.
This problem is more generally solved by so-called Dependency Injection frameworks such as Dagger, Guice, or Spring. They let you write code that just 'gets' an instance of your Foo class, without callers having to actually figure out where to get this instance from: The Dependency Injection framework takes care of it. It lets you do things like "Have a singleton of this object... per web session". Which is pretty powerful stuff.
I think what you probably want is a DI system. You may want to investigate a bit before spending the 2 weeks writing that annotation processor.
I have a utility class for interacting with the Datastore (GAE's in-built Datastore in my case) and it has methods like:
//Class GaeDataUtil
public static <T> Optional<Key<T>> saveEntity(T entity)
(Optional is from the Guava library and Key<T> from Objectify, although I doubt any of this makes a difference.)
I want my (minimal) hierarchy of entities to have a .save() method. So that for:
public class User extends RootEntity
where RootEntity provides:
public Optional<Key<T>> save() {
//Skipping the error-handling.
return GaeDataUtil.saveEntity(this);
}
I can write:
User myUser = new User();
// set some properties
Optional<Key<User>> optKey = myUser.save();
But of course that doesn't work because a call to myUser.save() returns Optional<Key<RootEntity>> not Optional<Key<User>> as I want.
I can avoid this issue by typecasting in User.save() (and Account.save() and Project.save() etc. etc.) and suppressing warnings, but even if there are only (say) 10 entity classes extending RootEntity, that's still a fair bit of boilerplate code to write just to typecast. Also, I think that much of the benefit of having a class hierarchy is lost if I have to write code (however minimal) for every derived class (there will be other, similar methods too).
Is there a better solution to this?
Update: using Java 7.
You will just need to type cast it to the Generic type T in the RootEntity.save() method.
public <T> Optional<Key<T>> save() {
//Skipping the error-handling.
return (Optional<Key<T>> GaeDataUtil.saveEntity(this); // This line will generate a warning.
}
And then when you write,
Optional<Key<User>> optKey = myUser.save();
It will automatically be inferred correctly because of Target Type Inference.
One solution is to parameterize RootEntity something like this:
class RootEntity<Subclass extends RootEntity> {
public Optional<Key<Subclass>> save() {...}
}
Then define your subclass like:
class User extends RootEntity<User> {...}
I've used this pattern before. If there is a slicker solution, I'll be eager to see it. :)
This is what finally worked:
public <T extends RootEntity> Optional<Key<T>> save1() {
#SuppressWarnings("unchecked")
Key<T> key = (Key<T>) ofy().save().entity(this).now();
return Optional.fromNullable(key);
}
Doing this in two steps works (get the Key, then wrap it up in an Optional) --- it let's the Target Type Inference work correctly. Doing it in a single step doesn't:
public <T extends RootEntity> Optional<Key<T>> save2() {
return (Optional<Key<T>>) Optional.fromNullable(ofy().save().entity(this).now());
}
This second form as suggested by #Codebender shows an error (Cannot cast from Optional<Key<RootEntity>> to Optional<Key<T>>), not a warning in Eclipse.
However, the basic idea by #Codebender of using Target Type Inference was sound.
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;
}
IS it possible to use the java reflection api in GWT client side? I want to use reflections to find the value of a property on a Javabean. Is this possible?
You can use the GWT Generators functionality that allows you to generate code during the GWT compile phase.
Your bean, that you want to introspect, can extend a class that has a method defined as
public Object getProperty(String propertyName){}
Let's call this class IntrospectionBean.
Let's say that you then have your bean defined as:
public class MyBean extends IntrospectionBean {
private String prop1;
private String prop2;
}
The GWT generator will have access to all fields of MyBean and it can generate the getProperty(String propertyName) method during GWT compile time, after iterating through all fields of MyBean.
The generated class might look like this:
public class MyBean extends IntrospectionBean {
private String prop1;
private String prop2;
public Object getProperty(String propertyName) {
if ("propr1".equals(propertyName)) {
return prop1;
}
if ("propr2".equals(propertyName)) {
return prop2;
}
return null;
}
}
You could simply then use myBean.getProperty("prop1") in order to retrieve a property based on it's name at runtime.
Here you can find an example of how to implement a gwt generator
I've been there and the solution indeed is to use Deferred Binding and Generators. You can see a use of Generators to overcome the lack of Reflection in GWT client here:
http://jpereira.eu/2011/01/30/wheres-my-java-reflection/
Hope it helps.
Since GWT code is translated to Javascript direct usage of reflection API is not supported.
There is a small project GWT-Reflection, that allows to use reflection in GWT.
I have made my gwt-reflection library public.
https://github.com/WeTheInternet/xapi/tree/master/gwt/gwt-reflect
https://github.com/WeTheInternet/gwt-sandbox/tree/xapi-gwt/user/src/com/google/gwt/reflect
Due to classpath issues with trying to make Gwt pick my version of Class.java over its own, I finally just forked Gwt, added java 8 and reflection support, and now maintain net.wetheinter:gwt-*:2.7.0 which has this support baked in (I will release a 2.8 some time after Gwt 2.8 goes live)
It supports three levels of reflection:
Monolithic:
// Embeds all data needed to perform reflection into hidden fields of class
GwtReflect.magicClass(SomeClass.class);
SomeClass.getField(fieldName).set(null, 1);
Lightweight:
// Allows direct reflection, provided ALL parameters are literals, or traced to literals
SomeClass.class.getField("FIELD_NAME").set(null, 1);
Flyweight:
// Skips creating a Field object entirely, and just invokes the accessor you want
// All params must be literals here as well
GwtReflect.set(SomeClass.class, "FIELD_NAME", null, 1);
These examples also work for Methods and Constructors. There's basic support for annotations, and more to come in the future.
GWT not support reflection fully, you can see bellow link :
http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsCompatibility.html
You should note the border between java and javascript. In GWT, all code compiles to javascript, so you have to check if JavaScript is a well-defined reflection.
If you just want to use reflection to grab a private field, consider using jsni (javascript native interface) instead; it has no notion of private or public, so you can just grab anything you want like so:
package com.foo;
class SomeClass {
private String someField;
private static int someInt;
}
//accessors:
native String ripField(SomeClass from)
/*-{
return from.#com.foo.SomeClass::someField;
}-*/;
native int ripInt()
/*-{
return #com.foo.SomeClass::someInt;
}-*/;
Also, I am in the middle of finishing up emulation for java.lang.Class newInstance / reflection.
I'll post back here with a link in about two days if you'd like to play with it.
It requires that you pass a class through a method which I route to a custom generator
(like GWT.create, except it returns a generated java.lang.Class with field and method accessors that just point to jsni methods / fields. :)
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)