JSR377 Review Ballot Results

We've got the green light to continue!
Next steps are:
- finish setting up the Expert Group. There are a few nominations in the queue due to missing Exhibit B or signed JSPA.
- setup ASLv2 CLA on github repositories for anonymous contributors.
- setup spec website (jsr377.github.io)
- write down and publish guidelines for doc contributions (asciidoc).

These tasks will take us a couple of weeks. In the meantime we can begin discussing the proposed feature list

A reminder, these features may or may not be delivered in full by the final spec. We have to decide if the scope of each one is right. Alternatively, there may be missing features (like the desktop integration feature mentioned in another thread) that should also be brought to light.

Here's to an exciting spec development cycle and the challenges that await us!

We've got the green light to continue!
Next steps are:
- finish setting up the Expert Group. There are a few nominations in the queue due to missing Exhibit B or signed JSPA.
- setup ASLv2 CLA on github repositories for anonymous contributors.
- setup spec website (jsr377.github.io)
- write down and publish guidelines for doc contributions (asciidoc).

These tasks will take us a couple of weeks. In the meantime we can begin discussing the proposed feature list

A reminder, these features may or may not be delivered in full by the final spec. We have to decide if the scope of each one is right. Alternatively, there may be missing features (like the desktop integration feature mentioned in another thread) that should also be brought to light.

Here's to an exciting spec development cycle and the challenges that await us!

Cheers,
Andres

If you reply to this email, your message will be added to the discussion below:

RE: JSR377 Review Ballot Results

RE: JSR377 Review Ballot Results

Before starting to work on these items, is it possible to clarify the goal of this JSR ?

Should we try to create an absolutely fresh API or should we try to get the biggest common part of some of existing ones ?

People that are already working on their application frameworks will not throw them to the dust, and start a new one tomorrow, so how many of working Implementation (and efficient) should we have in December...

Do we want to make an universal API like OSGI, in this case we should climb a step higher to define what an application framework should provide (in terms of architecture and design pattern to use)

This orientation is essential, because the success of this JSR depends on it.

As a UI developer I'm used to criticize application frameworks I'm using (currently all eclipse folks and there are tons of remark to say), as an application framework provider I'm curious to see how I will be able to implement this JSR, finally I'm curious to know if we will have fully interoperable frameworks (another time like OSGI with equinox, felix etc...)

RE: JSR377 Review Ballot Results

Johan's right on the money. We should prioritize the features, and for that we need to know what those features mean. The aforementioned list leaves some gaps and ambiguity creeps in. I guess our first task would be to define each feature so that all of us agree on what they mean.

Allow me to remind you of some of the source materials we can sue as starting points

These list is not exhaustive (Sebastien's JRebirth did not appear before the JSR was posted for example). So if you're familiar with a particular source material please take some time to write (at most) 2 paragraphs on each feature. We'll merge the results in say, 10 days time?

We can of course update these definitions as new EG members join or new data is available.

RE: JSR377 Review Ballot Results

The goal of this JSR is to deliver an API that existing and new frameworks can implement.
We'll base this API on existing behavior exposed by the source materials, thus designing interfaces, annotations and classes that are very close to what already exist today. Some features will be very easy to integrate into existing frameworks, others may require additional work, but that's just how things are.

I'd rather stay as close to the metal as possible, that is, to direct API usage without forcing architecture too much. I have strong opinions on opinionated frameworks and sensible defaults. Once size (in terms of architecture) does not fit all, so we have to make this API as extensible and light as possible without sacrificing usefulness and power.

RE: JSR377 Review Ballot Results

Administrator

This is where the RI comes in. It's likely that some bridge functions are so common that we package them into artifacts delivered by the RI. Next implementors decide if they take in these binaries or build their own bridges from scratch. This would be mostly the case with OSGi based frameworks where the very least they can do is repackage the binaries as OSGi compliant bundles.

RE: JSR377 Review Ballot Results

I better understand the spirit but if we don't make some choice in term of architecture, how the RI could join all these disjointed topics.

IE: How the RI will be able to manage internationalization and threading if it doesn't provide the glue between them (ie: when app starts, resources files are loaded into a dedicated thread), the RI should have a Launcher class to do that, and other provider will have to use it without breaking their own launcher...

For sur we can use some annotation to say that the resource loading should be performed in a custom thread, but I think that the RI will have to make some choices, we will later when all stuff will be analyzed.