Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Information about the "Generifing JFace viewers" project

Right all API in JavaFX is generified - and yes you simply have to take
the most basic type you have but like outlined already by Lars' one
often is able to find a base type (e.g. think about a File-Tree-Viewer
where the base class is always a File-Instance).

What worries me more how to deal with Object[] in the viewers which you
made generic but I'm uncertain this is legal from an API point of view
because some dumb man could have written code like this:

> public class TestMe {
> 	public interface B<E> {
> 		public E[] test();
> 	}
> 	
> 	public static class C implements B<String> {
> 		@Override
> 		public String[] test() {
> 			return new String[1];
> 		}
> 	}
> 	
> 	public static void main(String[] args) {
> 		B t = new C();
> 		Object[] v = t.test();
> 		v[0] = new Object();
> 	}
> }

which would break at the very moment someone adds generics

> public class TestMe {
> 	public interface B<E> {
> 		public E[] test();
> 	}
> 	
> 	public static class C implements B<String> {
> 		@Override
> 		public String[] test() {
> 			return new String[1];
> 		}
> 	}
> 	
> 	public static void main(String[] args) {
> 		B t = new C();
> 		Object[] v = t.test();
> 		v[0] = new Object(); // BAM BAM BAM ArrayStoreException!!!!!
> 	}
> }

It is highly unlikely that someone did something like that with
JFace-Viewers but the really bad thing is that no compiler can ever
catch this problem.

Tom

On 30.07.14 13:03, Erdal Karaca wrote:
> I am no JavaFX expert, but it has Views (for example, TreeView) whose
> "Items" are aware of a root generic type: for example,
> TreeView#setRoot(TreeItem<T>)...
> If the viewer input has no base class for all of its elements, then the
> API user would have to use Object again.
> I wonder how the JavaFX devs/community solved this issue... 
> 
> 
> 
> 2014-07-30 12:44 GMT+02:00 Lars Vogel <lars.vogel@xxxxxxxxx
> <mailto:lars.vogel@xxxxxxxxx>>:
> 
>     - 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_. 
> 
>     We need to investigate that,  for example in the e4 tools project
>     our tree is based on MApplicationElement hence for us it would make
>     sense to have a generified TreeViewer. 
> 
> 
>     2014-07-30 11:42 GMT+02:00 Daniel Megert <daniel_megert@xxxxxxxxxx
>     <mailto:daniel_megert@xxxxxxxxxx>>:
> 
>         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 <lars.vogel@xxxxxxxxx
>         <mailto:lars.vogel@xxxxxxxxx>>
>         To:        cross-project-issues-dev@xxxxxxxxxxx
>         <mailto:cross-project-issues-dev@xxxxxxxxxxx>, Jeanderson
>         Candido <jeandersonbc@xxxxxxxxx
>         <mailto:jeandersonbc@xxxxxxxxx>>, Hendrik Still
>         <Gamma32@xxxxxxxxx <mailto:Gamma32@xxxxxxxxx>>
>         Date:        30.07.2014 11:23
>         Subject:        [cross-project-issues-dev] Information about the
>         "Generifing JFace        viewers" project
>         Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx
>         <mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx>
>         ------------------------------------------------------------------------
> 
> 
> 
>         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
>         cross-project-issues-dev@xxxxxxxxxxx
>         <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>         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
>         cross-project-issues-dev@xxxxxxxxxxx
>         <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>         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
>     cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     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
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 



Back to the top