Re: [eclipse.org-architecture-council] JSR 377 - Desktop|Embedded Applic

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

Hi,

It might be too late but still I decided to keep an eye on it (believe
it or not just yesterday a potential new major e(fx)clipse customer ask
me about it).

I've also been invited to join the EG but we have not yet drawn a
decision but what I want to make sure is that if they define something
that it does not run completely against what e4 delivers already today
so that it would be easy for us to host components for JSR 377.

I think it would be the wrong move for e4 and all of us to close our
eyes from what's going on outside of the Eclipse Ecosystem and keep our
framework open so let's judge what the JSR 377 people are doing on what
they deliver.

Anyways if you look at the component list we have already defined ALL of
the API/components they plan to deliver although some of them need
polishing e.g. our command/handler API is not really in good shape but I
think it is fairly easy for us to provide a wrapper services compatible
with what those guys come up.

So the strategy we can provide compatibility is to wrap our services
with services they defined I've e.g. done this in e(fx)clipse with the
command service [1] and the IEclipseContext [2] without changing a
single line of the e4 code base.

Let's go through the list:
* dependency injection via JSR330 - supported
  => could be improved if e4 core would adopt changes part of
     e(fx)clipse today - most important get rid of the IEclipseContext
     is user code - in retrospect it was completely wrong to provide
     anyone access to it - not even the internal parts of e4 should get
     access to it but this is most likely the wrong place to discuss
     what's wrong with IEclipseContext

* common application structure - supported
  => with the help of our application model

* localized resources - supported
  => not 100% sure that that means but if they talk about l10n this is
     available through the work from Dirk Fauth and myself since Luna

* resource injection - supported
  => not sure what they are talking about exactly but our DI container
     can inject everything published to the OSGi-Service registry or
     created on demand by the IContextFunction

* localized configuration - supported
  => not 100% sure what that means either but

* decouple state from UI (binding) - supported
  => provided through our clean split between the application model we
     are very well prepared for anything they come up and can provide
     adapters between our application model and whatever API they come
     up with - e(fx)clipse has a generic rendering system that could be
     applied to UI-Toolkit on this planet besides SWT who is the only
     freaking (java) ui-toolkit on planet earth who require requires to
     have the parent up front

* persistence session state (preferences) - supported
  => we restore the UI state in our model and other preferences through
     the preference store of OSGi but we could improve this certainly
     so that the @Preference stuff would not directly delegate to OSGi
     but allows one to exchange the store

* action management - supported
  => we call that Command/Handler framework which could need some work
     to make it a bit simpler but it could be adapted to fairly
     anything including our clever @Execute/@CanExecute strategy

* light-weight event bus - supported
  => we call that EventBroker

* honor threading concerns (specific to UI toolkit) - supported
  => we have some preliminary support for this using UISynchronize for
     an a bit more powerful one once more e(fx)clipse could be an
     inspiration [3]

* application extensibility via plugins (implies modularity) - supported
  => well we use OSGi but I'm really curious what they understand that
     and find a solution that works on mobile - I'm having a hard time
     imagine who this plays with AOT which is needed at (least) on iOS

     I think they can't speak of dynamic modularity where you can post
     install stuff (mobile & AOT) nor can they speak of dynamics in the
     sense of OSGi

So having gone through all what they define as key components are
available some of them are really lightweight and only defined in terms
of interfaces, other would need some work e.g. the Command stuff.

Tom

[1]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.core/src/org/eclipse/fx/core/command/CommandService.java
[2]https://wiki.eclipse.org/Efxclipse/Runtime/Recipes#Publishing_to_the_IEclipseContext
[3]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.ui.services/src/org/eclipse/fx/ui/services/sync/UISynchronize.java

On 05.02.15 05:02, John Arthorne wrote:
> It's about 10 years too late :)  
> 
> I don't expect mature frameworks and applications will have much
> incentive to adopt it.
> 
> John
> 
> 
> 
> From:        Wayne Beaton <wayne@xxxxxxxxxxx>
> To:        eclipse.org-architecture-council@xxxxxxxxxxx
> Date:        02/03/2015 10:23 AM
> Subject:        Re: [eclipse.org-architecture-council] JSR 377 -
> Desktop|Embedded Application API - JSR Approval Ballot
> Sent by:        eclipse.org-architecture-council-bounces@xxxxxxxxxxx
> ------------------------------------------------------------------------
> 
> 
> 
> I must admit that I find it curious that nobody seems to have anything
> to say about this JSR.
> 
> The goal of this specification is to define an API for common behavior
> shared by many desktop applications. Most applications require the
> following features
> 
> * dependency injection via JSR330.
> * common application structure.
> * application life-cycle.
> * localized resources.
> * resource injection.
> * localized configuration.
> * decouple state from UI (binding).
> * persistence session state (preferences).
> * action management.
> * component life-cycle.
> * light-weight event bus.
> * honor threading concerns (specific to UI toolkit).
> * application extensibility via plugins (implies modularity).
> 
> There are a good number of framework and platforms that deliver these
> features in their own way. Deciding a standard API for all of them will
> make it easier to get started with new projects and fix existing ones.
> Also, with the rise of Embedded Java and IoT it makes sense to share
> codebases between desktop and embedded projects.
> 
> A driving goal behind the JSR is to provide a good abstraction over
> common needs of an application regardless of the toolkit of choice. For
> example this JSR must deliver an abstraction on how to access the UI
> thread (which ever it may be) and a mechanism for initializing and
> managing a View independent of the widget set. The UI thread abstraction
> has been already proven true by some of the frameworks mentioned as
> source materials.
> 
> The set of APIs proposed by this JSR will sit on top of any UI toolkit
> without requiring a bridge from a toolkit in particular; that is, none
> of the target UI toolkits (Swing, JavaFX, SWT) need to implement new
> APIs. If for some reason a bridge is required it will be provided from
> the RI side.
> 
> This JSR should be released as a standalone one, without ties to a
> particular JDK release.
> 
> 
> Anyone?
> 
> Hello?
> 
> Wayne
> 
> On 29/01/15 11:13 AM, Wayne Beaton wrote:
> Greetings Architecture Council.
> 
> I invite your input on this JSR:
> 
> 
> 
> ****NEW ITEM****
> JSR 377 - Desktop|Embedded Application API - JSR Approval Ballot
> Last day to vote: 9 February 2015
> URL of proposal:
> _https://jcp.org/en/jsr/detail?id=377_
> 
> 
> 
> -- 
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation_
> _EclipseCon 2015 <http://www.eclipsecon.org/na2015>
> 
> 
> 
> 
> _______________________________________________
> eclipse.org-architecture-council mailing list
> _eclipse.org-architecture-council@eclipse.org_
> <mailto:eclipse.org-architecture-council@xxxxxxxxxxx>
> _https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council_
> 
> IMPORTANT: Membership in this list is generated by processes internal to
> the Eclipse Foundation.  To be permanently removed from this list, you
> must contact _emo@eclipse.org_ <mailto:emo@xxxxxxxxxxx>to request removal.
> 
> -- 
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation_
> _EclipseCon 2015
> <http://www.eclipsecon.org/na2015>_______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
> 
> IMPORTANT: Membership in this list is generated by processes internal to
> the Eclipse Foundation.  To be permanently removed from this list, you
> must contact emo@xxxxxxxxxxx to request removal.
> 
> 
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
> 
> IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck