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. "

Similar Messages

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 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 (??).

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?

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 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

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.

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

Multiple Return Types

haven't been around in a while, so I thought I'd stir up some comments with a suggestion for a new feature in Java, which I'm sure has been suggested at some point, but I can't remember seeing it talked about, so here goes:
Multiple Return Types:
public String, int getStateInfo(String abbrev) {
   if("nj".equalsIgnoreCase(abbrev)) {
      return "New Jersey", 11408042;
   // ... and other states...
   return null, -1;
String name, int population = getStateInfo("nj");
System.out.println("The population of " + name + " is " + population + ".");Yes yes, I know. Create a StateInfo object with the fields needed. Still, I think that could be interesting.

apart from it getting ugly with more than twoparameters
What? How is this ugly? ;-)
public String, int, String, Color, String, String
getStateInfo(String abbrev) {
return name, population, stateFlower, stateColor,
or, stateAnimal, governorsName;
there no indication on what the return valuesrepresent.
Well, I guees the API docs would have to speak for
themselves. Or better method naming... In that
sense, it's no different then now. I could write a
method "getStateName()" and return totally different.
public String, int getStateNameAndPopulation(String
abbrev) {...
I used to like "tuples" when I studied The Tom Programming Language (that's how he calls them), as every CS student is a bit of a "featurist"... Now that I came to develop 40 hours a week and to love Java's simple and powerful expressiveness, I tend to find such constructs overly ugly to be avoided as possible... a matter of personal taste, too, I suppose...

How can I get rid of a type generated by the Data/Services return type wizard?

Hi All,
I have a JSON service that returns an object called "error". The Data/Services "Configure Return Type" wizard automatically turned this into a class "Error".
However, this caused over a hundred errors to show up inside the generated classes, "Call to a possibly undefined method Error." That's because of lines like this:
throw new Error(propertyName + " is not a data property of entity Agreements");
It's trying to throw a regular "Error" object, but now that there's an "Error" class in the same package, that is taking precedence--and that Error object doesn't have a constructor with a single parameter. At least, that's what I think is going on.
I tried to fix it by deleting _ErrorEntityMetadata.as, _Super_Error.as, and Error.as from the valueObjects package. I then opened the FML file and deleted the definition for the entity "Error" and every reference to the Error entity (class) in my FML file.
I then changed my JSON service so that it returns an object called "serviceError" instead of just "error".
But, whenever I re-run the "Configure Return Type" wizard, it regenerates the Error class, even though I've deleted it from everywhere I can find it. That breaks my project completely! How can I end this and get Flash Builder to *stop* generating this type!
In the "Configure Return Type" wizard I very carefully inspected the type of every bit of data coming back to make sure none of them show up as type "Error." And they don't (as expected, since I changed the object's name to serviceError--now the type of that object is ServiceError.
-Josh

I think you are facing this known issue https://bugs.adobe.com/jira/browse/FB-29770
Please vote it.
Thanks for the link--I just voted for it.
To avoid this, in the last page of "Configure Return Type", edit return type name to something else (You can also edit subnodes's name too in the wizard).
Actually, that's exactly what I saw doing; I apologize if that wasn't clear in my post.
I closed and restarted Flash Builder, and once I did that Flash Builder stopped generating the Error class. My guess is that the FML file, even though I had updated it (by deleting all references to the Error class), was cached in some fashion by Flash Builder, and restarting Flash Builder forced it to reread the FML file?
Additional point of clarification: my understanding is that the FML file stores all the metadata about the services that Flash Builder has been able to figure out so far, and when you run the Configure Return Type wizard, it will regenerate *every* type in the FML file, even if that type is not mentioned anywhere in the particular return value that you are working with.
Edited to provide additional thoughts on FML file.

Problem when calling a return type BOOLEAN SQL Function in a package

Hi All,
I am having problem when trying to call a SQL function in a package with return type BOOLEAN
The SQL function signature is as follows
CREATE OR REPLACE PACKAGE RMSOWNER.ORDER_ATTRIB_SQL ****
FUNCTION GET_PO_TYPE_DESC(O_error_message IN OUT VARCHAR2,
I_PO_TYPE       IN     VARCHAR2,
O_PO_TYPE_DESC IN OUT VARCHAR2)
RETURN BOOLEAN;
Following is my java code
+CallableStatement cs3 = conn.prepareCall("{?=call ORDER_ATTRIB_SQL.GET_PO_TYPE_DESC(?,?,?)}");+
+cs3.registerOutParameter(1, java.sql.Types.BOOLEAN);+
+cs3.registerOutParameter(2, java.sql.Types.VARCHAR);+
+cs3.registerOutParameter(4, java.sql.Types.VARCHAR);+
+cs3.setString(2, "");+
+cs3.setString(3, "ST");+
+cs3.setString(4, "");+
+ResultSet rs3 = cs3.executeQuery();+
I get the following exception, i tried changing the sql type(registerOutParameter) from boolean to bit but i still getting this exception.
But when i call any other functions with return type other than boolean they work perfectly fine.
Please can anyone help me fix this issue, i am not sure if its anything to do with vendor JDBC classes?
+java.sql.SQLException: ORA-06550: line 1, column 13:+
+PLS-00382: expression is of wrong type+
+ORA-06550: line 1, column 7:+
+PL/SQL: Statement ignored+
+     at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)+
+     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)+
+     at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)+
+     at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743)+
+     at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:215)+
+     at oracle.jdbc.driver.T4CCallableStatement.executeForRows(T4CCallableStatement.java:954)+
+     at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168)+
+     at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3316)+
+     at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3422)+
+     at oracle.jdbc.driver.OracleCallableStatement.execute(OracleCallableStatement.java:4394)+
#####

Hello People!
There is another workaround!!
See the example below:
private String callBooleanAPi(String tableName,String apikey,String dtInicio,String dtFim,String comando) throws SQLException {
               CallableStatement cs = null;
               String call = "";
               String retorno = null;
               try {
                    if(comando.equalsIgnoreCase("INSERT")){
                         call = "declare x BOOLEAN; y varchar2(2);begin x :=PKG.INSERT(?,?,?,?,?); if x then y := 'S'; else y :='N'; end if; ? := y;end;";
                    } else if(comando.equalsIgnoreCase("UPDATE")){
                         call = "declare x BOOLEAN; y varchar2(2);begin x := PKG.UPDATE(?,?,?,?,?); if x then y := 'S'; else y :='N'; end if; ? := y;end;";
                    } else if(comando.equalsIgnoreCase("DELETE")){
                         call = "declare x BOOLEAN; y varchar2(2);begin x := PKG.DELETE(?,?,?,?,?); if x then y := 'S'; else y :='N'; end if; ? := y;end;";
                    cs = conn.prepareCall(call);
                    SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy");
                    SimpleDateFormat sdfToSqlDate = new SimpleDateFormat("yyyy-MM-dd");
                    java.util.Date dataInicialVigencia =null;
                    java.util.Date dataFinalVigencia = null;
                    Date dtInicialFormatada =null;
                    Date dtFinalFormatada = null;
                    if(dtInicio != null && !dtInicio.equals("")){
                         dataInicialVigencia = sdf.parse(dtInicio);
                         dtInicio =sdfToSqlDate.format(dataInicialVigencia);
                         dtInicialFormatada = Date.valueOf(dtInicio);
                    if(dtFim != null && !dtFim.equals("")){
                         dataFinalVigencia = sdf.parse(dtFim);
                         dtFim =sdfToSqlDate.format(dataFinalVigencia);
                         dtFinalFormatada = Date.valueOf(dtFim);
                    cs.setString(1, tableName);
cs.setString(2, apikey);
cs.setDate(3, dtInicialFormatada );
cs.setDate(4, dtFinalFormatada );
cs.registerOutParameter(5, java.sql.Types.VARCHAR);
cs.registerOutParameter(6, java.sql.Types.VARCHAR );
cs.execute();
                    retorno = cs.getString(6);
                    System.out.println( cs.getString(5));
               } catch(SQLException e){
               throw new SQLException("An SQL error ocurred while calling the API COR_VIGENCIA: " + e);
               } catch(Exception e){
               Debug.logger.error( "Error calculating order: " + id, e );
               } finally {
               if (cs != null) {
               cs.close();
               cs = null;
               return retorno;
As you can see the CallableStatement class acepts PL/SQl blocks.
Best Regards.

Should Collections be used as return types across threads?

I am wondering when, if ever, it is appropriate to use a Collection as the return type of a method in a multi-threaded environment. Here is our situation:
We have four classes -- Widget, WidgetManager, ClientA, and ClientB. ClientA and ClientB are running in different Threads from each other and from the WidgetManager.
The WidgetManager class that uses a Collection of Widgets internally, and passes the Collection (or an Iterator over it) out as a return value of a method to ClientA, which is running in another thread. ClientA would start to go through it using next() and hasNext() of the Iterator. If the WidgetManager were to get a request from ClientB running in another thread to eliminate a Widget, it would attempt to remove it from the Collection. If ClientA were still looping through the Iterator, this would throw an IllegalStateException b/c the system would be in an inconsistent state. The Iterator given to the ClientA is directly linked to the actual Collection in the WidgetManager (am I right so far?).
In my opinion, in most cases we don't want to synchronize Collections. In the example above, if we had passed out a synchronized Collection, then the WidgetManager couldn't touch the collection while the client was looping through the Iterator. If the client got hung up while looping, then the WidgetManager would be hung up. In this case, I think that it will be better to use the toArray() method of Collection to just dump out the contents to a plain array of Objects. Actually, the WidgetManager could convert this array of Objects to an array of Widgets before passing it out, which would give us the type checking that we don't get with Containers.
The condition where you would want to use a synchronized Collection would be when you actually want the client to do some writing or removing from the Collection. I would expect this to be pretty rare since you usually dont want to give clients access to an interal member (the Collection) of a class.
I think that it is also possible to have read-only Collections, but I think (don't know for sure) that you would still have the same IllegalStateException or synchronization probelms.
Can someone point out the errors in my thinking? Or should you generally only use Collections as internal members in a multi-threaded environment, and use toArray() whenever you want to pass the Collection's data outside of the class?
Thanks for any help.
Keith

I haven't tested what happens when you synchronize the
Collection, but I think that you are right. But this
causes the problem that I mentioned in the first post.
That is, what happens if your client STARTS running
through the Iterator, and then stops or gets hung up
for some reason? I assume that you're still blocked.
And it's pretty important to me in this case to not
t be blocked -- WidgetManager is the highest level
class in the system.
I'd like to know if anyone has tested this.
The Iterator implementations used in java.util do not use any synchronization by itself, (which is what you would expect since synchronization over multiple method call will involve much more complications and slower performance) . With iterator, you have to provide the necessary synchronization yourself to maintain thread-safety like this
Iterator itr = get Iterator from collectionInstance ;
synchronized(collectionInstance) {
while(itr.hasNext())
process itr.next() ...
As long as your client code gracefully exits the synchronized block on a stop( or hangup, given that it is detected and handled fast enough), it will not be a problem.
Also, I'd like an example of when you WOULD want to
return a Collection. I'm specifically interested in
when you would want to return one in a multi-threaded
environment, but I'm beginning to wonder when you
would EVER want to return one from a method.
Collections are great for internal uses, but you lose
type-checking and you expose the internals of your
class to modification when you use them as return
types. And if you're returning a read-only
Collection, you might as well return an array, right?Using a read-only proxy will be much faster and space-efficient than toArray().

Two methods with same name but different return type?

Can I have two methods with same name but different return type in Java? I used to do this in C++ (method overloading or function overloading)
Here is my code:
import java.io.*;
public class Test{
public static void main(String ar[]){
try{
//I give an invalid file name to throw IO error.
File file = new File("c:/invalid file name becasue of spaces");
FileWriter writer = new FileWriter(file ,true);
writer.write("Test");
writer.close();
} catch (IOException IOe){
     System.out.println("Failure");
//call first method - displays stack trace on screen
     showerr(NPe);
//call second method - returns stack trace as string
        String msg = showerr(NPe);
        System.out.println(msg);
} // end of main
public static void showerr(Exception e){
     StringWriter sw = new StringWriter();
     PrintWriter pw = new PrintWriter(sw);
     e.printStackTrace(pw);
     try{
     pw.close();
     sw.close();
     catch (IOException IOe){
     IOe.printStackTrace();
     String stackTrace = sw.toString();
     System.out.println("Null Ptr\n" + stackTrace );
}//end of first showerr
public static String showerr(Exception e){
     StringWriter sw = new StringWriter();
     PrintWriter pw = new PrintWriter(sw);
     e.printStackTrace(pw);
     try{
     pw.close();
     sw.close();
     catch (IOException IOe){
     IOe.printStackTrace();
     return sw.toString();
}//end of second showerr
} // end of class
[\code]

Overloading is when you have multiple methods that have the same name and the same return type but take different parameters. See example
public class Overloader {
     public String buildError(Exception e){
          java.util.Date now = new java.util.Date() ;
          java.text.DateFormat format = java.text.DateFormat.getInstance() ;
          StringBuffer buffer = new StringBuffer() ;
          buffer.append(format.format(now))
               .append( " : " )
               .append( e.getClass().getName() )
               .append( " : " )
               .append( e.getMessage() ) ;
          return buffer.toString() ;
     public String buildError(String msg){
          java.util.Date now = new java.util.Date() ;
          java.text.DateFormat format = java.text.DateFormat.getInstance() ;
          StringBuffer buffer = new StringBuffer() ;
          buffer.append(format.format(now))
               .append( " : " )
               .append( msg ) ;
          return buffer.toString() ;
     public String buildErrors(int errCount){
          java.util.Date now = new java.util.Date() ;
          java.text.DateFormat format = java.text.DateFormat.getInstance() ;
          StringBuffer buffer = new StringBuffer() ;
          buffer.append(format.format(now))
               .append( " : " )
               .append( "There have been " )
               .append( errCount )
               .append( " errors encountered.") ;
          return buffer.toString() ;
}Make sense ???
Regards,

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

How to add User defined return type in service interface of AppModule

HI All,
I am creating service interface using AppModule. Added custom method with Java primitives and working fine. Now i want to added custom method with return type is EMP object means user defined object. How can i do so?
Thanks in advance.

I looked it up in the mean time ...
The docs state that you only can use simple data type or java.util.list or AttributeList (which is a wrapper for any viewRow). So I guess you have to somehow flatten your complex data type or create a custom VO which holds it.
http://download.oracle.com/docs/cd/E12839_01/web.1111/b31974/bcextservices.htm#CJAEHFJD
Scroll down to 11.2.3
Timo

Covariant Return Types - J2SE 5.0

Similar Messages

Maybe you are looking for