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

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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





_______________________________________________
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.

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
_______________________________________________
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.