Community
Participate
Working Groups
fully qualified names contain '/' instead of '.' from bug 8731 Test Case: Create a class that implements IAdapterFactory Select getAdapter(...) and try to modify method parameters. In the error message I get, the method is called 'java/lang/Object getAdapter (java/lang/Object adaptableObject, java/lang/Class adapterType)'. The fully qualified names, especially for classes like Object and Class, make it hard to recognize the method. But in any case the '/' should be replaced with the usual '.'
simpler test case is to create a class that implements java.util.List, override methods, select addAll(int arg0, Collection arg1) and 'modify parameters' the problem comes from Signature.toString(String methodSignature, String methodName, String[] parameterNames, boolean fullyQualifyTypeNames, boolean includeReturnType) i call it with: (ILjava/util/Collection;)Z addAll [arg0, arg1] false true and it returns: boolean addAll(int arg0, java.util.Collection arg1) and not the expected boolean addAll(int arg0, Collection arg1) another thing - by looking at code in Signature.toString it seems that it ignores the fullyQualifyTypeNames for the return type (running this test case on the subList(int, int) method confirms it)
In all examples the '/' is never used. You should call it with: (ILjava.util.Collection;)Z addAll [arg0, arg1] false true And then you will get the expected result. Should we handle the '/' to '.' conversion inside the Signature methods?
I fixed the problem for fully qualified name in the return type and added regression tests, but I don't think we should handle '/' internally.
the '/' is returned by jcore itself here's what i call (is this code a resonable use of jcore api?): String sig= Signature.toString(method.getSignature(), method.getElementName(), method.getParameterNames(), false, true); should i really be converting '/' to '.' myself? for me, as a client of that api the '/' thing is only an implementation detail
For now the specification of the Signature methods will specified they are dot-based and not /- based. Then it is up to the client to do the conversion and ensure that '.' are used instead of '/'.
Specifications of Signature methods is updated to specified they are always dot-based. Fixed and released in HEAD.
