From mike.duigou at oracle.com  Thu May  1 05:56:28 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 30 Apr 2014 22:56:28 -0700
Subject: Hello
In-Reply-To: <1398898791.58505.YahooMailNeo@web172405.mail.ir2.yahoo.com>
References: <1398898791.58505.YahooMailNeo@web172405.mail.ir2.yahoo.com>
Message-ID: <BE676FFC-2AE6-4874-A930-B3FE2E3063F9@oracle.com>

Welcome Jeff/Olivier!

Your past contributions and insights have been appreciated and I am glad to hear that you have now completed your OCA.

I haven't had a chance to follow up on the thread "AbstractCollection.removeAll(Collection) and AbstractSet.removeAll(Collection)" from way back in 2011 but rest assured I have not forgotten about it. It is, embarrassingly, the oldest item in my "tagged todo" features queue.

Welcome!

Mike

On Apr 30 2014, at 15:59 , Jeff Hain <jeffhain at rocketmail.com> wrote:

> 
> 
> I'm Olivier Masle, from France, and just joined the
> OCA signatories - but have been in core-libs-dev
> for a few years already.
> 
> 
> I spare-time-code only from time to time (*), but
> will happily contribute if my ideas are worth it
> (Brian thought one was, so here I am).
> 
> 
> (*) Mostly reinventing or upgrading the wheel in some
> small and low-level (for Java) open source libraries,
> with mostly performances and simplicity in mind,
> under "Jeff Hain" alias
> (https://sourceforge.net/u/omaamo/profile/
> and http://code.google.com/p/jodk/).
> 
> 
> Regards.



From martijnverburg at gmail.com  Thu May  1 09:08:06 2014
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 1 May 2014 10:08:06 +0100
Subject: Recommended usage of backports in JBS
In-Reply-To: <53615F12.3020305@oracle.com>
References: <536151AC.2010600@oracle.com>
	<53615F12.3020305@oracle.com>
Message-ID: <CAP7YuAR03d-M_MEU-5ASBk7KMdZ6Lqqg4Lyy9f3WF8uhg_=H6A@mail.gmail.com>

Hi all,

Where is this developers guide & how can we help?  We have a few things to
add to a Developers Guide.

Cheers,
Martijn


On 30 April 2014 21:37, Jonathan Gibbons <jonathan.gibbons at oracle.com>wrote:

> Joe,
>
> This would seem to be potentially excellent content for the OpenJDK
> Developers' Guide.
>
> -- Jon
>
>
> On 04/30/2014 12:40 PM, Joe Darcy wrote:
>
>> Hello,
>>
>> It has come to my attention that there are continuing questions about
>> policies around how to use backports in JBS. This email is intended to give
>> guidelines on effective usage of backports and to provide a brief design
>> rationale for the backport facility.
>>
>> By default, JIRA uses multiple values in the "Fix Version/s" field to
>> track a bug in multiple releases. When JBS was being designed, this out of
>> the box "Fix Version/s" facility was judged as inadequate for tracking JDK
>> bugs across numerous release trains and versions. Semantically, for each
>> release a tuple of information was wanted like:
>>
>>     (status in release, resolution in release, assignee for release,
>> release-specific comments)
>>
>> An approximation to this design was implemented in JBS. [1] Instead of
>> changing this set of fields to be tuples in JIRA, a release-specific issue
>> with these fields (and all the other fields) is used to store the
>> release-specific information. The issues for releases other than the
>> release used for the main issues have the custom "backport" issue type and
>> are displayed grouped together in the main bug. The setting of the "Fix
>> Version/s" field indicates which release a particular backport is tracking.
>> If a bug was pushed to both JDK 9 and, say, JDK 8u20, there would be two
>> issues for the conceptual bug in JBS. The canonical configuration for a
>> case like this is a main bug with its "Fix Version/s" field set to "9" and
>> a backport with its "Fix Version/s" set to 8u20.
>>
>> I think of backports as vestigial issues whose only contribution is
>> holding the value of a few fields. All notions of the identity of the issue
>> relate to the master issue. A consequence of this is the first rule of
>> backports:
>>
>> First rule of backports:
>>     Only push changesets using the master bug id and *not* a backport bug
>> id.
>>
>> (It would be technically possible for a tool like jcheck to verify that a
>> bug id corresponded to a main bug rather than a backport. As a matter of
>> design, we have not wanted to prevent pushes from going through due to an
>> outage of the bug database. However, we may want to reconsider the design
>> trade offs in this regard and perform such a check if JBS is available, but
>> not block the push from going through if JBS happens to be down.)
>>
>> Other questions about  backports concern when backports should be
>> created, which leads to the second rule of backports:
>>
>> Second rule of backports:
>>     Only create a backport when it is necessary to do so.
>>
>> It is necessary to create a backport as soon as there is a need to track
>> release-specific information about an issue. Sometimes a backport is not
>> needed until a fix is pushed to a particular release.
>>
>> For example, say a bug has already been fixed in JDK 9 and an engineer
>> believes the fix would be beneficial to the 8 update train. Following the
>> process for backporting fixes to the always-open mainline 8 update train
>> [2], the engineer would request approval for the backport. Assuming that
>> approval was granted, the fix is pushed to the appropriate 8 update repo
>> using the main bug id. At this point, the Hg update daemon would create a
>> backport for the particular 8 update release the 8u repo currently
>> corresponded to, say, 8u20. [3] The Hg updater process would also set the
>> fields of the new backport accordingly, status = resolved, resolution =
>> fixed, etc.
>>
>> Letting Hg updater create backports is the least error prone method for
>> creating them and is the recommended procedure when other factors don't
>> require the creation of a backport sooner.
>>
>> A corollary to the second rule is that if a backport is created before a
>> change is pushed, it should be created with the least specific information
>> necessary. For example, if it doesn't matter very much which 8 update
>> release the fix goes into, the backport should be created with a "Fix
>> Version/s" of 8-pool rather than a particular 8 update release like 8u20 or
>> 8u40. That way, if the bug is fixed in any member of the 8 update family,
>> Hg Updater will see the existing backport for 8-pool and adjust the Fix
>> Version/s field of that backport to the specific 8 release where the fix is
>> going.
>>
>> When a fix needs to be targeted to a specific update release and tracking
>> for that release is needed before the fix gets pushed, then it is
>> reasonable to create a backport with a Fix Version/s field set to that
>> release ahead of time. (This is commonly the case for bugs being tracked
>> for inclusion in a security release.)
>>
>> Consider another bug to be fixed in JDK 9 and specifically also in 8u20.
>> In that case, two issues are needed, a main bug and a backport. What should
>> be the Fix Version/s of the main bug and what should be the Fix Version/s
>> of the backport? It is preferable if the main bug has a Fix Version/s
>> setting of 9 and the backport has a setting of 8u20. This dovetails with
>> the 8 update release policy of not approving backports that haven't already
>> been fixed in JDK 9. However, it is marginally acceptable for the main bug
>> to have Fix Version/s of 8u20 and the backport a Fix Version/s of 9 *as
>> long as* the first rule is followed and the push to 9 uses the main bug id
>> (even though the main bug was in 8u20). (In a case like this the "backport"
>> is just going in a negative direction ;-)
>>
>> I hope this helps clarify the recommended use of backports.
>>
>> Cheers,
>>
>> -Joe
>>
>> [1] JBS Overview, https://wiki.openjdk.java.net/
>> display/general/JBS+Overview
>>
>> [2] http://openjdk.java.net/projects/jdk8u/
>>
>> [3] Over time, pushes to the always-open mainline repos for the 8 update
>> release correspond to makigg a fix in a different particular 8 update
>> release. For example, today a fix pushed to one of these repos will be
>> shipped as part of 8u20, but in a few months time, a fix pushed to one of
>> these repos will be fixed as part of 8u40. Meta-data on the Hg server used
>> by Hg updater records which particular 8 update release a push to the 8
>> update repo will correspond to.
>>
>
>


From ag at 4js.com  Mon May  5 15:00:58 2014
From: ag at 4js.com (Alex Geller)
Date: Mon, 05 May 2014 17:00:58 +0200
Subject: Hello
Message-ID: <5367A7AA.2060001@4js.com>

Hello,
now that my OCA was processed I would like to take the opportunity to 
introduce myself.
My name is Alex Geller and I am looking for a sponsor for a patch to 
improve the performance of Postscript output (posted in February this 
year to 2d-dev).
My work involves the creation of potentially larger document in various 
formats (Graphics2D, PDF, SVG, XLS(X), RTF, ..) in serial manner.
Over the years I have made a few small source code contributions to 
Digia Qt, Google sfntly and Apache POI (SXSSF).
Kind Regards,
Alex



From mark.reinhold at oracle.com  Mon May  5 21:13:49 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 05 May 2014 14:13:49 -0700
Subject: Second draft proposal: JEP 2.0
Message-ID: <20140505141349.114750@eggemoggin.niobe.net>

Thanks to everyone who commented on the first draft.  I've posted a
second draft here:

    http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

The major differences from the first draft are:

  - JEPs will be maintained entirely in JBS;

  - The "Research" JEP type has been dropped, since long-term research
    work can be tracked as subtasks of a Feature JEP;

  - The standard workflow has been simplified from ten states to eight,
    by removing the Planning and Funded states; and

  - The workflow for Informational and Process JEPs is now defined.

Most of my concerns about JIRA not being a good system for structured,
long-form text documents [1] have been addressed by Brian Beck and
Tony Squier.  They've implemented a Markdown plugin for JIRA so that
the bodies of JEPs can continue to be written in a reasonable markup
language, and they're customizing JIRA's CSS to fix some of its more
glaring typographical issues.  These changes, in combination with a
suitable browser plugin (e.g., [2]) to enable editing in Emacs (or
the editor of your choice), seem a good-enough solution for those of
us who write and edit JEPs, and they will display JEPs in a way that
is just about as readable as the current archive.

Brian and Tony are working to implement the new JEP issue type in JBS.
It's not quite ready to go, so stay tuned for further information.

If you have comments or suggestions on this draft, please send them
in a public reply to this message by next Monday, 12 May 2014.

- Mark


[1] http://mail.openjdk.java.net/pipermail/discuss/2014-April/003354.html
[2] https://addons.mozilla.org/en-US/firefox/addon/its-all-text/


From mark.reinhold at oracle.com  Mon May  5 21:20:57 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 05 May 2014 14:20:57 -0700
Subject: Draft proposal: JEP 2.0
In-Reply-To: <2A59EA4E-1A33-437F-A4AD-AB43FC9E31C2@oracle.com>
References: <20140408135412.415597@eggemoggin.niobe.net>,
	<2A59EA4E-1A33-437F-A4AD-AB43FC9E31C2@oracle.com>
Message-ID: <20140505142057.881723@eggemoggin.niobe.net>

2014/4/18 5:34 -0700, karen.kinnear at oracle.com:
> A couple of questions on the JEP workflow.
> 
> 1) Before "Integrated" could we add a "Validated" state?
> 
> It is probably already assumed that prior to Integrated, that a JEP's
> owner is required to have the code pass unit tests as well as system
> tests.
> 
> Would there be value in calling out a separate state here, such as
> "Validated"?
> 
> This could be of help in ensuring that unit tests are ready and pass
> before code gets integrated. It might also be of extra help for folks
> who need assistance in running any system tests.

I don't think it's worth encoding such details into the JEP Process
itself.  The owner of a Feature JEP can use subtasks to track specific
testing activities, and assign them to the appropriate people (e.g.,
those who run the relevant system tests) in order to make sure they
get done.

> 2) Funded
> 
> Could you possibly add performance testing to the funded detail list?
> I know the current statement is not intended to be exhaustive, but it
> might be helpful to explicitly add performance.

The "Funded" state is gone, but I've added performance tests to the list
of items that should be covered in a Feature JEP's engineering plan.

- Mark


From mark.reinhold at oracle.com  Mon May  5 21:26:27 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 05 May 2014 14:26:27 -0700
Subject: Draft proposal: JEP 2.0
In-Reply-To: <534F4615.2060107@oracle.com>
References: <534D89AD.6030505@bothner.com>, <534DA018.4080209@oracle.com>,
	<534F1DF4.2040708@oracle.com>, <534F4615.2060107@oracle.com>
Message-ID: <20140505142627.250880@eggemoggin.niobe.net>

2014/4/16 13:10 -0700, jon.masamitsu at oracle.com:
> On 4/16/2014 5:19 PM, Jonathan Gibbons wrote:
>> On 04/15/2014 02:09 PM, Jon Masamitsu wrote:
>>>> The JEP owner is expected to update the Alert Status on a weekly 
>>>> basis once a JEP is Funded and active development work is under way. 
>>>> If the Alert Status is Yellow or Red then the owner must use the 
>>>> Alert Reason field to explain what is required to return the Status 
>>>> to Green. This way everyone working on the release or otherwise 
>>>> interested in the JEP can easily understand its current state.
>>>
>>> This sounds a lot like the status I have to report to my managers.
>>> Except that I talk to my manager about how things are going.  This I
>>> have to compose and publish.  Sorry but it's something that I'll
>>> easily forget to do.
>> 
>> I think the point is that this will supersede some of the ad-hoc
>> infrastructure we currently use to track project progress, so this is
>> not something that you'll forget to do: it is simply a formalized
>> replacement of what you do today.

Exactly!

>>                                    It is just an "enum"
>> (green/yellow/red) and a text field. I doubt that folk are expecting
>> you to write an essay each week for the Alert Reason field.

Nope.

> So you're saying that management will accept the updates to the JEP as
> the way of tracking progress on a project.  That I like.

Yes, that's exactly the intent (at least as far as Oracle management
is concerned).

- Mark


From bengt.rutisson at oracle.com  Tue May  6 09:40:01 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 06 May 2014 11:40:01 +0200
Subject: Second draft proposal: JEP 2.0
In-Reply-To: <20140505141349.114750@eggemoggin.niobe.net>
References: <20140505141349.114750@eggemoggin.niobe.net>
Message-ID: <5368ADF1.802@oracle.com>


Hi Mark,

Thanks for the updated JEP 2.0 proposal. Looks much better to me.

One question about the initial step of a JEP. The proposal states:

"Any particular proposal must be open for discussion for at least one 
calendar week, major holidays excepted."

This seems reasonable to me. What is not clear from this description is 
when this calendar week starts. Is it when I create the JEP in the JBS 
system or is there some kind of publish step in between as with the 1.0 
version of the JEP? Basically my question is, is there an SLA for how 
long I have to wait from creating a JEP until I can start pushing 
changes for it?

Thanks,
Bengt



On 2014-05-05 23:13, mark.reinhold at oracle.com wrote:
> Thanks to everyone who commented on the first draft.  I've posted a
> second draft here:
>
>      http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>
> The major differences from the first draft are:
>
>    - JEPs will be maintained entirely in JBS;
>
>    - The "Research" JEP type has been dropped, since long-term research
>      work can be tracked as subtasks of a Feature JEP;
>
>    - The standard workflow has been simplified from ten states to eight,
>      by removing the Planning and Funded states; and
>
>    - The workflow for Informational and Process JEPs is now defined.
>
> Most of my concerns about JIRA not being a good system for structured,
> long-form text documents [1] have been addressed by Brian Beck and
> Tony Squier.  They've implemented a Markdown plugin for JIRA so that
> the bodies of JEPs can continue to be written in a reasonable markup
> language, and they're customizing JIRA's CSS to fix some of its more
> glaring typographical issues.  These changes, in combination with a
> suitable browser plugin (e.g., [2]) to enable editing in Emacs (or
> the editor of your choice), seem a good-enough solution for those of
> us who write and edit JEPs, and they will display JEPs in a way that
> is just about as readable as the current archive.
>
> Brian and Tony are working to implement the new JEP issue type in JBS.
> It's not quite ready to go, so stay tuned for further information.
>
> If you have comments or suggestions on this draft, please send them
> in a public reply to this message by next Monday, 12 May 2014.
>
> - Mark
>
>
> [1] http://mail.openjdk.java.net/pipermail/discuss/2014-April/003354.html
> [2] https://addons.mozilla.org/en-US/firefox/addon/its-all-text/



From mathias.axelsson at oracle.com  Tue May  6 12:40:53 2014
From: mathias.axelsson at oracle.com (Mathias Axelsson)
Date: Tue, 6 May 2014 14:40:53 +0200
Subject: Second draft proposal: JEP 2.0
In-Reply-To: <20140505141349.114750@eggemoggin.niobe.net>
References: <20140505141349.114750@eggemoggin.niobe.net>
Message-ID: <E9C4E553-945E-4753-981E-3121E72497D5@oracle.com>

Hi Mark,

I think this update looks really good. One thing that is a little bit unclear to me is the matching of fields in JEP 1.0 vs JBS regarding Author, but I may have interpreted this incorrectly.

In the section Information in JBS issues (in table 1 and 2) I interpret it as:

- Reporter (JBS) maps to original author in JEP 1.0
- Author (JBS) maps to Author in JEP 1.0

The description text later on says "The Author field is used to record the original author of the JEP. It?s a free-form text field, since the original author might not have a username in JBS.".

Given this and that Reporter is set to the person filling an issue in JBS, should this instead state:

- Reporter (JBS) maps to Author (JEP 1.0)
- Author (JBS) maps to original author (JEP 1.0)

Kind regards,
Mathias

On 5 maj 2014, at 23:13, mark.reinhold at oracle.com wrote:

> Thanks to everyone who commented on the first draft.  I've posted a
> second draft here:
> 
>    http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> 
> The major differences from the first draft are:
> 
>  - JEPs will be maintained entirely in JBS;
> 
>  - The "Research" JEP type has been dropped, since long-term research
>    work can be tracked as subtasks of a Feature JEP;
> 
>  - The standard workflow has been simplified from ten states to eight,
>    by removing the Planning and Funded states; and
> 
>  - The workflow for Informational and Process JEPs is now defined.
> 
> Most of my concerns about JIRA not being a good system for structured,
> long-form text documents [1] have been addressed by Brian Beck and
> Tony Squier.  They've implemented a Markdown plugin for JIRA so that
> the bodies of JEPs can continue to be written in a reasonable markup
> language, and they're customizing JIRA's CSS to fix some of its more
> glaring typographical issues.  These changes, in combination with a
> suitable browser plugin (e.g., [2]) to enable editing in Emacs (or
> the editor of your choice), seem a good-enough solution for those of
> us who write and edit JEPs, and they will display JEPs in a way that
> is just about as readable as the current archive.
> 
> Brian and Tony are working to implement the new JEP issue type in JBS.
> It's not quite ready to go, so stay tuned for further information.
> 
> If you have comments or suggestions on this draft, please send them
> in a public reply to this message by next Monday, 12 May 2014.
> 
> - Mark
> 
> 
> [1] http://mail.openjdk.java.net/pipermail/discuss/2014-April/003354.html
> [2] https://addons.mozilla.org/en-US/firefox/addon/its-all-text/



From martijnverburg at gmail.com  Tue May  6 12:55:02 2014
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 6 May 2014 13:55:02 +0100
Subject: Hello
In-Reply-To: <5367A7AA.2060001@4js.com>
References: <5367A7AA.2060001@4js.com>
Message-ID: <CAP7YuATZvHGhdrM--85OwEfyGzPcku5kgfdQVfU_QLJgo_eMFw@mail.gmail.com>

Hi Alex,

Welcome to OpenJDK, we look forward to your contributions, not many folks
work in your area!

Cheers,
Martijn


On 5 May 2014 16:00, Alex Geller <ag at 4js.com> wrote:

> Hello,
> now that my OCA was processed I would like to take the opportunity to
> introduce myself.
> My name is Alex Geller and I am looking for a sponsor for a patch to
> improve the performance of Postscript output (posted in February this year
> to 2d-dev).
> My work involves the creation of potentially larger document in various
> formats (Graphics2D, PDF, SVG, XLS(X), RTF, ..) in serial manner.
> Over the years I have made a few small source code contributions to Digia
> Qt, Google sfntly and Apache POI (SXSSF).
> Kind Regards,
> Alex
>
>


From brian.beck at oracle.com  Tue May  6 23:20:15 2014
From: brian.beck at oracle.com (Brian Beck)
Date: Tue, 06 May 2014 16:20:15 -0700
Subject: Second draft proposal: JEP 2.0
In-Reply-To: <20140505141349.114750@eggemoggin.niobe.net>
References: <20140505141349.114750@eggemoggin.niobe.net>
Message-ID: <53696E2F.8070300@oracle.com>

An implementation of Mark's current proposal should show up in JBS 
momentarily.  Since discussion on the proposal is not yet complete, 
please consider it a prototype. There are one or two things that aren't 
quite right yet.  Most notably, the workflow for Process and 
Informational JEPs does not exist.  We will be making improvements and 
adapting to whatever changes occur as a result of the discussion over 
the next couple of weeks.

Please kick the tires and give us feedback.  You may enter "real" JEPs 
if you like but with two caveats.  First, we will make every effort to 
preserve the data as we evolve the system over the next couple of weeks, 
but there are no guarantees.  If some change is needed that can't be 
made without data loss, you may be asked to re-enter your work.  Second, 
the OpenJDK Lead may or may not be processing Submitted JEPs just yet, 
so don't expect it to proceed through the process.

Looking forward to feedback.

Brian.



On 5/5/14 2:13 PM, mark.reinhold at oracle.com wrote:
> Thanks to everyone who commented on the first draft.  I've posted a
> second draft here:
>
>      http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>
> The major differences from the first draft are:
>
>    - JEPs will be maintained entirely in JBS;
>
>    - The "Research" JEP type has been dropped, since long-term research
>      work can be tracked as subtasks of a Feature JEP;
>
>    - The standard workflow has been simplified from ten states to eight,
>      by removing the Planning and Funded states; and
>
>    - The workflow for Informational and Process JEPs is now defined.
>
> Most of my concerns about JIRA not being a good system for structured,
> long-form text documents [1] have been addressed by Brian Beck and
> Tony Squier.  They've implemented a Markdown plugin for JIRA so that
> the bodies of JEPs can continue to be written in a reasonable markup
> language, and they're customizing JIRA's CSS to fix some of its more
> glaring typographical issues.  These changes, in combination with a
> suitable browser plugin (e.g., [2]) to enable editing in Emacs (or
> the editor of your choice), seem a good-enough solution for those of
> us who write and edit JEPs, and they will display JEPs in a way that
> is just about as readable as the current archive.
>
> Brian and Tony are working to implement the new JEP issue type in JBS.
> It's not quite ready to go, so stay tuned for further information.
>
> If you have comments or suggestions on this draft, please send them
> in a public reply to this message by next Monday, 12 May 2014.
>
> - Mark
>
>
> [1] http://mail.openjdk.java.net/pipermail/discuss/2014-April/003354.html
> [2] https://addons.mozilla.org/en-US/firefox/addon/its-all-text/



From bob.vandette at oracle.com  Wed May  7 14:08:16 2014
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 7 May 2014 10:08:16 -0400
Subject: Result: New Project: Device I/O
Message-ID: <1298C428-AFDC-45BD-8881-B1E0E1B98430@oracle.com>

Voting for the Device I/O Project [1] is now closed.

Yes: 8
Veto: 0
Abstain: 0

Accordining to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the creation of this project.

-Bob.

[1] http://mail.openjdk.java.net/pipermail/announce/2014-April/000170.html
[2] http://openjdk.java.net/bylaws#lazy-consensus




From ag at 4js.com  Mon May 12 06:55:27 2014
From: ag at 4js.com (Alex Geller)
Date: Mon, 12 May 2014 08:55:27 +0200
Subject: Hello
In-Reply-To: <CAP7YuATZvHGhdrM--85OwEfyGzPcku5kgfdQVfU_QLJgo_eMFw@mail.gmail.com>
References: <5367A7AA.2060001@4js.com>
	<CAP7YuATZvHGhdrM--85OwEfyGzPcku5kgfdQVfU_QLJgo_eMFw@mail.gmail.com>
Message-ID: <5370705F.2070602@4js.com>

Thanks for the encouraging words.
Kind regards,
Alex
On 5/6/2014 2:55 PM, Martijn Verburg wrote:
> Hi Alex,
>
> Welcome to OpenJDK, we look forward to your contributions, not many 
> folks work in your area!
>
> Cheers,
> Martijn
>
>
> On 5 May 2014 16:00, Alex Geller <ag at 4js.com <mailto:ag at 4js.com>> wrote:
>
>     Hello,
>     now that my OCA was processed I would like to take the opportunity
>     to introduce myself.
>     My name is Alex Geller and I am looking for a sponsor for a patch
>     to improve the performance of Postscript output (posted in
>     February this year to 2d-dev).
>     My work involves the creation of potentially larger document in
>     various formats (Graphics2D, PDF, SVG, XLS(X), RTF, ..) in serial
>     manner.
>     Over the years I have made a few small source code contributions
>     to Digia Qt, Google sfntly and Apache POI (SXSSF).
>     Kind Regards,
>     Alex
>
>



From franz.van.betteraey at googlemail.com  Wed May 14 20:21:44 2014
From: franz.van.betteraey at googlemail.com (Franz van Betteraey)
Date: Wed, 14 May 2014 22:21:44 +0200
Subject: Java Code Conventions Update
In-Reply-To: <51ED8585.2060202@googlemail.com>
References: <51ED8585.2060202@googlemail.com>
Message-ID: <5373D058.6080300@googlemail.com>

Hi all,

Meanwhile, the good old Java code conventions from 1999 seem to have gone.
(http://stackoverflow.com/questions/22961733/oracle-java-code-conventions)

Does anybody know if there is an official (Oracle) or community 
(OpenJDK) attempt to update them?
Or is the "Google Java Style" guide the new de facto standard 
(http://google-styleguide.googlecode.com/svn/trunk/javaguide.html)?

Kind regards,
   Franz


Am 22.07.2013 21:18, schrieb Franz van Betteraey:
> Hi there,
>
> I find it very helpful that Java Code Conventions exist for a long 
> time now. They really "improve the readability of the software, 
> allowing engineers to understand new code more quickly and thoroughly" 
> (from the Code Conventions web page).
>
> But while the Java language evolves the code conventions remain the 
> same. Since the Java Code Conventions were last updated in 1999 
> several new Java language features were introduced including lambdas 
> in the upcoming version of Java 8.
>
> Would it not be nice to update the Code Conventions so that we do not 
> need to follow rules from the last century in Java 8 (which are not 
> bad but probably missing relevant parts)?
>
> I wonder if (or where) someone could make an "official" request for 
> this. Dalibor Topic suggested to bring this up on this discussion list 
> (https://twitter.com/robilad/status/338350845315928064) - so that's 
> what I do now.
>
> Thanks for any support on this.
>
> Kind regards
>   Franz



From nick.radov at optum.com  Sat May 17 00:26:23 2014
From: nick.radov at optum.com (Radov, Nicholas O)
Date: Sat, 17 May 2014 00:26:23 +0000
Subject: HTTP 404 on Oracle Java code conventions
Message-ID: <0D30AB9F36B3B24DA8D29EB394F7F2142A8619A5@APSWP0948.ms.ds.uhc.com>

I'm posting this on the discuss list in the hope that someone at Oracle will see it and take action. All of the links on the "Code Conventions for the Java Programming Language" web page are broken.

http://www.oracle.com/technetwork/java/index-135089.html

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


From donald.smith at oracle.com  Sat May 17 02:21:16 2014
From: donald.smith at oracle.com (Donald Smith)
Date: Fri, 16 May 2014 22:21:16 -0400
Subject: HTTP 404 on Oracle Java code conventions
In-Reply-To: <0D30AB9F36B3B24DA8D29EB394F7F2142A8619A5@APSWP0948.ms.ds.uhc.com>
References: <0D30AB9F36B3B24DA8D29EB394F7F2142A8619A5@APSWP0948.ms.ds.uhc.com>
Message-ID: <5376C79C.50205@oracle.com>

There's a bug at [1] for that, suggest commenting there (I'll kick it 
again now).
[1] https://bugs.openjdk.java.net/browse/JDK-8039151

I'm not sure what it should say instead, but the linked pages seem to 
have been removed.  Oddly, I do remember this guide from 1999 (15 years 
ago!!) -- and I believe it stopped being updated because that was right 
around the time that IDEs started just automatically doing this for you, 
so the conversations moved there.

  - Don

On 16/05/2014 8:26 PM, Radov, Nicholas O wrote:
> I'm posting this on the discuss list in the hope that someone at Oracle will see it and take action. All of the links on the "Code Conventions for the Java Programming Language" web page are broken.
>
> http://www.oracle.com/technetwork/java/index-135089.html
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.



From fcassia at gmail.com  Sat May 17 02:53:53 2014
From: fcassia at gmail.com (Fernando Cassia)
Date: Fri, 16 May 2014 23:53:53 -0300
Subject: HTTP 404 on Oracle Java code conventions
In-Reply-To: <0D30AB9F36B3B24DA8D29EB394F7F2142A8619A5@APSWP0948.ms.ds.uhc.com>
References: <0D30AB9F36B3B24DA8D29EB394F7F2142A8619A5@APSWP0948.ms.ds.uhc.com>
Message-ID: <CACGw4H56Fk1Tc6hfYGppU6MtR4SSR8S4QiD2sYgdxxr2UHhjgw@mail.gmail.com>

On Fri, May 16, 2014 at 9:26 PM, Radov, Nicholas O <nick.radov at optum.com>wrote:

> I'm posting this on the discuss list in the hope that someone at Oracle
> will see it and take action. All of the links on the "Code Conventions for
> the Java Programming Language" web page are broken.
>
> http://www.oracle.com/technetwork/java/index-135089.html
>

By googling the document title with the addition of ".pdf" I was able to
find such document online as PDF on several other sites, don't know how
recent they are.

ie
www.havelund.com/Publications/*JavaCoding*Standard.




*pdfSee
alsohttp://www.javacodegeeks.com/2012/10/java-coding-conventions-considered-harmful.html
<http://www.javacodegeeks.com/2012/10/java-coding-conventions-considered-harmful.html>FC*
-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell


From fcassia at gmail.com  Sat May 17 02:58:14 2014
From: fcassia at gmail.com (Fernando Cassia)
Date: Fri, 16 May 2014 23:58:14 -0300
Subject: HTTP 404 on Oracle Java code conventions
In-Reply-To: <CACGw4H56Fk1Tc6hfYGppU6MtR4SSR8S4QiD2sYgdxxr2UHhjgw@mail.gmail.com>
References: <0D30AB9F36B3B24DA8D29EB394F7F2142A8619A5@APSWP0948.ms.ds.uhc.com>
	<CACGw4H56Fk1Tc6hfYGppU6MtR4SSR8S4QiD2sYgdxxr2UHhjgw@mail.gmail.com>
Message-ID: <CACGw4H7kSNmGJ=0+5oBWs6S8REbzLLG+JrcTg=Pqz5KJQzCVhQ@mail.gmail.com>

On Fri, May 16, 2014 at 11:53 PM, Fernando Cassia <fcassia at gmail.com> wrote:

> ie
> www.havelund.com/Publications/*JavaCoding*Standard.
>
>
>
> *pdfSee
> alsohttp://www.javacodegeeks.com/2012/10/java-coding-conventions-considered-harmful.html
> <http://www.javacodegeeks.com/2012/10/java-coding-conventions-considered-harmful.html>
> *
>

This will be of interest, too.

http://phillyjug.files.wordpress.com/2013/03/philly_jug.pdf

FC
-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell


From philip.race at oracle.com  Sat May 17 14:29:50 2014
From: philip.race at oracle.com (Phil Race)
Date: Sat, 17 May 2014 07:29:50 -0700
Subject: HTTP 404 on Oracle Java code conventions
In-Reply-To: <5376C79C.50205@oracle.com>
References: <0D30AB9F36B3B24DA8D29EB394F7F2142A8619A5@APSWP0948.ms.ds.uhc.com>
	<5376C79C.50205@oracle.com>
Message-ID: <5377725E.1020007@oracle.com>

The dead links need to be removed for sure and replaced with something else.
However my understanding is that the positioning of the doc on the oracle
website made it appear to be recommendations for the way all Java code
should be written. Given that it doesn't cover newer features, and clearly
Oracle isn't going to (or going to want to) enforce style guidelines for
non-Oracle code it was deliberately removed.

However for projects in which Oracle *is* involved (ie openjdk) there
seems to be a case for reviving this document in some limited form.
ie limited in the material it covers to generally accepted and customary
openjdk coding guidelines, and limited to claiming to be an openjdk 
document,
but not a document for the entire world.

-phil.

On 5/16/14 7:21 PM, Donald Smith wrote:
> There's a bug at [1] for that, suggest commenting there (I'll kick it 
> again now).
> [1] https://bugs.openjdk.java.net/browse/JDK-8039151
>
> I'm not sure what it should say instead, but the linked pages seem to 
> have been removed.  Oddly, I do remember this guide from 1999 (15 
> years ago!!) -- and I believe it stopped being updated because that 
> was right around the time that IDEs started just automatically doing 
> this for you, so the conversations moved there.
>
>  - Don
>
> On 16/05/2014 8:26 PM, Radov, Nicholas O wrote:
>> I'm posting this on the discuss list in the hope that someone at 
>> Oracle will see it and take action. All of the links on the "Code 
>> Conventions for the Java Programming Language" web page are broken.
>>
>> http://www.oracle.com/technetwork/java/index-135089.html
>>
>> This e-mail, including attachments, may include confidential and/or
>> proprietary information, and may be used only by the person or entity
>> to which it is addressed. If the reader of this e-mail is not the 
>> intended
>> recipient or his or her authorized agent, the reader is hereby notified
>> that any dissemination, distribution or copying of this e-mail is
>> prohibited. If you have received this e-mail in error, please notify the
>> sender by replying to this message and delete this e-mail immediately.
>



From scolebourne at joda.org  Sun May 18 07:15:27 2014
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 18 May 2014 08:15:27 +0100
Subject: HTTP 404 on Oracle Java code conventions
In-Reply-To: <5377725E.1020007@oracle.com>
References: <0D30AB9F36B3B24DA8D29EB394F7F2142A8619A5@APSWP0948.ms.ds.uhc.com>
	<5376C79C.50205@oracle.com> <5377725E.1020007@oracle.com>
Message-ID: <CACzrW9BT=BoocbgXxOhkU3itBS0kHZAjK0KGc454_WStaB38ew@mail.gmail.com>

On 17 May 2014 15:29, Phil Race <philip.race at oracle.com> wrote:
> The dead links need to be removed for sure and replaced with something else.
> However my understanding is that the positioning of the doc on the oracle
> website made it appear to be recommendations for the way all Java code
> should be written. Given that it doesn't cover newer features, and clearly
> Oracle isn't going to (or going to want to) enforce style guidelines for
> non-Oracle code it was deliberately removed.

Just noting that this statement is not true. Oracle is forcing style
guidelines on non-Oracle developers with the Javadoc doclint tool in
JDK 8. That tool is enforcing a very specific set of rules on Javadoc
that consist of a very particular style (one that is applicable for
the JDK itself, but not for others.) I would encourage Oracle project
management to review the doclint tool and its draconian default
settings which have broken numerous projects trying to upgrade to JDK
8.
http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html
https://github.com/search?q=doclint&type=Issues

> However for projects in which Oracle *is* involved (ie openjdk) there
> seems to be a case for reviving this document in some limited form.
> ie limited in the material it covers to generally accepted and customary
> openjdk coding guidelines, and limited to claiming to be an openjdk
> document, but not a document for the entire world.

I think most developers recognise that coding guidelines are just
guidelines. If you feel you need to move them, then thats OK, but they
are a vital part of the ecosystem around any programming language,
Since the old link will be used around the web, a redirect would be
desirable.

Stephen

6/14 7:21 PM, Donald Smith wrote:
>>
>> There's a bug at [1] for that, suggest commenting there (I'll kick it
>> again now).
>> [1] https://bugs.openjdk.java.net/browse/JDK-8039151
>>
>> I'm not sure what it should say instead, but the linked pages seem to have
>> been removed.  Oddly, I do remember this guide from 1999 (15 years ago!!) --
>> and I believe it stopped being updated because that was right around the
>> time that IDEs started just automatically doing this for you, so the
>> conversations moved there.
>>
>>  - Don
>>
>> On 16/05/2014 8:26 PM, Radov, Nicholas O wrote:
>>>
>>> I'm posting this on the discuss list in the hope that someone at Oracle
>>> will see it and take action. All of the links on the "Code Conventions for
>>> the Java Programming Language" web page are broken.
>>>
>>> http://www.oracle.com/technetwork/java/index-135089.html
>>>
>>> This e-mail, including attachments, may include confidential and/or
>>> proprietary information, and may be used only by the person or entity
>>> to which it is addressed. If the reader of this e-mail is not the
>>> intended
>>> recipient or his or her authorized agent, the reader is hereby notified
>>> that any dissemination, distribution or copying of this e-mail is
>>> prohibited. If you have received this e-mail in error, please notify the
>>> sender by replying to this message and delete this e-mail immediately.
>>
>>
>