Should a bean dto always have an associated interface ?
Below dto is used by jackson to send json over the wire :
public class Bean {
private String date;
public Bean(String date)
{
this.link = date;
}
public String getDate() {
return date;
}
}
Should this class always implement an interface to match its structure ?
I wouldn't unless you're using an API or Framework that requires an interface or are writing an API yourself.
Older versions of J2EE (before it became Java EE) required interfaces for enterprise beans, and some other frameworks use an interface to generate a proxy; however that has mostly been replaced by the runtime generation of synthetic proxies. If you start with a well defined class, you can later add an interface you discover a need for one.
Currently one of my tasks is maintaining an existing web application. Essentially everything in it has the Interface + Class pattern, but for no real reason as its all self contained. The extra files for the interfaces just clutter up the workspace and make tracking down the source of the actual code take a couple seconds longer in each case (can't just highlight and press F3 in Eclipse).
Related
This morning I fell into a particular case that never happened to me before. I'm developing a Minecraft plugin using the minecraft server API which is usually called NMS with reference to the name of its packages (eg net.minecraft.server.v1_13_R1 for version 1.13).
The main problem with the use of the minecraft server API is that it is difficult to write a cross version code: indeed the name of the packages changes with each new version.
When the plugin only supports two versions it is usually easier to use the interfaces to write two different codes depending on the version. But when you have to support a dozen different versions (and this is my case), it's a bad idea (the plugin would be much too heavy, it would have to import every jar in the IDE, and I would have to redo the code with each new version).
In these cases I usually use reflection but I do not think it's possible here:
packet = packetConstructor.newInstance(
new MinecraftKey("q", "q") {
#Override
public String toString() {
return "FML|HS";
}
},
packetDataSerializerConstructor.newInstance(Unpooled.wrappedBuffer(data)));
As you probably guessed MinecraftKey is a class from NMS and I was told to use Java Dynamic Proxy API. I have never used it and would like to know if you would know a place that would explain to me how to do it simply? If you know of another better method that interests me too!
When I think about it, I think that this is really a lot of trouble for a tiny piece of code x)
EDIT :
My plugin uses the PacketPlayOutCustomPayload (aka plugin messages) to communicate with the mods of the players. It allows me to send a message (a byte []) on a particular channel (a String). But with the 1.13 this String has been replaced by a MinecraftKey (a wrapper for the String that replaces some characters and requires the use of a ":"). This poses a problem when players connect to 1.12 on my 1.13 server so I do not have a choice: I have to override the MinecraftKey object in this case.
I don’t really think using proxy classes is good solution here, it will only make it harder to debug, but if you need something like that you should use library like ByteBuddy: (as java can’t generate proxy for a class, only interfaces are allowed)
import net.bytebuddy.ByteBuddy;
import net.bytebuddy.implementation.FixedValue;
import static net.bytebuddy.matcher.ElementMatchers.*;
public class Main {
public static void main(String[] args) throws Exception {
SomeKey someKey = new SomeKey("my", "key");
System.out.println(someKey); // :<
// this class should be cached/saved somewhere, do not create new one each time.
Class<? extends SomeKey> loaded = new ByteBuddy()
.subclass(SomeKey.class)
.method(named("toString").and(returns(String.class).and(takesArguments(0))))
.intercept(FixedValue.value("something"))
.make()
.load(Main.class.getClassLoader()).getLoaded();
someKey = loaded.getConstructor(String.class, String.class).newInstance("what", "ever");
System.out.println(someKey); // YeY
}
}
class SomeKey {
final String group;
final String name;
public SomeKey(String group, String name) {
this.group = group;
this.name = name;
}
public String getGroup() { return this.group; }
public String getName() { return this.name; }
#Override public String toString() {
return group+":"+name;
}
}
But I would just create separate modules in my project, one that does only work with real bukkit API and contains many interfaces to represent NMS types in some normalised and readable way.
And separate modules for each version, then you will not have much code to duplicate, as most of it will be abstracted and handled by that “core/base” module.
Then you can build it as one single fat jar or separate .jar per version.
Other solution might be using some template engines and preprocessors to generate java sources on build time, see how fastutil is doing this:
https://github.com/vigna/fastutil
And yet another solution for simple classes and parts of code would be to use build-in javascript or external script language like groovy to also create this pattern-line but in runtime. But I would use this only for simplest stuff.
Also for just using methods you can just use normal reflections.
You can also always inject into netty and instead of using default packet serializer just write own bytes, then you don't need that key at all.
I would like to send messages in JSON format through RabbitMQ from one Java application to another using spring-amqp (1.7.4). The two applications do not share the same domain model classes.
I have a single generic #RabbitListener annotated method on the receiving end, that takes a single argument of type Event, an interface.
I have properly configured Jackson to handle the Event type hierarchy on both sides, yet, spring-rabbit won't convert my JSON message into the proper type because DefaultJackson2JavaTypeMapper does not support inferred abstract classes or interfaces.
If I define a custom JavaTypeMapper that extends DefaultJackson2JavaTypeMapper and does the following, it works perfectly fine:
#Override
public JavaType toJavaType(MessageProperties properties) {
boolean hasInferredTypeHeader = hasInferredTypeHeader(properties);
if (hasInferredTypeHeader && getTypePrecedence().equals(TypePrecedence.INFERRED)) {
// do not check for abstract classes and interfaces here
JavaType targetType = fromInferredTypeHeader(properties);
return targetType;
}
return super.toJavaType(properties);
}
Wouldn't it be better to leave the user in charge of how the conversion is to take place (either using spring-rabbit conventions or using Jackson directly)? Maybe add a flag that enables abstract classes and interfaces support? Is there something I'm missing?
Feel free to open an Improvement JIRA Issue.
Contributions are welcome along with suitable test cases.
I'm rolling my own IAuthorizationStrategy for Wicket 1.5.x I've setup type annotation for pages to use with isInstantiationAuthorized(). It works well and I'd like to use annotations for isActionAuthorized() as well. Ideally I'd like to be able annotate local variables and then check the annotations in my AuthStrategy. From what I've read Local variable Annotation doesn't work that way.
Is there any kind of known work around, maybe some sort of Compile time annotation processing to turn an annotated local variable into an "anonymous" subclass with the annotation as a type annotation?
For the record, the annotation I'm trying to use looks like this:
#Retention(RetentionPolicy.Runtime)
#Target(ElementType.Type, ElementType.LOCAL_VARIABLE)
public #interface AdminOnly
{
int isVisible() default 0;
int isEnabled() default 1;
}
UPDATE
So based on #Xavi López'es answer what I was hoping to do isn't exactly possible.
Annotated LocalVariables should be available at compile time though. Is there some way maybe I could use them as a shortcut for boiler-plating the meta-data code examples that are available in Wicket Examples or the excellent Apache Wicket Cookbook?
I've struggled with a similar issue some time ago with Wicket 1.3.x, and didn't find any way to achieve this with annotations. Annotations on local variables can't be retained at run-time, as explained in the JLS (9.6.3.2. #Retention):
An annotation on a local variable declaration is never retained in the binary representation.
In this related question: How can I create an annotation processor that processes a Local Variable? they talked about LAPT-javac, a patched javac version to allow this. On their site there's a link to the Type Annotations Specification (JSR 308), which will hopefully address this subject (JDK 8 ?).
I ended up defining a plain old interface with a related functionality code:
public interface RestrictedComponent {
Integer getFunction();
}
The main problem with this approach is that it's not possible to make instant anonymous subclasses of a specific class implement other interfaces (such as Component c = new TextField() implements AdminOnly { }) , but you can always define Component extensions that just implement RestrictedComponent in a class:
public abstract class RestrictedTextField extends TextField implements RestrictedComponent { }
Finally, I ended up implementing a RestrictedContainer that just subclassed WebMarkupContainer and put every secured component inside one, modelling it with a <wicket:container> in the markup.
public class RestrictedContainer extends WebMarkupContainer implements RestrictedComponent {
private final Integer function;
public RestrictedContainer(String id, IModel model, final Integer function) {
super(id, model);
this.function = function;
}
public RestrictedContainer(String id, final Integer funcionalitat) {
super(id);
this.function = function;
}
public Integer getFunction() {
return function;
}
}
And then in the Authorization Strategy checked for component instanceof RestrictedComponent and returned true or false depending on user permissions on the associated function.
I'm building a simple RESTFul Service; and for achieve that I need two tasks:
Get an instance of my resource (i.e Book) from request parameters, so I can get that instance to be persisted
Build an XML document from that instance to send the representation to the clients
Right now, I'm doing both things in my POJO class:
public class Book implements Serializable {
private Long id;
public Book(Form form) {
//Initializing attributes
id = Long.parseLong(form.getFirstValue(Book.CODE_ELEMENT));
}
public Element toXml(Document document) {
// Getting an XML Representation of the Book
Element bookElement = document.createElement(BOOK_ELEMENT);
}
I've remembered an OO principle that said that behavior should be where the data is, but now my POJO depends from Request and XML API's and that doesn't feels right (also, that class has persistence anotations)
Is there any standard approach/pattern to solve that issue?
EDIT:
The libraries i'm using are Restlets and Objectify.
I agree with you when you say that the behavior should be where the data is. But at the same time, as you say I just don't feel confortable polluting a POJO interface with specific methods used for serialization means (which can grow considerably depending on the way you want to do it - JSON, XML, etc.).
1) Build an XML document from that instance to send the representation to the clients
In order to decouple the object from serialization logic, I would adopt the Strategy Pattern:
interface BookSerializerStrategy {
String serialize(Book book);
}
public class XmlBookSerializerStrategy implements BookSerializerStrategy {
public String serialize(Book book) {
// Do something to serialize your book.
}
}
public class JsonBookSerializerStrategy implements BookSerializerStrategy {
public String serialize(Book book) {
// Do something to serialize your book.
}
}
You POJO interface would become:
public class Book implements Serializable {
private Long id;
private BookSerializerStrategy serializer
public String serialize() {
return serializer.serialize(this);
}
public void setSerializer(BookSerializerStrategy serializer) {
this.serializer = serializer;
}
}
Using this approach you will be able to isolate the serialization logic in just one place and wouldn't pollute your POJO with that. Additionally, returning a String I won't need to couple you POJO with classes Document and Element.
2) Get an instance of my resource (i.e Book) from request parameters, so I can get that instance to be persisted
To find a pattern to handle the deserialization is more complex in my opinion. I really don't see a better way than to create a Factory with static methods in order to remove this logic from your POJO.
Another approach to answer your two questions would be something like JAXB uses: two different objects, an Unmarshaller in charge of deserialization and a Marshaller for serialization. Since Java 1.6, JAXB comes by default with JDK.
Finally, those are just suggestions. I've become really interested in your question actually and curious about other possible solutions.
Are you using Spring, or any other framework, in your project? If you used Spring, it would take care of serialization for you, as well as assigning request params to method params (parsing as needed).
i have a small code generation question.
I have a EJB3 backend that serves DTO objects to a frontend. The frontend uses a configurable binding procedure to map the attributes of the DTO to their forms.
At the moment they are doing it by specifing the attributes as strings in ther configuration. The binding implementation uses reflection to acces the attributes.
Sounds nice but the problem is, each time we change an attribute name in a DTO, this will not lead to a compile error in the frontend because they have just strings.
I'm now looking for a way to create a string constant for each attribute of the class that can be used by the frontend to map the attributes to their forms so that they get compile errors if i made changes in the dto attributes.
Example how it is:
public class CarDTO {
private String vendor;
private String name;
public String getVendor() {}
public String getName() {}
[..]
}
And how it should be:
public class CarDTO {
public static final String VENDOR = "vendor";
public static final String NAME = "name";
private String vendor;
private String name;
public String getVendor() {}
public String getName() {}
[..]
}
I was looking for a maven plugin that is capable of this but without success. Is there any one who nows a tool which can do things like that?
Thanks in advance
martin
Modifying existing class is more difficult then creating new one.
JPA took a interesting approach to solve this problem by creating CarDTO_ class. See http://www.hibernate.org/subprojects/jpamodelgen.html for more details. This approach is much easier. You can look at the hibernate maven plugin that implement the code generation.
If you really want to modify the existing class, then I would recommend using AspectJ with an approach similar to Spring Roo, where the aspect contains the generated code.
Edited (Example using AspectJ)
In this case, we are using AspectJ inter-type declarations that enables you to modify an existing class.
aspect CarAspect
{
public static final String CarDTO.VENDOR = "vendor";
public static final String CarDTO.NAME = "name";
}
Do implement this in maven, you need
a plugin to generate the CarAspect
the aspectj-maven-plugin to compile (weave) the aspect
Also, Eclipse has good support for AspectJ so you can use it there too.
I have a app with a similar frontend approach to access the domain classes, but I have my domain is entirely created via a DSL implemented via Eclipse Xtext, who can be used in a maven build also. There is a sample Java domain DSL project in the xtext distribution, its easy to start from there.
This sure is not a fast "just use a maven plugin" solution but once you get into Xtext it will pay off, especially if you have a lot domain classes, or a lot similar projects.
From my domain DSL I create via code templates and a xtext generator project three classes:
target/generated/mydsl (generated always):
AbstractDomainClass (in this file i have my static string's)
src/main/java (generated once):
ConcreteDomainClass
src/test/java (generated once):
ConcreteDomainClassTest
In the abstract domain class i have all getters and setters and simple persistence stuff in it, in the concrete domain class is the more complex stuff and the test class stands for it self.