[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse.org-architecture-council] JSR 377 - Desktop|Embedded Application API - JSR Approval Ballot
|
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