Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Feature Freeze before Final Draft
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: Feature Freeze before Final Draft
- Date: Wed, 22 Jun 2016 11:39:24 +0200
Hi,
Making the transition of getProductUnits() in Unit (for now unless there's
a vast majority of strong arguments against it, consistently using the
plural *Units feels better even if EC members voting may not always go into
such detail;-) I saw we have a similar method name in Dimension. Please
look at
https://java.net/jira/browse/UNITSOFMEASUREMENT-193 and advise, if
the "*Product* -> *Base*" refactoring should also occur there, or if it's a
different case for Dimension.
The JavaDoc is oriented on descriptions by e.g. Wikipedia:
https://en.wikipedia.org/wiki/Dimensional_analysis#Mathematical_properties
Referring to "Fundamental Dimensions" or also "Fundamental Units" (another
synonym for "Base Units")
In UCAR they called it "factors" but its API consists of several additional
elements, so we cannot directly compare them any more.
https://en.wikipedia.org/wiki/Physical_quantity usually speaks of "Base
Quantity" so do you see a need to rename getProductDimensions() to either
getBaseDimensions() or e.g. getFundamentalDimensions() ?
Thanks,
Werner
On Tue, Jun 21, 2016 at 6:25 PM, Werner Keil
<
>
wrote:
>
Not sure, if that's a good idea?
>
>
Keep in mind, with the whole election and a huge number of EE JSRs all
>
facing Renewal Ballot immediately after JavaOne I don't think we get a
>
ballot done before the very last moment (since Public Review started in
>
January the latest a Final ballot should start was also the end of the
>
year) with 10 or more EE JSRs facing Renewal Ballot automatically plus
>
there could be new EC members (ratified like V2COM, SouJava or others quite
>
rarely, only if a member should no longer wish to participate) to vote on
>
it then.
>
>
I'm not afraid either way, even if others than myself should be elected
>
(given the ability to participate I have a solid track record, so likely
>
run again unless something "very bad" happened with the whole Java EE
>
situation and the role of the EC;-) but it would be a hassle to go into
>
ballot then, especially if the Java EE situation could escalate and EC
>
members may be drawn into a "negative spirit" like in 2007.
>
Jean-Marie who hosted that "famous barn F2F" probably knows that best,
>
others in the EC like Geir also should, so would we rather try to reach
>
Final before that, around the July/August timeframe, and leave Hackathon
>
etc. for a possible MR or 2.0 or should we risk getting sucked into that
>
sort of "politics" again as 275 partly did? (the Public Review ballot was
>
literally a month after the Oracle takeover:
>
https://en.wikipedia.org/wiki/Sun_acquisition_by_Oracle)
>
>
Happy to hear a quick response by others, Jean-Marie and if they can
>
Martin on behalf of major downstream projects like GeoAPI.
>
>
Keep in mind, Patrick stated, using JSR 275 is "half-legal" especially for
>
commercial products, so we should also offer them a safe alternative as
>
soon as possible.
>
>
Cheers,
>
Werner
>
>
>
>
On Tue, Jun 21, 2016 at 6:03 PM, Leonardo Lima
>
<
>
>
wrote:
>
>
> Werner,
>
>
>
> I think it should be best to have the JSR as "almost-final" (I believe
>
> that'd be proposed final draft?) by JavaOne. That way, we can still gather
>
> input in hackergartens and/or BoFs. We can have everything ready to file
>
> for Final just after 1-2 weeks after J1.
>
>
>
> Regards,
>
> Leo.
>
>
>
> On Tue, Jun 21, 2016 at 7:48 AM, Werner Keil
>
> <
>
>
> wrote:
>
>
>
>> Please also review the Spec Document again if you can.
>
>> The license paragraph exists for "Evaluation" and "Implementation". Only
>
>> when the Final version is approved and released both will go out to
>
>> separate download deliverables (see all major new JSRs that went final
>
>> like
>
>> Money https://jcp.org/aboutJava/communityprocess/final/jsr354/index.html,
>
>> JCache, etc.)
>
>>
>
>> For the Proposed Final Draft only the "Evaluation" part is relevant.
>
>> Aside from brushing up to SPI changes, I added another Use Case chapter
>
>> on DevOps and Cloud. Quite a hot topic and thanks to being picked up by
>
>> PCP/Parfait with the latest releases it is of course a good thing to
>
>> mention (aside from everyone staring at or rushing to the Cloud right
>
>> now;-)
>
>>
>
>> We aim for Code-freeze of the API and RI pretty much around June 30/July
>
>> 1 (if there was any issue or significant input for changes we still have
>
>> the weekend)
>
>> July 4 is a holiday in the US, so PMO would not process anything before
>
>> the 5th, so around then looks good to submit it. Depending on how fast
>
>> it's
>
>> put online, the community and EC members may see it before the EC call on
>
>> July 12th, but the Proposed Final Draft is just for review, no ballot
>
>> there
>
>> yet. JSR 354 had its PFD on March 13 and Approval Ballot on April 28.
>
>> Final
>
>> was out exactly 2 months later on May 13. Even if JavaOne was to snub and
>
>> ignore it again (unlike the Awards) or Oracle ended up with a "JDK
>
>> Personality Show" while the community looks for other forums like DevoXX,
>
>> etc. a Final date ideally before JavaOne looks best and looking at 354
>
>> doable.
>
>> There's a Creation Review for Java SE 9 Umbrella (actually right now)
>
>> and JSON-B has a Public Review Ballot at the end of July. So it could be
>
>> best to aim at a nearby date, otherwise there are not too many ballots
>
>> anyway.
>
>> JSR 330 (Dependency Injection) showed, there seems almost no rule for a
>
>> minimum PFD duration. It went out on Sep 22 followed by the ballot
>
>> starting
>
>> only a week later on Sep 29. I'd say at least 14 days could be good in our
>
>> case if asked, if you think we should take longer, please advise.
>
>>
>
>> Cheers,
>
>> Werner
>
>>
>
>
>
>
>