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

[Doug Schaefer <dschaefer@xxxxxxx>]

I wonder if this would really lead to any adoption. As John said, this is
many years too late. I don¹t see any of the major IDE vendors adopting
this. It would be too disruptive to their current ecosystems and just
plain too expensive.

Doug.

On 2015-02-05, 9:33 AM, "Michael Scharf" <eclipse@xxxxxxxxx> wrote:

>I wonder if that would really lead to interoperability of code
>between UI frameworks. I mean, would that enable us to write
>extensions that would work with eclipse, netbeans and intellij?
>
>
>Michael
>
>On 2015-02-03 16:15, Wayne Beaton wrote:
>> 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@xxxxxxxxxxx
>>> 
>>>https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-counci
>>>l
>>>
>>> IMPORTANT: Membership in this list is generated by processes internal
>>>to the Eclipse Foundation.  To be permanently removed from this list,
>>>you must contactemo@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.