Ramsin Khoshaba

Tobias Bachert wrote:Type-erasure is happening, your makeArray method has compiled the type (Object[])Object[], but the generic types are still present during compile-time -> you create and pass a String array to the method (and thus receive a String array).
Your code is compiled similar to
public class Application {    static Object[] makeArray(Object[] ts) {        Object[] a = (Object[]) Array.newInstance(ts.getClass().getComponentType(), ts.length);                for (int i = 0; i < a.length; i++) {            a[i] = ts[i];        }                return a;    }        public static void main(String[] args) {        String[] array = (String[]) makeArray(new String[] {"Hello", "World", "Goodbye"});        System.out.println(array.getClass().getComponentType()); // prints String, not Object    } }

Thank you very much.

So the compiler translates the argument list to the equivalent array creation expression before type erasure.

Object[] array = Application.<Comparable<String>>makeArray("Hello", "World", "Goodbye"); System.out.println(array.getClass().getComponentType());
This prints Comparable, even though I have Strings.
So it is the inferred type that counts, not the actual type.

Henry Wong wrote:

Ramsin Khoshaba wrote:
Why does ts.getClass().getComponentType() return the type before erasure in the case of varargs?

Your code is simply an example of creating an array via the reflection library (specifically, via the Array class). This method of creating arrays works, even without generics and / or varargs involved.

Henry

Yea, but why is not
ts.getClass().getComponentType() == Object.class
true when I use the type argument String for T?

Why isn't type erasure taking place in this case?

Hello,

Why does ts.getClass().getComponentType() return the type before erasure in the case of varargs?
That is instead of creating an array of Object because the type parameter is not bounded, I succeed in creating an array of T.
import java.lang.reflect.Array; public class Application {    static <T> T[] makeArray(T... ts) {        T[] a = (T[]) Array.newInstance(ts.getClass().getComponentType(), ts.length);                for (int i = 0; i < a.length; i++) {            a[i] = ts[i];        }                return a;    }        public static void main(String[] args) {        String[] array = makeArray("Hello", "World", "Goodbye");        System.out.println(array.getClass().getComponentType()); // prints String, not Object    } }
Where can I read about this in the specification or tutorials?

Thanks.

Hello all,

Consider this code,
interface I <T> { void f(T e); } class C implements I<String> { @Override public void f(String e) { System.out.println(e); } }
When taking into account type erasure, why does the code compile?
That is, why is f() overriden and not overloaded instead?

I'm thinking that, after type erasure, the signature of the abstract method is f(Object), and f(String) does not override f(Object).

Where am I wrong here?
Thank you.

Henry Wong wrote:The example is this... Let's say you have code in class S, which is trying to access a protected field in superclass C (that is in a different package), and is doing it with a reference variable. Then the type of the reference variable is checked. If the type is of class S, or subclass of S, then code of class S can access protected members of C, as it is an instance that the code is responsible of the implementation.

Given this program,
package a; public class Foo { protected int i = 42; }
package b; import a.Foo; public class Bar extends Foo { public static void main (String[] args) { Bar o = new Bar(); System.out.println(o.i); } }
line 8 compiles fine (as it should according to §6.6.2.1), but I can't see how the main method is responsible for the implementation of a Bar object.

Hello,

I found this answered question useful.

And from §8.1.4,

Given a generic class declaration C<F1,...,Fn> (n > 0), the direct superclass of the parameterized class type C<T1,...,Tn>, where Ti (1 ≤ i ≤ n) is a type, is D<U1 θ,...,Uk θ>, where D<U1,...,Uk> is the direct superclass of C<F1,...,Fn> and θ is the substitution [F1:=T1,...,Fn:=Tn].

I think I got it, and k must be less than or equal to n.

Hello,

From JLS-6.6.2,

A protected member or constructor of an object may be accessed from outside the package in which it is declared only by code that is responsible for the implementation of that object.

I'm trying to understand what a responsible code might be: a statement, an expression, or only a class?

To use super to access a hidden protected field, works. Because the expression, i.e. super.Identifier, used to access the protected field is responsible for implementation, as specified above.

From JLS-6.6.2.1,

Let C be the class in which a protected member is declared. Access is permitted only within the body of a subclass S of C.

In addition, if Id denotes an instance field or instance method, then:

If the access is by a qualified name Q.Id or a method reference expression Q :: Id (§15.13), where Q is an ExpressionName, then the access is permitted if and only if the type of the expression Q is S or a subclass of S.

So I can access a protected member of an object in a static method in S, given that the reference expression used to access the member is of type S or a subclass of S.
But I fail to see how the code used to access a protected non-static member of an object in a static method is responsible for the implementation of the object!

Basically, how do §6.6.2 and §6.6.2.1 not contradict each other?

Thanks.

Tiya,

You can try regexr, an online tool used to learn and test regular expressions.
Don't forget to hover the cursor over each item in the expression, to get some explanation.

\\ is an escaped character, so \\* matches 0 or more backslashes.

EDIT: Sorry, I did not notice the String literal.

Petr Omáčka wrote: import inside.*; class Z extends B{ public static void main(String args[]){ A.someStaticMethod(); B.someStaticMethod(); C.someStaticMethod(); // Fine at compile-time but IllegalAccessError at run-time. } }

At line with comment there is no error at compile-time but at runtime there is IllegalAccesError.

What is the true reason for this behavior?

Correct me if I'm wrong, but Z is NOT a subclass of C, whether directly or indirectly; so inside.C.someStaticMethod() is not inherited.
Furthermore, Z is in a different package (in your case the default package) than C, and inside.C.someStaticMethod() is declared protected.
That's why inside.C.someStaticMethod() is simply not accessible.

Campbell Ritchie wrote:For the purpose of your question, consider List and ArrayList the same;

The most confusing part was that they were different. I intentionally chose List and ArrayList, rather than ArrayList only.

I just read from here,

Given a generic type declaration C<F1,...,Fn> (n > 0), the direct supertypes of the parameterized type C<T1,...,Tn>, where Ti (1 ≤ i ≤ n) is a type, are all of the following:

D<U1 θ,...,Uk θ>, where D<U1,...,Uk> is a generic type which is a direct supertype of the generic type C<T1,...,Tn> and θ is the substitution [F1:=T1,...,Fn:=Tn].

C<S1,...,Sn>, where Si contains Ti (1 ≤ i ≤ n) (§4.5.1).

The type Object, if C<F1,...,Fn> is a generic interface type with no direct superinterfaces.

The raw type C.

And here,

A type argument T1 is said to contain another type argument T2, written T2 <= T1, if the set of types denoted by T2 is provably a subset of the set of types denoted by T1 ...

So looking at the second bullet point, it appears to me that it's an alternative (although equivalent) explanation for the behavior Campbell just explained.

Now I'm really struggling to understand the first point, which would clarify a lot.

Hello,

The topic of variance is new to me.

Arrays are covariant. So given that A is a subtype of B, A[] is also a subtype of B[].
Nevertheless, A[] is not a subclass of B[]. The only super class of every array type is Object.
Yes,
(new A[0]) instanceof B[]
returns true, but "the result of the instanceof operator is true if the value of the RelationalExpression is not null and the reference could be cast to the ReferenceType without raising a ClassCastException."

Generics without wildcards are not covariant, nor contravariant. As for generics with wildcards, they are covariant (when expressed using extends keyword) and contravariant (when expressed using super keyword).

I want to know why the following compiles, albeit I have no reason to argue that it should not compile. And more importantly what it actually means.

How to explain the following code in terms of variance?
List<? super String> list1 = new ArrayList<Object>(); List<? extends Number> list2 = new ArrayList<Integer>();
I'm asking this question because I'm using two different but related types: List and ArrayList.
I know that ArrayList<E> implements List<E>.
But I don't really grasp this situation where type parameters are involved together with a class and its interface.
What makes ArrayList<Integer> a subtype of List<? extends Number>?

Thanks for reading.

There exists this math library, which includes some combinatorics functions:
https://commons.apache.org/proper/commons-math/

Unfortunately, there is no function for calculating multinomial coefficients.

Piet Souris wrote:@Ramsin
what is your background, if I may ask? Not many know about diiofantic equations. I remember doing a Project Euler problem that dealt with these things. As it turned out, I had to search Google for some theoretic results first.

I'm a freshman at KTH. My MScEng programme is called Information Technology. I'm having a course in discrete mathematics this period.

The previous semester I had a course in Java, where I got 41/41 on the final exam
Of course, after the course was done I started to better understand some parts that I had learned during the course, with frustration.
And I still have to understand more.

There is also an elective Java course I'm gonna choose for the next semester. It covers network programming in Java

Ramsin Khoshaba wrote:Now for each such permutation there should belong a 3 also. So we get,
permutations += factorial(x + y + z)/factorial(x)/factorial(y)/factorial(z) * (x + y + z + 1);
Or, 56 such permutations.

Oh, I forgot to count permutations with digit 6.