Generic method signature help

Hello All,
I'm confused about the following generic method signature . Compilation fails
public class Animal{}
public class Dog extends Animal{}
public <E super Dog> List<E> methodABC(List<E> list){
The compiler gives the following error
E cannot be resolved to a type
E cannot be resolved to a type
Syntax error on token "super", , expected
if i change the declaration of E to <E extends Dog>, no compiler error.
An early response will be highly appreciated. Thanks in advance.
Kind Regards.
Hasnain Javed Khan.

you cannot use "super" on a type variable, only on wildcards

Similar Messages

Generic method signatures

I've searched but can't find that a question I have has been asked (or answered). I apologize in advance if it has. Here is my question.
In Java Generics FAQ by Angelika Langer states in FAQ 802 ( [http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#FAQ802] ) "the type parameters of a generic method including the type parameter bounds are part of the method signature."
In FAQ 810, many examples are presented of method declarations, including generic ones, and their corresponding method signatures. For example,
<T> T method(T arg) has the following signature in the example:
<$T1_extends_Object>method($T1_extends_Object>)
It would seem to be intuitively clear that the type parameter and bounds would be part of the method signature but I can't seem to find such a stipulation/requirement of such in the Java Language Specification. Anybody know where it's stipulated in the JLS?
Best Regards

user13143654 wrote:
Yeah, I know. The title of the subsection is "Determining Method Signature," but then it never seems to expressly do that other than in some ephemeral wafting byproduct of overload resolution.I wouldn't call it "ephemeral" and "wafting." It's pretty specific. If you're looking for the $T1_extends_Object notation, you won't find it. That's not part of the spec.
I can't seem to find a specific spot in the subsection where I can say "OK, now I've got the method signature and now can proceed to ..." Well, it goes on to Phase 3, and then on to 15.12.2.5 Choosing the Most Specific Method. I'm not sure what you're looking for. It does describe in detail how we get from all the methods in the universe, to which type's methods we'll be considering to which signatures could match to which one is the best match. I don't know what else you're looking for.
If you're looking for somebody to digest, translate, and simplify all that for you, good luck, but it ain't gonna be me. :-)
If you have specific questions about smaller pieces of it I (or somebody else) might be able to help out. At the moment though, your question is rather vague.
Edited by: jverd on May 3, 2011 1:48 PM

Problems deploying application with updated method signatures on WLS8.1

Hi,
I have an jar file under applications which I have deployed fine on WLS 8.1 in the past. I changed the method signature on one of the EJB classes in the jar. One of the parameters now takes a different Java class type. I have recompiled everyone and repackaged the jar but when I try to deploy the jar it gives me an error because the the local interface of the EJB does not have the old Java class parameter type.
I have checked the jar, classes in the jar, and the ejb-jar.xml and weblogic-ejb-jar.xml in the jar and it is looks fine. I have cleaned out my server deployment directories and verified the classpath in case the older jar was in there and everything looks OK. It seems for some reason 8.1 is caching the old ejb-jar.xml or somehow is remembering the old method signature and will not process the updated jar. Has anyone seen anything like this?
Thanks for any help or recommendations

Can you show me the error you receive?
Another simple test would be to deploy your application to a new, empty
server.
You can create a new domain as easy as this:
mkdir testDomain;
cd testDomain;
java weblogic.Server
Type in the username/password that you want and answer 'Yes' when it
asks if you want to create a new domain.
Try deploying your jar to this new domain, and let me know if it still
fails.
-- Rob
Jeff Dooley wrote:
Hi,
I have an jar file under applications which I have deployed fine on WLS 8.1 in the past. I changed the method signature on one of the EJB classes in the jar. One of the parameters now takes a different Java class type. I have recompiled everyone and repackaged the jar but when I try to deploy the jar it gives me an error because the the local interface of the EJB does not have the old Java class parameter type.
I have checked the jar, classes in the jar, and the ejb-jar.xml and weblogic-ejb-jar.xml in the jar and it is looks fine. I have cleaned out my server deployment directories and verified the classpath in case the older jar was in there and everything looks OK. It seems for some reason 8.1 is caching the old ejb-jar.xml or somehow is remembering the old method signature and will not process the updated jar. Has anyone seen anything like this?
Thanks for any help or recommendations

Generic Method override compatibility

I tried to find references to the problem but couldn't. I face it all the time and I thought some else must have had the same problem already.
Oh well, here it goes.
With both 3.1M4 and 3.1M5a the following code compiles without any problems.
public interface MyIface {
    public <T> void foo(T p);
public class MyClass implements MyIface{
    public <T extends Integer> void foo(T p) {
         //does something
}However, javac 1.5 gives me:
MyClass.java:1: MyClass is not abstract and does not override abstract method <T>foo(T) in MyIface
public class MyClass implements MyIface{
^
1 error
I found many different variations to this problem, which I am not going to list here as I am trying to be concise. But for the eclipse compiler, <T extends Integer> is the same as <T> in terms of method signature. For the javac compiler these are different thingss.
Does anyone know if this is a Bug in eclipse or javac, or if this is a known decision, which is taking both tools in different directions?
Coconha

Coco, you have to understand how generics work in the compiler to understand this. Basically, erasure means that all the fancy generics stuff you write in your source code gets 'erased' when it gets compiled... So:public interface MyIface {
    public <T> void foo(T p);
}gets compiled and the resulting .class file, if you decompiled it, would actually look like this:public interface MyIface {
    public void foo(Object p); // NOTICE that "T" gets erased to plain old java.lang.Object
}See? The same thing happens with MyClass:public class MyClass implements MyIface {
    public <T extends Integer> void foo(T p) {
         //does something
}after it's compiled, actually looks like this inside the .class file:public class MyClass implements MyIface {
    public void foo(Integer p) { // NOTICE that "T extends Integer" gets erased to plain old Integer!
         //does something
}Do you see what the problem is now? MyClass has a method called foo(Integer) and MyIface has a method called foo(Object). Obviously now, you see, foo(Integer) shouldn't override foo(Object). The Eclipse compiler should actually complain that you haven't implemented foo(Object) in MyClass. Do you follow?
Let's look at your second example.public class Base {
public <S> void foo(S a) {
    System.out.println("Base: " + a);
public class Sub extends Base {
public <S extends Integer> void foo(S a) {
    super.foo(a); // should be an error here! super.foo(Integer) doesn't exist!
    System.out.println("Sub: " + a);
}Let's apply erasure manually and see why there is no error:public class Base {
public void foo(Object a) {
    System.out.println("Base: " + a);
public class Sub extends Base {
public void foo(Integer a) {
    super.foo(a); // calls foo(Object a)! you could also write "this.foo((Object)a)"
    System.out.println("Sub: " + a);
}Sub actually has two methods - foo(Integer a) which it defines explicitly - and foo(Object a) which it inherits from Base.

Changing exception clause in method signature when overwriting a method

Hi,
I stumbled upon a situation by accident and am not really clear on the details surrounding it. A short description:
Say there is some API with interfaces Foo and Bar as follows:
public interface Foo {
   void test() throws Exception;
public interface Bar extends Foo {
   void test();
}Now, I find it strange that method test() for interface Bar does not need to define Exception in its throws clause. When I first started with Java I was using Java 1.4.2; I now use Java 1.6. I cannot remember ever reading about this before and I have been unable to find an explanation or tutorial on how (or why) this works.
Consider a more practical example:
Say there is an API that uses RMI and defines interfaces as follwows:
public interface RemoteHelper extends Remote {
   public Object select(int uid) throws RemoteException;
public interface LocalHelper extends RemoteHelper {
   public Object select(int uid);
}As per the RMI spec every method defined in a Remote interface must define RemoteException in its throws clause. The LocalHelper cannot be exported remotely (this will fail at runtime due to select() in LocalHelper not having RemoteException in its clause if I remember correctly).
However, an implementing class for LocalHelper could represent a wrapper class for RemoteHelper, like this:
public class Helper implements LocalHelper {
   private final RemoteHelper helper;
   public Helper(RemoteHelper helper) {
      this.helper = helper;
   public Object select(int id) {
      try {
         return (this.helper.select(id));
      } catch(RemoteException e) {
         // invoke app failure mechanism
}This can uncouple an app from RMI dependancy. In more practical words: consider a webapp that contains two Servlets: a "startup" servlet and an "invocation" servlet. The startup servlet does nothing (always returns Method Not Allowed, default behaviour of HttpServlet), except locate an RMI Registry upon startup and look up some object bound to it. It can then make this object accessible to other classes through whatever means (i.e. a singleton Engine class).
The invocation servlet does nothing upon startup, but simply calls some method on the previously acquired remote object. However, the invocation servlet does not need to know that the object is remote. Therefore, if the startup servlet wraps the remote object in another object (using the idea described before) then the invocation servlet is effectively removed from the RMI dependancy. The wrapper class can invoke some sort of failure mechanism upon the singleton engine (i.e. removing the remote object from memory) and optionally throw some other (optionally checked) exception (i.e. IllegalStateException) to the invocation servlet.
In this way, the invocation servlet is not bound to RMI, there can be a single point where RemoteExceptions are handled and an unchecked exception (i.e. IllegalStateException) can be handled by the Servlet API through an exception error page, displaying a "Service Unavailable" message.
Sorry for all this extensive text; I just typed out some thoughts. In short, my question is how and why can the throws clause change when overwriting a method? It's nothing I need though, except for the clarity (e.g. is this a bad practice to do?) and was more of an observation than a question.
PS: Unless I'm mistaken, this is basically called the "Adapter" or "Bridge" (not sure which one it is) pattern (or a close adaptation to it) right (where one class is written to provide access to another class where the method signature is different)?
Thanks for reading,
Yuthura

Yuthura wrote:
I know it may throw any checked exception, but I'm pretty certain that an interface that extends java.rmi.Remote must include at least java.rmi.RemoteException in its throws clause (unless the spec has changed in Java 1.5/1.6).No.
A method can always throw fewer exceptions than the one it's overriding. RMI has nothing to do with it.
See Deitel & Deilte Advanced Java 2 Platform How To Program, 1st Ed. (ISBN 0-13-089650-1), page 793 (sorry, I couldn't find the RMI spec quick enough). Quote: "Each method in a Remote interface must have a throws clause that indicates that the method can throw RemoteException".Which means that there's always a possibility of RemoteException being thrown. That's a different issue. It's not becusae the parent class can throw RE. Rather, it's because some step that will always be followed is declared to throw RE.
I later also noticed I could not add other checked exceptions, which made sense indeed. Your explanation made perfect sense now that I heard (read) it. But just to humour my curousity, has this always been possible? Yes, Java has always worked that way.
PS: The overwriting/-riding was a grammatical typo (English is not my native language), but I meant to say what you said.No problem. Minor detail. It's a common mistake, but I always try to encourage proper terminology.

Dynamic method signatures

This does not compile:
public class Main {
public static void main(String[] args) {
    Object sok = Socket.class.newInstance();
    foo(sok); // syntax error only as help to prevent runtime errors?
    Object x = ArrayList.class.newInstance();
    foo(x); // syntax error because method linkage must happen and i don't know the class of "x" yet.
public static void foo(Socket s) { println("i am a socket"); }
public static void foo(List l) { println("i am a list"); }
}Is the compiler complaining only to prevent a possible runtime (typecast) error? Or, is there actually some real problem (perhaps method linkage)?
I read that methods live in their own special place in memory (and each has an address)? And is that address inserted into the bytecode when the Java source is compiled? So, while in the runtime every object knows its type, and this would enable selection of the correct method, you can't wait because of the need for compile-time method linking? Or, while waiting is technically possible, you can't because the developers of Java wanted to help developers to minimize run-time errors.
If this question makes no sense, please help clear-up my misunderstanding about method linkage. thanks.

dpxqb wrote:
It only cares about the reference type of the expression you pass to foo(expression), which is Object for both cases.awesome. So, I hope this means that the "type" of the concrete object is not relevant for method signature. Rather, it is the "type" of the reference .Correct. I believe it's common to say class when talking about the concrete runtime object, and "type" when talking about the compile-time reference.
And "reference typing" (aka "casting") happens at compile-time while "object typing" happens in the run-time.Yes and no. Your terminology is non-standard, so I'm not sure exactly what you mean, but approximately, yes, references types matter at compile time and object classes matter at runtime (for polymorphism in overridden methods, for example).
Casting is both a compile-time and a runtime operation, however. At compile time, the reference type has to be one that could possibly be cast to whatever the target type is, and at runtime, the actual object has to be of an appropriate class for the cast to succeed.
String s1 = (String)new Date(); // compile time error can't cast "across" the hierarchy
String s2 = (String)new Object(); // compiles fine, but ClassCastException at runtime
Object o1 = "abc";
String s3 = (String)o1; // success

How do I gain type safety with a generic method taking a class object?

How do I achieve type safety with the following code without getting a compile error?
import java.util.ArrayList;
import java.util.List;
public class Main {
    public static void main(String[] args) throws Exception {
        ListenerHolder th = new ListenerHolder();
        List<TestObject<String>> list = createTestObjectList();
        /* *** compiler error here *** */
        th.addListener(TestObject.class, list);
    private final static List<TestObject<String>> createTestObjectList() {
        List<TestObject<String>> list = new ArrayList<TestObject<String>>();
        return list;
    private final static class ListenerHolder {
            /* *** my generic method *** */
            public <T> void addListener(Class<T> listenerType, List<T> listener) { }
    private final static class TestObject<T> { }
}The compiler error is:
C:\java\Main.java:11: <T>addListener(java.lang.Class<T>,java.util.List<T>) in Main.ListenerHolder cannot be applied to (java.lang.Class<Main.TestObject>,java.util.List<Main.TestObject<java.lang.String>>)
Thanks in advance,
Dan

dandubois wrote:
Thanks for the help, that is exactly what I wanted to know.
It didn't occur to me that TestObject<T> would in some respects be considered as an 'extends' of TestObject as I know the compiler converts them all back to plain TestObjects.Maybe I should have written TestObject<?>, to make it more obvious. There's some supertype/subtype relation diagram in the Generics FAQ somewhere, if you need more detailed information.
In the end, I think jtahlborn's solution might be more appropriate in the described scenario, so you should go for it.

Detecting webservice methods signatures

Hi,
I'm searching for an elegant solution for the following problem:
My application is a webservice client that will consume a webservice with some methods.
let's suppose service interface has methods :
public void methodA(String A, String B, String C);
public void methodB(String D, String B, String E);my application will parse a String stream and figure out what method to call .if for example the string pattern is : methodA:A,valueA:B,valueB:C,valueC;then i'll need to call method :public void methodA(String A, String B, String C);I need to know what is an elegant and clean why to implement this feature. Note that i don't know the webservice methods signatures in advance!
I guess i'll have to use java Reflection. I'm not sure what is a good solution for this problem .
thanks for your help.
NB: I posted this same topic at [coderanche.com|http://www.coderanch.com/t/441073/Web-Services/java/detecting-webservice-methods-signatures] but couldn't get responses.

slowfly wrote:
That is imo a very bad idea. That's no java problem, it's a communication problem. If the service providers can't provide you the interface or the wsdl, you can't code towards it. They also should provide you a test-environment, where you can test your client implementations. Everything else is just... not right...
I'm just curious: Where comes the string stream from? And why don't you know the endpoint interface? There must be another approach.
regards
slowflythe webservice client i'm coding is part of a complex system with many components communicating through JMS and using Spring Managed beans.
my plug-in will receive a command from an external provisioning system. i'll have to parse this command string then figure out what webservice method i'll need to call on remote webservice.
i know this is weired. but my boss is not helpful. he can't yet get the WSDL from the customer and I have now to manage testing with dummy webservice methods without actually talking to real webservice.
I want to know what is a good solution to Map the above String command Pattern into a java method . it seems like to be a Mapping from String Pattern to java method with arguments. the only problem is that i can't know the names of method parameters.and the command string pattern might contains method args in un-ordered state. so after collecting the method args (from command) i will need to figure out which one fits in the args list of webservice method.
probably using method parameters annotations? does this means the WSDL should also contain the parameter annotaions?
anyway i hope someone here can suggest me some good solution.
thanks

Interface method Signature...

Hi all,
Is there any Function Module that can be used to modify
the signature of a method in an interface from code??
I want to write a FM that imports the interface and
method name and changes the method signature..
Pls Help.
Thanks in advance.

Here is a sample program which will give you thep signature of the class/methods.    I'm not sure how to update them, or if it is a good idea to do so.
report zrich_0003.
data: l_dref type ref to cl_abap_typedescr.
data: l_clref type ref to cl_abap_classdescr.
data: x_methods type abap_methdescr.
data: x_parameters type abap_parmdescr.
constants: query_class type seoclsname
                    value 'CL_GUI_ALV_GRID'.
* check if query_class exists in the current system
call method cl_abap_classdescr=>describe_by_name
exporting
    p_name         = query_class
receiving
      p_descr_ref = l_dref
exceptions
    type_not_found = 1
    others         = 2.
if sy-subrc <> 0.
exit.
endif.
l_clref ?= l_dref.
loop at l_clref->methods into x_methods.
write:/ x_methods-name.
loop at x_methods-parameters into x_parameters.
    write:/     x_parameters-length,
        x_parameters-decimals,
        x_parameters-type_kind,
        x_parameters-name,
        x_parameters-parm_kind     .
endloop.
skip 3.
endloop.
Regards,
Rich Heilman

Parsing java source files - identifying method signature

Im doing a project in which i need to parse java source file and identifying java method signature to take the methods parameters name as tokens, does anyone know how to do this with regular expression? I really appreciate your help.
regards,
gr33nl1nk

i'm still working on it, but still doesn't work :'(
// Regular expression used to find the result type and the name of a method
//String s1 = "\\s-*\$\\(public\\|protected\\|private\\|const\\|abstract\\|synchronized\\|final\\|static\\|threadsafe\\|transient\\|native\\|volatile\$\\s-+\\)*\$.*\$";
String s1 = "\\s-*((public|protected|private|const|abstract|synchronized|final|static|threadsafe|transient|native|volatile)\\s-+)*\$.*\$";
// Regular expression used to find the method arguments
String s2 = "([ ]*\$.*\$[ ]*)";
// Regular expression used to find the method exceptions.
String s3 = "throws[ ]+\$.*\$[ ]*[{;]";
// Regular expression for white spaces separator
String sp = "[ \t\r\n]+";
//String mspat = s1+sp+s2;
String mspat = s1;
compile(mspat);

Are bridge methods generated for generic methods?

I've recently come across the notion of bridge methods. They provide type safety while allowing for erasure. However, the only places where they've been mentioned is with your class extending a parameterized type. That is the only case mentioned with bridge methods in the JLS as well as:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#Under which circumstances is a bridge method generated?
So I've been wondering about generic methods. For example, Collections.max's signature looks like the following in the source:
public static <T extends Object & Comparable<? super T>> T max(Collection<T> coll)
and after erasure:
public static Object max(Collection coll)
However, one cannot simply pass any type of Collection to the max method, it must implement Comparable and whatnot. Therefore, my question is how does it do that? Mustn't there be some sort of bridge method or generic information in the class file? Else how can the compiler, by just looking at the erasure of generic methods, check type safety, do capture conversion, type inference, etc?

Generic information is erased from the byte code. It is still there in the class file in the method signatures. That's how the compiler knows.

Java.lang.AssertionError: Can not find generic method public abstract

I just downloaded the JDev 11g and trying to test the JEE web app. Below is my install:
JDeveloper 11g
JEE Web Project
EJB 3.0
Steps taken:
1. Created an entity bean from a table.
2. Created a session facade
3. Create sample Java client to use the facade (Right-click on the session facade, and choose New sample Java Client from the context menu)
4. Run the session facade
5. Run the Java client
I got the following error.
java.lang.AssertionError: Can not find generic method public abstract java.util.List<com.oracle.orm.model.ejb.persistence.Hosttags> queryHosttagsFindAll() in EJB Object
I checked the methods in the beans and interfaces, they are all there. Any idea?
Thanks.

I have a customer that has this problem.
We wrote me that:
we got a java.lang.NoSuchMethodException while the method exist even in the generated (by WLS) stub.
when we change the interface by putting a "list" instead of list <> then it works.
hope it can help, but should be great know why.
Regards
Marco
글 수정: user10649412

500 Invalid method signature

Hi,
Can somebody help me out?
Getting the following error in the code:
500 Invalid method signature: t;)Ljava/lang/Object;
Invalid method signature: t;)Ljava/lang/Object;
Don't have any clue to fix this issue. Please help me.
Coldfusion version : 6
database : sql server.
Thanks,
Satheesh.

See how the above method is self explaining. Yes, returning an array is more self explanatory. Are you defensively copying the array?
For classes that are to be re-used often by other developers would it be better to use arrays because they are more obvious? It depends. Yes its more obvious but if folks are going to stick the array contents into a Collection then returning a Collection is nice, too.
How do other people deal with this or do you just not worry about it and leave it up to the comments to explain?Thats what javadoc is for. i.e. @return a List of EmailTo objects
In jdk1.5 templates will help with this a bit.
One of the most painful bugs you will encounter is when you don't make defensive copies of objects and another class mutates an internal data structure. Of course, defensive copies waste object references and in some cases, can really cause a slow down. You can always provide access via ye old getNumberOfFollowUpEmails/getFollowUpEmail(int i)
Ian

Reflection cant get parameterized method signature?

my sample:
interface Root<T>{
public void prt(T t );
interface A extends Root<String>{
public class Reflecttest {
public static void main(String[] args){
Class cl=A.class;
for (Method m:cl.getMethods()){
m.getParameterTypes();
//som reflection like above, but i cant get signature like public void prt(String str); but public void prt(Object o);
//how can i get the parameterized method signature
}

That information doesn't exist at runtime. It is all
erased to Object by the compiler. That's what
Generics does - safe type erasurefurther, you don't need to know, since by using reflection you're basically bypassing compile-time type safety altogether. reflection and generics have totally different intents, and don't mix well together

Method signature - ideas

Look at this method signature:
public ArrayList getFollowUpEmails() throws Exception{}
This ArraysList contains several EmailTO transfer objects - but I had to tell you this. Now look at this signature:
public EmailTO[] getFollowUpEmails() throws Exception{}
See how the above method is self explaining. For classes that are to be re-used often by other developers would it be better to use arrays because they are more obvious? How do other people deal with this or do you just not worry about it and leave it up to the comments to explain?

See how the above method is self explaining. Yes, returning an array is more self explanatory. Are you defensively copying the array?
For classes that are to be re-used often by other developers would it be better to use arrays because they are more obvious? It depends. Yes its more obvious but if folks are going to stick the array contents into a Collection then returning a Collection is nice, too.
How do other people deal with this or do you just not worry about it and leave it up to the comments to explain?Thats what javadoc is for. i.e. @return a List of EmailTo objects
In jdk1.5 templates will help with this a bit.
One of the most painful bugs you will encounter is when you don't make defensive copies of objects and another class mutates an internal data structure. Of course, defensive copies waste object references and in some cases, can really cause a slow down. You can always provide access via ye old getNumberOfFollowUpEmails/getFollowUpEmail(int i)
Ian

Generic method signature help

Similar Messages

Maybe you are looking for