Using ASM 9 on Java11, I am able to generate my Sample Class dynamically, but my current class implements interface MyBeanIface
public class Sample implements MYBeanIface
{
public String SampleId = "";
public Sample() {
this.super();
}
// other getters/setters
}
I want to know how do i implement all methods from interface using ASM?
Also want to know if there is any way to generate toString() method dynamically?
Thanks
I have a simple java abstract class:
abstract public class MyClass implements Streamable {
private static final long serialVersionUID = 5593048244217796061L;
...
protected MyClass() { }
...
abstract public ReturnType abstractMethod(ArgType crd);}
All types mentioned are also streamable (i'm not using default Java serialization, but some "GWT" serializer).
Now, i have A LOT of classes which work like this:
public abstract class AnotherClass implements Streamable {
protected AnotherClass() { }
protected void initDeterminators() {
MyClass determinator = new MyClass(conditions) {
#Override
public ReturnType abstractMethod(ArgType crd) {
//some code
}
};
addDeterminator(determinator);
}}
While serializing the "AnotherClass" i'm getting an error:
com.nkdata.gwt.streamer.client.StreamerException: Error creating streamer for class package.AnotherClass$1
Adding "Serial UIID" didn't help. "MyClass" do have protected default ctor. What should i do in order to make it serializable? Can i avoid changing all those other classes which make use of "MyClass"?
It turned out i had some cross references i didn't mentioned for sake of simplicity:
in place of
//some code
i was calling the method of outer "AnotherClass" instance and it seems that's a no-no for serialization.
I've solved by:
1) avoiding anonymous class
2) passing "conditions" and "this" to the constructor of that class.
3) instead of
>some code calling outer method<
i've did
>some code calling "parent.method()"<
Let's say there's a class that I use extensively and is returned by a method.
CommonClass obj = getCommonObject();
Now I want to extend this class to create some utility method to avoid repeating myself.
public CommonClassPlus extends CommonClass {
public String dontRepeatYourself() {
// the reason I'm creating a subclass
}
}
Of course I would like to use my improved class for the method above, however, downcasting isn't allowed.
CommonClassPlus obj = getCommonObject();
//Cannot cast to CommonClassPlus
How can I use the method dontRepeatYourself() if I can only work with the object that is an instance of the superclass?
CommonClass and getCommonObject() are from an external library and I cannot change them.
You cannot add behavior to an existing instance in Java (like you could in JavaScript, for example).
The closest you can get in Java is the Decorator pattern:
CommonClassPlus obj = decorate(getCommonObject());
where decorate() is
public CommonClassPlus decorate(CommonClass x) {
return new CommonClassPlus(x);
}
This approach creates a potentially huge amount of boilerplate because it must delegate each method call to the wrapped instance. If a method in CommonClass is final and there is no interface you can reimplement, then this approach fails altogether.
In most cases you will be able to get along with a simple static helper method:
public static String dontRepeatYourself(CommonClass x) {
...
}
If CommonClass is from an external library, you probably want to wrap it in an Adapter Pattern anyway, using the principle of Composition over Inheritance.
This gives you complete control if you want to, say, change the library you're using, and allows you to add functionality like dontRepeatYourself().
public class CommonClassAdapter implements MyAdapter {
private final CommonClass common;
private final String cachedResult;
// Note that I'm doing dependency injection here
public CommonClassAdapter(CommonClass common) {
this.common = common;
// Don't expose these because they shouldn't be called more than once
common.methodIOnlyCallOnce();
cachedResult = common.anotherMethodIOnlyCallOnce();
}
#Override
public void someMethod() {
common.someMethodWithDifferentName();
}
#Override
public String dontRepeatYourself() {
return cachedResult;
}
}
Note also that most modern IDEs have things like Eclipse's Source -> Generate Delegate Methods to make this process faster.
Small preamble. I was good java developer on 1.4 jdk. After it I have switched to another platforms, but here I come with problem so question is strongly about jdk 1.6 (or higher :) ). I have 3 coupled class, the nature of coupling concerned with native methods. Bellow is example of this 3 class
public interface A
{
public void method();
}
final class AOperations
{
static native method(. . .);
}
public class AImpl implements A
{
#Override
public void method(){
AOperations.method( . . . );
}
}
So there is interface A, that is implemented in native way by AOperations, and AImpl just delegates method call to native methods.
These relations are auto-generated. Everything ok, but I have stand before problem. Sometime interface like A need expose iterator capability. I can affect interface, but cannot change implementation (AImpl).
Saying in C# I could be able resolve problem by simple partial:
(C# sample)
partial class AImpl{
... //here comes auto generated code
}
partial class AImpl{
... //here comes MY implementation of
... //Iterator
}
So, has java analogue of partial or something like.
EDITED:
According to comment by #pgras I need some clarification. AImpl is not in vacuum, there is some factory (native implemented) that returns instance of AImpl, that is why creation of inheritance from AImpl, is not applicable.
EDITED 2:
May be it doesn't relate, but how it is done by JUnit 4:
public class SomeTest {
...
//there is no direct inheritance from Assert, but I can use follow:
assertTrue(1==1); //HOW DOES it works??
Java does not have support for partials or open classes. Other JVM languages do, but not Java. In your example, the simplest thing may unfortunately be to use delegation. You can have your AImpl take another object that fulfills an interface to these extension methods. The generated AImpl would then have generated methods such as iterator methods that it could delegate to the user created object you pass in.
How about that:
Compute.java = your class
Compute$.java = base class for partial classes. Reference a Compute object
Compute$Add.java = your partial class. Subclass Compute$.
Compute$Sub.java = your partial class. Subclass Compute$.
file Compute.java
public class Compute {
protected int a, b;
Compute$Add add;
Compute$Sub sub;
public Compute() {
add = new Compute$Add(this);
sub = new Compute$Sub(this);
}
public int[] doMaths() {
int radd = add.add();
int rsub = sub.sub();
return new int[] { radd, rsub };
}
}
file Compute$.java
public abstract class Compute$ {
protected Compute $that;
public Compute$(Compute c){
$that=c;
}
}
file Compute$Add.java
public class Compute$Add extends Compute$ {
public Compute$Add(Compute c) {
super(c);
// TODO Auto-generated constructor stub
}
public int add(){
return $that.a+$that.b;
}
}
file Compute$Sub.java
public class Compute$Sub extends Compute$ {
public Compute$Sub(Compute c) {
super(c);
}
public int sub() {
return $that.a - $that.b;
}
}
You could extend A (say interface B extends A) and extend AImpl and implement B (class BImpl extends AImpl implements B)...
I know that an interface must be public. However, I don't want that.
I want my implemented methods to only be accessible from their own package, so I want my implemented methods to be protected.
The problem is I can't make the interface or the implemented methods protected.
What is a work around? Is there a design pattern that pertains to this problem?
From the Java guide, an abstract class wouldn't do the job either.
read this.
"The public access specifier indicates that the interface can be used by any class in any package. If you do not specify that the interface is public, your interface will be accessible only to classes defined in the same package as the interface."
Is that what you want?
You class can use package protection and still implement an interface:
class Foo implements Runnable
{
public void run()
{
}
}
If you want some methods to be protected / package and others not, it sounds like your classes have more than one responsibility, and should be split into multiple.
Edit after reading comments to this and other responses:
If your are somehow thinking that the visibility of a method affects the ability to invoke that method, think again. Without going to extremes, you cannot prevent someone from using reflection to identify your class' methods and invoke them. However, this is a non-issue: unless someone is trying to crack your code, they're not going to invoke random methods.
Instead, think of private / protected methods as defining a contract for subclasses, and use interfaces to define the contract with the outside world.
Oh, and to the person who decided my example should use K&R bracing: if it's specified in the Terms of Service, sure. Otherwise, can't you find anything better to do with your time?
When I have butted up against this I use a package accessible inner or nested class to implement the interface, pushing the implemented method out of the public class.
Usually it's because I have a class with a specific public API which must implement something else to get it's job done (quite often because the something else was a callback disguised as an interface <grin>) - this happens a lot with things like Comparable. I don't want the public API polluted with the (forced public) interface implementation.
Hope this helps.
Also, if you truly want the methods accessed only by the package, you don't want the protected scope specifier, you want the default (omitted) scope specifier. Using protected will, of course, allow subclasses to see the methods.
BTW, I think that the reason interface methods are inferred to be public is because it is very much the exception to have an interface which is only implemented by classes in the same package; they are very much most often invoked by something in another package, which means they need to be public.
This question is based on a wrong statement:
I know that an interface must be public
Not really, you can have interfaces with default access modifier.
The problem is I can't make the interface or the implemented methods protected
Here it is:
C:\oreyes\cosas\java\interfaces>type a\*.java
a\Inter.java
package a;
interface Inter {
public void face();
}
a\Face.java
package a;
class Face implements Inter {
public void face() {
System.out.println( "face" );
}
}
C:\oreyes\cosas\java\interfaces>type b\*.java
b\Test.java
package b;
import a.Inter;
import a.Face;
public class Test {
public static void main( String [] args ) {
Inter inter = new Face();
inter.face();
}
}
C:\oreyes\cosas\java\interfaces>javac -d . a\*.java b\Test.java
b\Test.java:2: a.Inter is not public in a; cannot be accessed from outside package
import a.Inter;
^
b\Test.java:3: a.Face is not public in a; cannot be accessed from outside package
import a.Face;
^
b\Test.java:7: cannot find symbol
symbol : class Inter
location: class b.Test
Inter inter = new Face();
^
b\Test.java:7: cannot find symbol
symbol : class Face
location: class b.Test
Inter inter = new Face();
^
4 errors
C:\oreyes\cosas\java\interfaces>
Hence, achieving what you wanted, prevent interface and class usage outside of the package.
Here's how it could be done using abstract classes.
The only inconvenient is that it makes you "subclass".
As per the java guide, you should follow that advice "most" of the times, but I think in this situation it will be ok.
public abstract class Ab {
protected abstract void method();
abstract void otherMethod();
public static void main( String [] args ) {
Ab a = new AbImpl();
a.method();
a.otherMethod();
}
}
class AbImpl extends Ab {
protected void method(){
System.out.println( "method invoked from: " + this.getClass().getName() );
}
void otherMethod(){
System.out.println("This time \"default\" access from: " + this.getClass().getName() );
}
}
Here's another solution, inspired by the C++ Pimpl idiom.
If you want to implement an interface, but don't want that implementation to be public, you can create a composed object of an anonymous inner class that implements the interface.
Here's an example. Let's say you have this interface:
public interface Iface {
public void doSomething();
}
You create an object of the Iface type, and put your implementation in there:
public class IfaceUser {
private int someValue;
// Here's our implementor
private Iface impl = new Iface() {
public void doSomething() {
someValue++;
}
};
}
Whenever you need to invoke doSomething(), you invoke it on your composed impl object.
I just came across this trying to build a protected method with the intention of it only being used in a test case. I wanted to delete test data that I had stuffed into a DB table. In any case I was inspired by #Karl Giesing's post. Unfortunately it did not work. I did figure a way to make it work using a protected inner class.
The interface:
package foo;
interface SomeProtectedFoo {
int doSomeFoo();
}
Then the inner class defined as protected in public class:
package foo;
public class MyFoo implements SomePublicFoo {
// public stuff
protected class ProtectedFoo implements SomeProtectedFoo {
public int doSomeFoo() { ... }
}
protected ProtectedFoo pFoo;
protected ProtectedFoo gimmeFoo() {
return new ProtectedFoo();
}
}
You can then access the protected method only from other classes in the same package, as my test code was as show:
package foo;
public class FooTest {
MyFoo myFoo = new MyFoo();
void doProtectedFoo() {
myFoo.pFoo = myFoo.gimmeFoo();
myFoo.pFoo.doSomeFoo();
}
}
A little late for the original poster, but hey, I just found it. :D
You can go with encapsulation instead of inheritance.
That is, create your class (which won't inherit anything) and in it, have an instance of the object you want to extend.
Then you can expose only what you want.
The obvious disadvantage of this is that you must explicitly pass-through methods for everything you want exposed. And it won't be a subclass...
I would just create an abstract class. There is no harm in it.
With an interface you want to define methods that can be exposed by a variety of implementing classes.
Having an interface with protected methods just wouldn't serve that purpose.
I am guessing your problem can be solved by redesigning your class hierarchy.
One way to get around this is (depending on the situation) to just make an anonymous inner class that implements the interface that has protected or private scope. For example:
public class Foo {
interface Callback {
void hiddenMethod();
}
public Foo(Callback callback) {
}
}
Then in the user of Foo:
public class Bar {
private Foo.Callback callback = new Foo.Callback() {
#Override public void hiddenMethod() { ... }
};
private Foo foo = new Foo(callback);
}
This saves you from having the following:
public class Bar implements Foo.Callback {
private Foo foo = new Foo(this);
// uh-oh! the method is public!
#Override public void hiddenMethod() { ... }
}
I think u can use it now with Java 9 release. From the openJdk notes for Java 9,
Support for private methods in interfaces was briefly in consideration
for inclusion in Java SE 8 as part of the effort to add support for
Lambda Expressions, but was withdrawn to enable better focus on higher
priority tasks for Java SE 8. It is now proposed that support for
private interface methods be undertaken thereby enabling non abstract
methods of an interface to share code between them.
refer https://bugs.openjdk.java.net/browse/JDK-8071453