Markus,
Comments below.
On 30/07/2014 7:18 PM, Markus Keller wrote:
Hi Ed
Thanks for this excellent write-up of https://bugs.eclipse.org/416189!
Yes, the proposed changes will be scrutinized, and it's very well
possible that the outcome is again WONTFIX.
Side-note about java.util.Collection's <T> T[] toArray(T[] a): That
method looks type-safe, but it's not.
Well, yes and no. It's guaranteed (at least by contract) to return an
array of T, i.e., an array of the same type as "a". It doesn't requires
that T have any relation to E, so yes, trying to store each E instance
of the Collection into "a" or its clone if "a" isn't big enough can
result in an array store exception. Of course the exact same statement
was true before they generified it.
Again, there's no connection between the Collection's <E> and the
method's <T>.
Indeed.
See its @throws ArrayStoreException and the example in
https://bugs.openjdk.java.net/browse/JDK-7023484
But the point is, its guaranteed to produce T[], and it's able to do so
in any Collection implementation. As we all know from writing
c.toArray(new X[c.size()]) again and again, it would have been totally
convenient if toArray return E[], but it doesn't though it certainly
could, if each collection constructor required an X[] prototype or an
X.class instance. So while incredibly convenient for calling toArray,
and very convenient for fail fast type safety even in contexts that have
erased the type, that's not what they decided to do.
Markus
From: Ed Merks <[email protected]>
To: [email protected]
Date: 2014-07-30 16:47
Subject: Re: [cross-project-issues-dev] Information about the
"Generifing JFace viewers" project
Sent by: [email protected]
------------------------------------------------------------------------
Dani,
As I've made pretty clear in the past, I'm a huge non-fan of this
effort. I find it ironic that the platform is rife with raw types
(List), and rather than investing an effort to eliminate those, effort
will be invested on generifying things that just aren't screaming to
be generified, and to do so in a context that is heavily dominated by
Object[], which interacts exceedingly poorly with generics. Thought
I've made that argument already, I think it bears repeating...
Anywhere you see something like T[] where T is a type parameter, you
already have to get suspicious. Of course we see this in
java.util.Collection:
<T> T[] toArray(T[] a);
But note that T is derived from the argument, and argument my not be
null, so even in an erased runtime environment we can determine a
reasonable T from "a", so suspicion alleviated and that's why we can
have generic collection implementations...
Note that however nice it would have been that toArray() method looked
like this:
E[] toArray()
rather than
Object[] toArray
because you can't implement this generically, unless you provide some
object with the necessary *runtime *information about E to the
constructor of an implementation class...
So consider this:
public interface IStructuredContentProvider extends IContentProvider {
public Object[] getElements(Object inputElement);
}
there's no relationship between the input element's type and the type
of the array, so if someone proposes
public interface IStructuredContentProvider<X, Y> extends
IContentProvider<X> {
public Y[] getElements(X inputElement);
}
I'm going to be very suspicious. What this tells me is there must be
some sensible way of being sure that I'll be getting back a real Y[]
instance and not an Object[] instance. What could that sensible way be?
Of course directly implementing that interface in a sensible way is a
good solution, but what about generic solutions?
Consider org.eclipse.jface.viewers.ArrayContentProvider (and note that
EMF generally has *only *content provider implementations analogous to
this). This existing implementation just don't work. You can just
forget about org.eclipse.jface.viewers.ArrayContentProvider.instance,
you can just deprecate
org.eclipse.jface.viewers.ArrayContentProvider.getInstance(), and
you'd better add a public constructor and deprecate it while your at
it, because this implementation
public Object[] getElements(Object inputElement) {
if (inputElement instanceof Object[]) {
return (Object[]) inputElement;
}
if (inputElement instanceof Collection) {
return ((Collection) inputElement).toArray();
}
return new Object[0];
}
simply doesn't work for collections. You'll need new constructors
and new getInstance methods each of which specify the array type,
either as java.lang.Class or as an array prototype, as in the first
form to toArray above. You'd have to provide that even for the
constructor that takes a collection, just the collection instance will
not suffice.
Great, so much for adding generics to JFace being erasure compatible,
counter to what was the case when Java's collection library was
generified. Nothing in the collections library was deprecated and no
new methods were added. In other words, for JFace's changes, you
can't just turn off warnings about raw types, you must deal with the
deprecations and API changes. So if you're trying to maintain
something that works with old versions of Eclipse (i.e., EMF is
compatible with Eclipse 3.5), you're completely hosed. You can't add
generics, because you can't compile against an older target platform
that does have it, so you simply have to live with a sea of raw type
warnings (or turn them all off and lose the value of even having such
warnings). Also, you can't start using the new methods instead of the
deprecated ones, so you have to live with that sea of warning as well,
or just turn them off too. Nor you can you exploit any of it to
provide value to clients (given the premise there is value), because
you can't reasonably address this ArrayContentProvider problem without
inflicting the same pain on the clients (who actually have better
things to do, go figure).
Even the premise that this effort has value is questionable. Granted,
someone writing their first content provider might find it useful, if
(and only if) it's one that's concrete and if (and only if) it doesn't
need to deal with several input types that have no common super type
(and even in that case they'll still typically end up with instanceof
tests to return subtype-appropriate results). That's on the argument
side of the getElements. On the return type side, it's of no benefit
to the author; they just pass this content provider into a generic
viewer that doesn't care whether it's Object[] or X[]. So in fact it's
just a burden with which one must conform.
So is the value of this whole exercise eliminating instance of checks
for the arguments of the provider implementations? Does this tangible
(but small) benefit justify the impact on the long established
community? Do we expect that community to eliminate their
deprecations and generify all their code? (Sorry guys and girls, all
your existing toArray() calls are invalid, or, don't worry about it,
just sprinkle <Object, Object> everywhere.) I wonder, will JDT and
PDE do that? If not, why expect the rest of the community to do it?
And if you don't expect that, what exactly are you expecting will
come from this?
I suggest folks carefully weight the benefits against the disruptive
nature of this type of change.
Regards,
Ed
On 30/07/2014 11:42 AM, Daniel Megert wrote:
Just for the records, here are some constraints that I required in
order to agree to continue that work:
- Some stuff just doesn't make sense to be generified because it often
contains various kinds of objects, e.g. (tree) viewers. See also
_http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html_.
- If generified types cannot be plugged together unless everything is
again just Object or Class, it's not worth to generify those types.
- The generified code must be in a shape so that clients can start to
fix their code by invoking Refactor > Infer Generic Type Arguments...
This needs to be validate on existing Platform UI code.
Dani
From: Lars Vogel _<[email protected]>_ <mailto:[email protected]>
To: [email protected]_
<mailto:[email protected]>, Jeanderson Candido
_<[email protected]>_ <mailto:[email protected]>, Hendrik
Still _<[email protected]>_ <mailto:[email protected]>
Date: 30.07.2014 11:23
Subject: [cross-project-issues-dev] Information about the "Generifing
JFace viewers" project
Sent by: [email protected]_
<mailto:[email protected]>
------------------------------------------------------------------------
Hi,
as some of you probably remember, the platform.ui team started a GSoC
project last year to generify the JFace viewer framework. We
(platform.ui team together with John Arthone and Dani Megert) decided
that it is worth to finish this project and started a new GSoC project.
Jeanderson Barros Candido (cc) is working on this project with Hendrik
Still (cc) (GSoC student from last year) and me as mentor.
I personally think the work looks already very good and plan to
integrated it soon into the master. We are trying to learn from the
experience from last year, therefore:
- We plan to integrate it as a whole, not piece wise so people can
fix warning messages created by this change
- We reworking the JFace snippets and tests at the same time to have a
first proof-point
- We plan to use it for platform views to validate that it works
Of course generifying an existing API, will result in certain
limitations and some suggested a complete rewrite of the JFace viewer
framework but this is currently not the scope of this project.
The implementation is currently done at Github:
_https://github.com/jeandersonbc/eclipse.platform.ui_and we do our
planning in _https://github.com/jeandersonbc/gsoc14-eclipse-planning_.
If someone wants to test the new implementation and provide feedback,
please let us know.
Best regards, Lars_______________________________________________
cross-project-issues-dev mailing list_
[email protected]_
<mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit_
__https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
_______________________________________________
cross-project-issues-dev mailing list
[email protected]_
<mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
_https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
