Covariant return types without "-source 1.5"

Hello all,
I've just noticed that one can compile code that makes use of covariant return types even without specifying the flag -source 1.5.
Just out of curiosity: Was that behvaiour of javac intentional?
What's more, if you compile it with target 1.4
you can even run it with a 1.4 JRE!
Great, ain't it?

I've just noticed that one can compile code thatmakes use of covariant return types even without
specifying
the flag -source 1.5.
Very interesting, actually it runs on jdk 1.3.1 too.
Actually using -target 1.4 or -target 1.3 generated the sameclass file in a small example (with the exception of the version number). And this class file contains 2 method entry per covariant(ed) method. One method with the return type specified in the source code and a second method with the return type of the base class. The second method is of synthetic and has a virtual call to the the this method.
with -target 1.5 you also get both method entries, but the second one is not synthetic anymore (??).

Similar Messages

Covariant return types - JLS to support but JVM will not?

Could you please confirm the following? My understanding is that covariant return types will be supported by the JLS but the JVM will know nothing about them. That is, the invokevirtual instruction will not change to support covariant return types but rather the compiler will use bridge methods to simulate support. Is this correct?

Right: but is there support for this in 1.5?
javac -verbose -source 1.5 -target 1.5 *java
was run on a .java file with the following methods and it failed "getX already defined"
public Integer getX() {
return(null);
public String getX() {
return(null);
The above would be overloading by return type and fails to compile.
================
class A {
Exception f() {}
class B extends A {
BindException f() {} // overload or override?
The above would be covariant returns and works just fine right?

Covariant return types over Generic return types.

Feeling rather slow on the uptake having only just discovered covariant return types (thanks again cowwoc), I've been looking over one of our soon to be released APIs and think using covariants makes muchos sense for it but there's one issue:
public interface Foo {
     Foo get();
public interface Bar {
     Bar get();
public interface FooBar
          extends Foo, Bar {
     FooBar get();
}Which isn't allowed, as the compiler states the return types are incompatible (I think incorrectly as it's been further overridden). Its generic equivalent is:
public interface FooX<T> {
     T get();
public interface BarX<T> {
     T get();
public interface FooBarX
          extends FooX<FooBarX>, BarX<FooBarX> {
     FooBarX get();
}Which works, and well, but the extra hassle of declaring/using generics is turning out to be a pain for our users (this pattern is used extensively). Does anyone have any simple suggestions/recommendations to resolve either the covariant issue or simplify the generics one? Also does anyone have any preferences to which one they prefer (and why)?
Incidentally does anyone know the the rationale behind not allowing the first example, when clearly it can't be abused (can it)?

BobDavies wrote:
. it is because you can not override a method or its definition with the same signatur, which does not include return type.What do you mean "does not include return type"?
method signature does not count the return type. i think java does allow you to repeat definitions in a sub class but when you put up a different retyrn type, it sees it as an attempt to do overriding, so it flags it out.
the fact that it works is becuase you are not extending anything but itsself:I am aware of the reasons for the Generic version working, it achieves our aim, I just don't like it when in use. And was wondering why the joining covariants do not work. I still can't see the reason for the FooBar not being allowed when you are allowed to return subtypes. You cannot break the inheritance/return types expectations like this can you? E.g. if I write a bit of code using Foo, it will still work with FooBar, and the same with Bar using FooBar, no? Can you show me an example of why this isn't allowed?your generic version should NOT work either; it is working becuase you are confused:
public interface FooBarX extends FooX<FooBarX>, BarX<FooBarX> only equals to
public interface FooBarX extends FooBarX, FooBarX

Covariant Return Types - J2SE 5.0

I just read the tech tip regarding the new covariant return types in j2se 5.0
In the doc, it said that you can now compile two methods with the same signature but with different return types. I was wondering if anyone knew how this would affect what the following expression returns: anObject.getClass().getMethod(aMethodNameString, aClassArray)
If there are two methods with the same signature except for the return type, how does the above expression know which method to return?

Never mind, I just found my answer in the javadoc....
"To find a matching method in a class C: If C declares exactly one public method with the specified name and exactly the same formal parameter types, that is the method reflected. If more than one such method is found in C, and one of these methods has a return type that is more specific than any of the others, that method is reflected; otherwise one of the methods is chosen arbitrarily. "

JCP Submission to add covariant return types

What would be involved in getting to gether to submit a formal JCP to enable covariant return types?
AFAIK, the changes are:
1) the language spec
2) the JVM Spec
3) changes to the compiler code
4) changes to the class file verifier in the JVM code
And that should be it. Who wants to organise this?

My understanding is that the current generics proposal already includes covariant return types.

Covariant return types in interfaces

Hi,
I was trying this small code snippet to understand covariant returns but when I tried compiling it I get errors saying that I must implement the interfaces. I'm in a bit of a puzzle because I believe that I have implemented them correctly. Can anyone please help me out of this problem....
interface I1 { Number f(); }
interface I2 { Number f(Number i); }
interface I3 { int f(); }
class C {
     public Number f() { return 1; }
class C2 implements I1, I2 {
     public Integer f() { return 1; }
     public Integer f(Float i) { return 1; }
class C3 extends C implements I2 {
     public Float f(Integer i) { return (float) 1; }
class C4 extends C implements I3 {
     public int f() { return 1; }
Any help is greatly appreciated.

1. I want to know why varying the parameter types doesnot work when overriding functionsBecause it is a contradiction in terms. Either you are varying the parameter types or you are overriding the method. You cannot do both.
because in my example code I am trying to pass an Integer object type to Number.But you can do that without changing the formal argument types.
I feel it should work because I am doing a widening conversion from a sub-type to a super-type.The widening conversion works. The 'override' doesn't, because it isn't an override. You aren't getting an error about type widening, you are getting an error about not implementing the method you aren't over-riding correctly.
According to me I am trying to vary the return type of f () from classAnd you are doing that. However you are not staying within the rules specified in the JLS section I cited, which you are required to do when over-riding a method. So you get a compilation error.

Covariant return types and reflection

I have TextControl which extends AbstractValueControl, which has this method:
public ValueModel getModel() {return (ValueModel)super.getModel();}AbstractValueControl extends AbstractControl, which has:
public ControlModel getModel() {return (ControlModel)super.getModel();}AbstractControl extends AbstractComponent, which has:
public Model getModel() {return model;}(The models are all interfaces.)
So at runtime I'm enumerating the methods of TextControl.class using reflection, and the Method for getModel() indicates a return type of ControlModel!
Reflection must recognize covariance, or the return type would indicate simply Model. but TextControl extends AbstractValueControl, so I would expect (and desire) the return type to be ValueModel. Why isn't this the case?
Thanks,
Garret

So at runtime I'm enumerating the methods of
TextControl.class using reflection, and the Method
for getModel() indicates a return type of
ControlModel!
Reflection must recognize covariance, or the return
type would indicate simply Model. but TextControl
extends AbstractValueControl, so I would expect (and
desire) the return type to be ValueModel. Why isn't
this the case?Because you're enumerating the methods in random order! (See the JavaDoc for Class.getMethods()).
If you're lucky, you'll encounter the "correct" version of getModel first, if not, you'll get to the compiler-generated bridge-method with the same name first.
You need to filter out the compiler-generated methods using Method.isSynthetic(). There should be only one getModel in each class where isSynthetic == false

Tricky Generics problem covariant return types

Consider the following classes
class A {
class B extends A {
class C {
public <T extends A> T foo(Class<T> cls) {
System.out.println("A");
return null;
class D extends C {
public <T extends B> T foo(Class<T> cls) {
System.out.println("B");
return null;
public static void main(String[] args) {
D d = new D();
d.foo(B.class);
This will print "B" as one would expect. But if change main() to be like this:
C d = new D();
d.foo(B.class);
Then it will print "A". In other words, public <T extends B> T foo(Class<T> cls) does not override public <T extends A> T foo(Class<T> cls)
Rather dangerously apparently, the method that gets called doesn't depend on the object type but upon the variable type holding the reference. No dynamic binding.
Can anyone explain to me the logic of why <T extends B> shouldn't be a covariant subclass of <T extends A> and thus be overriding the superclass method?

Hello chrisbitmead,
what should the following print?
C d = new D();
d.foo(A.class);If D.<T extends B>foo(Class<T>) overrode C.<T extends A>foo(Class<T>) it would print B, even though A.class does fall within the required bounds.
With kind regards
Ben

The class of the deferred-methods return type "{0}" can not be found.

I am developing a multilingual portal application.
I have the method that changes the locale based on user's choice in the bean and the method is being referred to as below.
<af:selectOneChoice label="Select Language" autoSubmit="true"
value="#{localeBean.locale}"
valueChangeListener="localeBean.changeLocale">
<af:selectItem label="English" value="en" id="si1"/>
<af:selectItem label="French" value="fr" id="si2"/>
<af:selectItem label="Dutch" value="nl" id="si3"/>
</af:selectOneChoice>
when i try to run the application, i am getting compile time errors as below,
The class of the deferred-methods return type "{0}" can not be found.
No property editor found for the bean "javax.el.MethodExpression".
After going through the discussion forums i learned that the compilation errors can be resolved by setting the <jsp:directive.page deferredSyntaxAllowedAsLiteral="false> at the starting of the page.
Even after that i am getting the compilation error.
Any solutions, suggestions or possible approaches would be helpful as i am new to Webcenter Portal development.
Thanks,

The error you get points to a problem on the page (somewhere). Switch to source mode and check the right margin if you see orange or red marks. These are pointing to problems (not all are show stoppers, but they give you hints that something is not according to the standard for jsf, jsff, jsp or jspx pages.
Have you checked that the bean is correctly defined and that it's reachable?
Start a fresh page and isolate the problem, e.g. build a selectOneChoiuce on the new page (don't copy it as you might copy the error too) and make it work on the new page. Once you have it running you can compare the solution to your not running page.
Timo

Return Delivery without reference

Hi all,
i have one specific query.
i have matl in my stock ( customer returns). i know the vendor code but i don't know the reference doc no of GR posted for that purchase order. I want to send this matl back to vendor without any reference.
I can find out this from ME2L but my requirment is that return delivery without reference. i don't want any reference but return delivery should happen.
plz help as it is very urgent.

There are types of Returns here:
1.Vendor returns against original purchase order
2.Vendor returns through returns purchase order.
For your requirement you can use the second option:
1.If the original purchase order reference is not known, then Purchase Department will prepare a u201CReturn Purchase Orderu201D using T. Code ME21N. Creation of a Return Purchase Order in the system is similar to that of a regular Purchase Order except that the u201CReturns Indicatoru201D has to be ticked for each line item in the PO.
2.Next a goods receipt will have to be done with reference to the Returns PO. Such Goods receipt and Invoice receipt has an exactly reverse effect than that of a Regular PO. Goods Movement Type 161 (T. Code MIGO) is used which reduces the material stock from the Inventory & creates Material and Accounting document
3.If the material is excisable, then Excise Department will create an outgoing Excise Invoice with reference to material document.
4.Next, Invoice Verification is done for a Return PO which creates a reverse liability in the system and the amount appears as u201Crecoverableu201D from the Vendor. FI Team will create a Credit Note through MIRO.
5.If the vendor sends back a substitute delivery after we have returned goods, we can reference the return delivery when we post the goods receipt for substitute items.

Easy way to evaluate a complex return type in adf taskflow

Hi,
I use a method call in adf taskflow where I call a bpel ws . This bpel has a complex return type. I want to evaluate in the taskflow router if STATUS==true . Can this be done with pageflowscope (in the method call , I have a return value) or do I need a methodIterator / accessorIterator in the pagedef.
thanks edwin
<?xml version="1.0" encoding="UTF-8" ?>
<JavaBean xmlns="http://xmlns.oracle.com/adfm/beanmodel" version="11.1.1.47.96"
id="process_Result" Package="nl.ordina.order.view.CreditCheck"
BeanClass="nl.ordina.order.view.CreditCheck.process_Result"
isJavaBased="false">
<Attribute Name="STATUS" IsUpdateable="0" Type="java.lang.Boolean"/>
<Attribute Name="LIMIT" IsUpdateable="0" Type="java.math.BigDecimal"/>
<Attribute Name="REASON" IsUpdateable="0" Type="java.lang.String"/>
</JavaBean>
Here is the methodaction in the pagedef
<methodAction id="process" RequiresUpdateModel="true" Action="invokeMethod"
MethodName="process" IsViewObjectMethod="false"
DataControl="CreditCheck" InstanceName="CreditCheck"
ReturnName="CreditCheck.methodResults.process_CreditCheck_process_result">

nice try,
Unfortunately your method is easily circumvented by either 1.) disabling javascript in the browser preferences or 2.) viewing the source code for the page and clearly seeing the required password or 3.) simply bookmarking and visiting protectpage.html
It may take you 5 mins. to password protect your iweb site by using the method you've described, but it would take a visitor less than a minute to bypass the password protection. You need server-side scripting like php to enable real password protection so that information is processed on the server before the page is loaded.

Is there a way to end a method that has no return type?

Without using an exception, as they are costly I am told, and without using may if then statements, is it possible to end a method if some criteria isn't met.
example.
public void doThis(){
// the method relies on the state of some
// other things.
if(!someBoolean) endHere
// then following is the rest of the method.
// I'd like to be able to do this so that the "meat"
// of the method is located under the conditions
// that must be met.
}... Any thoughts?
Thank You

No need to hide or commit ritual suicide, the "void" keyword could lead you to think that your method can't use the return statement. At least you wrote code to investigate and didn't spend 10 or 20 posts asking for verification. Be aware, some folk will tell you that there should be only one exit point from the method, often this is true. In large methods you can get lost in the execution path if there are multiple exit points. I think it's a judgement call.
As for returning a bogus boolean, but, from a design point of view, if your method really doesn't have anything to return to its caller then the signature should reflect that with a return type of void (I know you are suggesting returning the bogus boolean for a different reason, and you've abandoned the idea anyway, I'm just being pedantic here)(indulge me). Returning a bogus boolean makes the class method more difficult to understand from a design and JavaDoc point of view because I, as the user of your method, will see it returing a boolean and expect to be able to use that value, and it might color my view of what the method does.
Lee

EJB3 Creating Web Services with Complex Return Types

Hi
Not sure if this is the right place, but hoping someone can help!
I have an entity bean that has a collection (list<Address>) of sub-entities. I have then created a session bean to retrieve the Business and populate it's children.
I then expose this as a web service and although it works and I get appropriate XML out, the WSDL of the deployed service is not as I would like.
For example:
The return type is
<complextype name="Business">
<sequence>
<element name="id" type="int"/>
<element name="addresses" type="ns1:list"/>
</sequence>
</complextype>
<complextype name="Address">
<sequence>
<element name="id" type="int"/>
<element name="addresses1" type="string"/>
<element name="addresses2" type="string"/>
<element name="addresses3" type="string"/>
</sequence>
</complextype>
ns1:list is included as a separate schema as a complex extension of the base "collection"
So, even though the Address type is there it is not referenced from Business.
So, when I'm calling the Web Service from BPEL or ESB, I have not got the ability to map adequately back from the response.
I have tried a whole bunch of ways of getting this to work, but so far to no avail...
Has anyone seen this before, or can I somehow override the mapping from the Entity to the WSDL?
Any help would be most appreciated.
Thanks
Chris

Thanks. We are using a Java Proxy to consume the web service as we need to use JAX-WS handlers. We created data control from the service stub that was created by the proxy. Our issue is with the response XML which comes as a complex type. Also, the data control is understanding the complex type and is creating the structure right. The problem is when we drag that control on a JSF page. No data is displayed. We think that we are not traversing the complex object properly which is creating the issue.
I understand that you answer related to the input is applicable to output as well. We can change the structure by flattening it but we thought that in 11G there is some new features where we can use the complex types out of the box without any change. Is that true? Also, any luck in finding the documents (broken links) on your blog page?

Same functions with different return types in C++

Normally the following two functions would be considered the same:
int getdata ( char *s, int i )
long getdata ( char *s, int i )
Every other compiler we use would resolve both of these to the same function. In fact, it is not valid C++ code otherwise.
We include some 3rd party source in our build which sometimes messes with our typedefs causing this to happen. We have accounted for all of the function input types but never had a problem with the return types. I just installed Sun ONE Studio 8, Compiler Collection and it is generating two symbols in our libraries every time this occurs.
Is there a compiler flag I can use to stop it from doing this? I've got over 100 unresolved symbols and I'd rather not go and fix all of them if there is an easier way.

Normally the following two functions would be
considered the same:
int getdata ( char *s, int i )
long getdata ( char *s, int i )Not at all. Types int and long are different types, even if they are implemented the same way.
Reference: C++ Standard, section 3.9.1 paragraph 10.
For example, you can define two functions
void foo(int);
void foo(long);
and they are distinct functions. The function that gets called depends on function overload resolution at the point of the call.
Overloaded functions must differ in the number or the type of at least one parameter. They cannot differ only in the return type. A program that declares or defines two functions that differ only in their return types is invalid and has undefined behavior. Reference: C++ Standard section 13.1, paragraph 2.
The usual way to implement overloaded functions is to encode the scope and the parameter types, and maybe the return type, and attach the encoding to the function name. This technique is known as "name mangling". The compiler generates the same mangled name for the declaration and definition of a given function, and different mangled names for different functions. The linker matches up the mangled names, and can tell you when no definition matches a reference.
Some compilers choose not to include the return type in the mangled name of a function. In that case, the declaration
int foo(char*);
will match the definition
long foo(char*) { ... }
But it will also match the definitions
myClass foo(char*) { ... }
double foo(char*) { ... }
You are unlikely to get good results from such a mismatch. For that reason, and because a pointer-to-function must encode the function return type, Sun C++ always encodes the function return type in the mangled name. (That is, we simplify things by not using different encodings for the same function type.)
If you built your code for a 64-bit platform, it would presumably link using your other compilers, but would fail in mysterious ways at run time. With the Sun compiler, you can't get into that mess.
To make your program valid, you will have to ensure your function declarations match their definitions.

Configure return type: There was an error while invoking the operation

This error only occurs when I pass parameters to Configure return type dialog
As a follow on from http://forums.adobe.com/message/2663481
I am getting this in the log.
!ENTRY com.adobe.flexbuilder.DCDService 4 1 2010-06-15 11:45:29.323
!MESSAGE Please specify a valid <services/> file path in flex-config.xml.
!STACK 0
flex.messaging.config.ConfigurationException: Please specify a valid <services/> file path in flex-config.xml.
    at flex.messaging.config.LocalFileResolver.getConfigurationFile(LocalFileResolver.java:79)
    at flex.messaging.config.AbstractConfigurationParser.parse(AbstractConfigurationParser.java: 67)
    at flex.messaging.config.ServicesDependencies.getClientConfiguration(ServicesDependencies.ja va:150)
    at com.adobe.flexbuilder.dcrad.utils.DCRADUtility.getServiceSettingsOnServer(DCRADUtility.ja va:1398)
    at com.adobe.flexbuilder.dcrad.utils.DCRADUtility.getServerConfiguration(DCRADUtility.java:1 374)
    at com.adobe.flexbuilder.dcrad.views.ServiceExplorerView.refreshService(ServiceExplorerView. java:1703)
    at com.adobe.flexbuilder.dcrad.views.ServiceExplorerView.refreshSelectedServices(ServiceExpl orerView.java:1650)
    at com.adobe.flexbuilder.dcrad.views.internal.actions.ServiceRefreshAction.run(ServiceRefres hAction.java:41)
    at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
    at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionI tem.java:584)
    at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
    at org.eclipse.jface.action.ActionContributionItem$6.handleEvent(ActionContributionItem.java :452)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
    at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473)
    at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405)
    at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
    at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
    at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
    at com.adobe.flexbuilder.standalone.FlexBuilderApplication.start(FlexBuilderApplication.java :109)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLau ncher.java:110)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.jav a:79)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
One problem I keep getting is that FB keeps setting this setting as J2EE Server even when I tell it is standalone. When I add a server an tell FB that it is Remote, does that mean its J2ee?

Hi,
This is definitely a Bug. I would have filed it but it would be better if we have the exact steps to reproduce the issue. I am aware that you might not be able to share all your source. But a scaled down example would really be helpful. Please do log this bug at
http://bugs.adobe.com/flex/
Nishad
Flash Builder Team

Covariant return types without "-source 1.5"

Similar Messages

Maybe you are looking for