From ivanov-jr at mail.ru  Fri Jan  2 06:07:23 2015
From: ivanov-jr at mail.ru (=?UTF-8?B?Um9tYW4gSXZhbm92?=)
Date: Fri, 02 Jan 2015 09:07:23 +0300
Subject: =?UTF-8?B?UmVbMl06IGNoZWNrc3R5bGUgdG9vbCB0byBlbmZvcmNlIFN1bi9PcmFjbGUg?=
	=?UTF-8?B?Y29kZSBzdGFuZGFyZCBvbiBvcGVuSmRr?=
In-Reply-To: <CAP7YuAT6NAn1HxeCCCL6wXSd9M8eXmWf8p0_NNdq78mtbAZBVA@mail.gmail.com>
References: <1419901645.865795059@f142.i.mail.ru>
	<CAP7YuAT6NAn1HxeCCCL6wXSd9M8eXmWf8p0_NNdq78mtbAZBVA@mail.gmail.com>
Message-ID: <1420178843.409036663@f158.i.mail.ru>


Hi Martijn and others,

It completely clear and very reasonable to have different style's (or slightly different) between projects.

It will be good to star with smth basic or with project that is interested. 

All I need from OpenJdk are :
- Provide me link to project code.
- Provide me link to style guide(s) for that prjoect.
- Clearly state that some team would benefit from that work and will use it during some build rutine, and would like to have Checkstyle configuration.

"Code Standard" is a document that written to be followed and not just to have it an show it as smb asked for it.
We need to be sure that we will do smth that will be used and useful.
Code standard should be enforced or do not exists at all. Checkstyle could help to enforce it.

thanks,
Roman Ivanov

Wed, 31 Dec 2014 11:36:22 +0000 ?? Martijn Verburg <martijnverburg at gmail.com>:
> 
> Hi Roman,
> 
> I for one would welcome this.? A bit of extra information from someone fairly new themselves (I've only ever submitted a few doc patches).? Each  OpenJDK project (project ~= a part of the source tree) has it's own unofficial style idioms or official style guide.? So you may find that for example  AWT /2D/Swing has a different set of guidelines than core-libs.
> 
> That said I think there's generally a feeling that having something check for style within a project would be welcome and perhaps then there could also be some cross project collaboration.? Of course this sort of thing can lead to somewhat frivolous "whitespace changes" type of patches coming in which I think each project will have an opinion on.
> 
> Perhaps the best thing to do is to start with one project (e.g. Core libs) and go from there....
> 
> CCing in the Adoption group as this sort of style check is something we'd happily host as part of the  Betterrev workflow .
> 
> 
> 
> 
> Cheers,
> Martijn
> On 30 December 2014 at 01:07, Roman Ivanov  < ivanov-jr at mail.ru > wrote:
> >Hi OpenJdk engineers,
> >
> >I am owner of Checkstyle project -?  http://checkstyle.sourceforge.net/index.html ? .
> >?
> >We had Sun code standard configuration that allow developers?
> >write code in the same approach as?authors?of Java do.?
> >But a lot of time passed from time that configuration is?
> >introduced, and I am not completely sure that we do complete?
> >and accurate in coverage? of Sun Java Standard.
> >?
> >This year we did complete code coverage for Google's style -?
> >http://checkstyle.sourceforge.net/google_style.html
> >?
> >Guava team already agreed on fixing problems?
> >and updating style guide to be more precise in some requirements -
> >https://github.com/google/guava/issues/1891
> >?
> >I have an idea to create similar page for Sun/Oracle style -
> >http://checkstyle.sourceforge.net/sun_style.html
> >?
> >Checkstyle already detected a lot of problem in javadoc on openjdk9 (base on change set: 11061:9ade71a206f9 ) -?
> >http://checkstyle.sourceforge.net/reports/javadoc/openjdk9/
> >That report contains only problems of Javadoc but? it could be as full as report over Guava -  http://checkstyle.sourceforge.net/reports/google-style/guava/ .
> >?
> >Are you interested in such automatic validation of Sun/Oracle Code Standard ?
> >To let openJDK comply their own code standard :), let automatically validate any contributions to project .
> >
> >thanks,
> >Roman Ivanov
> 


Roman Ivanov

From jonathan.gibbons at oracle.com  Fri Jan  2 17:41:27 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 02 Jan 2015 17:41:27 +0000
Subject: checkstyle tool to enforce Sun/Oracle code standard on openJdk
In-Reply-To: <1419901645.865795059@f142.i.mail.ru>
References: <1419901645.865795059@f142.i.mail.ru>
Message-ID: <54A6D847.6010904@oracle.com>

As attractive as the idea might be, it is not a slam dunk good idea to 
update the code base to a consistent style.

OpenJDK spans multiple versions, and patches get backported between 
versions. And there are always many projects "in-flight" at any time, at 
varying stages of development. Doing wholesale style-cleanup can cause 
undue difficulties when trying to port changesets or merge lines of 
development.

I'm not saying it shouldn't be done; but if it is done, it should be 
done carefully, in a considered manner, at an appropriate time.   Also, 
we should consider the relative importance of the fixes.  For example, 
fixing lint and doclint warnings that might indicate problematic code 
and comments is more important that fixing errors in whitespace indentation.

-- Jon

On 12/30/2014 01:07 AM, Roman Ivanov wrote:
> Hi OpenJdk engineers,
>
> I am owner of Checkstyle project -  http://checkstyle.sourceforge.net/index.html   .
>   
> We had Sun code standard configuration that allow developers
> write code in the same approach as authors of Java do.
> But a lot of time passed from time that configuration is
> introduced, and I am not completely sure that we do complete
> and accurate in coverage  of Sun Java Standard.
>   
> This year we did complete code coverage for Google's style -
> http://checkstyle.sourceforge.net/google_style.html
>   
> Guava team already agreed on fixing problems
> and updating style guide to be more precise in some requirements -
> https://github.com/google/guava/issues/1891
>   
> I have an idea to create similar page for Sun/Oracle style -
> http://checkstyle.sourceforge.net/sun_style.html
>   
> Checkstyle already detected a lot of problem in javadoc on openjdk9 (base on change set: 11061:9ade71a206f9 ) -
> http://checkstyle.sourceforge.net/reports/javadoc/openjdk9/
> That report contains only problems of Javadoc but  it could be as full as report over Guava - http://checkstyle.sourceforge.net/reports/google-style/guava/.
>   
> Are you interested in such automatic validation of Sun/Oracle Code Standard ?
> To let openJDK comply their own code standard :), let automatically validate any contributions to project .
>
> thanks,
> Roman Ivanov


From martijnverburg at gmail.com  Sat Jan  3 15:15:49 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 3 Jan 2015 15:15:49 +0000
Subject: checkstyle tool to enforce Sun/Oracle code standard on openJdk
In-Reply-To: <54A6D847.6010904@oracle.com>
References: <1419901645.865795059@f142.i.mail.ru> <54A6D847.6010904@oracle.com>
Message-ID: <CAP7YuAQfSMhCVP_df=oZjAPtbJecHCstJZpZyZQ2Lvfe7KGifw@mail.gmail.com>

Hi Jonathan,

Sounds very sensible, is there a project you can suggest that would be a
good one to start with (I'm thinking the smallest Java language based
one...)?

Cheers,
Martijn

On 2 January 2015 at 17:41, Jonathan Gibbons <jonathan.gibbons at oracle.com>
wrote:

> As attractive as the idea might be, it is not a slam dunk good idea to
> update the code base to a consistent style.
>
> OpenJDK spans multiple versions, and patches get backported between
> versions. And there are always many projects "in-flight" at any time, at
> varying stages of development. Doing wholesale style-cleanup can cause
> undue difficulties when trying to port changesets or merge lines of
> development.
>
> I'm not saying it shouldn't be done; but if it is done, it should be done
> carefully, in a considered manner, at an appropriate time.   Also, we
> should consider the relative importance of the fixes.  For example, fixing
> lint and doclint warnings that might indicate problematic code and comments
> is more important that fixing errors in whitespace indentation.
>
> -- Jon
>
>
> On 12/30/2014 01:07 AM, Roman Ivanov wrote:
>
>> Hi OpenJdk engineers,
>>
>> I am owner of Checkstyle project -  http://checkstyle.sourceforge.
>> net/index.html   .
>>   We had Sun code standard configuration that allow developers
>> write code in the same approach as authors of Java do.
>> But a lot of time passed from time that configuration is
>> introduced, and I am not completely sure that we do complete
>> and accurate in coverage  of Sun Java Standard.
>>   This year we did complete code coverage for Google's style -
>> http://checkstyle.sourceforge.net/google_style.html
>>   Guava team already agreed on fixing problems
>> and updating style guide to be more precise in some requirements -
>> https://github.com/google/guava/issues/1891
>>   I have an idea to create similar page for Sun/Oracle style -
>> http://checkstyle.sourceforge.net/sun_style.html
>>   Checkstyle already detected a lot of problem in javadoc on openjdk9
>> (base on change set: 11061:9ade71a206f9 ) -
>> http://checkstyle.sourceforge.net/reports/javadoc/openjdk9/
>> That report contains only problems of Javadoc but  it could be as full as
>> report over Guava - http://checkstyle.sourceforge.
>> net/reports/google-style/guava/.
>>   Are you interested in such automatic validation of Sun/Oracle Code
>> Standard ?
>> To let openJDK comply their own code standard :), let automatically
>> validate any contributions to project .
>>
>> thanks,
>> Roman Ivanov
>>
>
>

From ivanov-jr at mail.ru  Sun Jan  4 07:20:12 2015
From: ivanov-jr at mail.ru (=?UTF-8?B?Um9tYW4gSXZhbm92?=)
Date: Sun, 04 Jan 2015 10:20:12 +0300
Subject: =?UTF-8?B?Y2hlY2tzdHlsZSB0b29sIHRvIGVuZm9yY2UgU3VuL09yYWNsZSBjb2RlIHN0?=
	=?UTF-8?B?YW5kYXJkIG9uIG9wZW5KZGs=?=
Message-ID: <1420356012.769135497@f90.i.mail.ru>

Hi Jon,

first of all lets deside on last version of "Code Standard", as it might be appeared that changes will be cosmetic.

It might be reasonble to configure Checkstyle to enforce Code Standard on young/new projects or part of the project.
If project have a lot of backporting and it might be reasonable to enforce Code Standard only in latest code - version 9, and all previous version keep as is. 

It also might be reasonable to after config is created, start to use it partly, and slowly increase amount of rules as project have time to resolve style stuff.

The main point - old code/files stay unchanged, new files are created to follow all rules 100%, no backporting problems are guaranteed.

thanks,
Roman Ivanov

> As attractive as the idea might be, it is not a slam dunk good idea to 
> update the code base to a consistent style.
> 
> OpenJDK spans multiple versions, and patches get backported between 
> versions. And there are always many projects "in-flight" at any time, at 
> varying stages of development. Doing wholesale style-cleanup can cause 
> undue difficulties when trying to port changesets or merge lines of 
> development.
> 
> I'm not saying it shouldn't be done; but if it is done, it should be 
> done carefully, in a considered manner, at an appropriate time.   Also, 
> we should consider the relative importance of the fixes.  For example, 
> fixing lint and doclint warnings that might indicate problematic code 
> and comments is more important that fixing errors in whitespace indentation.
> 
> -- Jon
> 
> On 12/30/2014 01:07 AM, Roman Ivanov wrote:
>> Hi OpenJdk engineers,
>>
>> I am owner of Checkstyle project -  http://checkstyle.sourceforge.net/index.html   .
>>   
>> We had Sun code standard configuration that allow developers
>> write code in the same approach as authors of Java do.
>> But a lot of time passed from time that configuration is
>> introduced, and I am not completely sure that we do complete
>> and accurate in coverage  of Sun Java Standard.
>>   
>> This year we did complete code coverage for Google's style -
>> http://checkstyle.sourceforge.net/google_style.html
>>   
>> Guava team already agreed on fixing problems
>> and updating style guide to be more precise in some requirements -
>> https://github.com/google/guava/issues/1891
>>   
>> I have an idea to create similar page for Sun/Oracle style -
>> http://checkstyle.sourceforge.net/sun_style.html
>>   
>> Checkstyle already detected a lot of problem in javadoc on openjdk9 (base on change set: 11061:9ade71a206f9 ) -
>> http://checkstyle.sourceforge.net/reports/javadoc/openjdk9/
>> That report contains only problems of Javadoc but  it could be as full as report over Guava - http://checkstyle.sourceforge.net/reports/google-style/guava/.
>>   
>> Are you interested in such automatic validation of Sun/Oracle Code Standard ?
>> To let openJDK comply their own code standard :), let automatically validate any contributions to project .
>>
>> thanks,
>> Roman Ivanov

From scolebourne at joda.org  Sun Jan  4 11:20:58 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 4 Jan 2015 11:20:58 +0000
Subject: checkstyle tool to enforce Sun/Oracle code standard on openJdk
In-Reply-To: <1420356012.769135497@f90.i.mail.ru>
References: <1420356012.769135497@f90.i.mail.ru>
Message-ID: <CACzrW9CDo1C1uykeFoahHEoiMMSC_XgEX6-qtBoeGrNhZKeSog@mail.gmail.com>

While I don't have much time to follow up, the java.time packages
should be relatively easy to checkstyle as they had checkstyle applied
before entering OpenJDK.

Stephen



On 4 January 2015 at 07:20, Roman Ivanov <ivanov-jr at mail.ru> wrote:
> Hi Jon,
>
> first of all lets deside on last version of "Code Standard", as it might be appeared that changes will be cosmetic.
>
> It might be reasonble to configure Checkstyle to enforce Code Standard on young/new projects or part of the project.
> If project have a lot of backporting and it might be reasonable to enforce Code Standard only in latest code - version 9, and all previous version keep as is.
>
> It also might be reasonable to after config is created, start to use it partly, and slowly increase amount of rules as project have time to resolve style stuff.
>
> The main point - old code/files stay unchanged, new files are created to follow all rules 100%, no backporting problems are guaranteed.
>
> thanks,
> Roman Ivanov
>
>> As attractive as the idea might be, it is not a slam dunk good idea to
>> update the code base to a consistent style.
>>
>> OpenJDK spans multiple versions, and patches get backported between
>> versions. And there are always many projects "in-flight" at any time, at
>> varying stages of development. Doing wholesale style-cleanup can cause
>> undue difficulties when trying to port changesets or merge lines of
>> development.
>>
>> I'm not saying it shouldn't be done; but if it is done, it should be
>> done carefully, in a considered manner, at an appropriate time.   Also,
>> we should consider the relative importance of the fixes.  For example,
>> fixing lint and doclint warnings that might indicate problematic code
>> and comments is more important that fixing errors in whitespace indentation.
>>
>> -- Jon
>>
>> On 12/30/2014 01:07 AM, Roman Ivanov wrote:
>>> Hi OpenJdk engineers,
>>>
>>> I am owner of Checkstyle project -  http://checkstyle.sourceforge.net/index.html   .
>>>
>>> We had Sun code standard configuration that allow developers
>>> write code in the same approach as authors of Java do.
>>> But a lot of time passed from time that configuration is
>>> introduced, and I am not completely sure that we do complete
>>> and accurate in coverage  of Sun Java Standard.
>>>
>>> This year we did complete code coverage for Google's style -
>>> http://checkstyle.sourceforge.net/google_style.html
>>>
>>> Guava team already agreed on fixing problems
>>> and updating style guide to be more precise in some requirements -
>>> https://github.com/google/guava/issues/1891
>>>
>>> I have an idea to create similar page for Sun/Oracle style -
>>> http://checkstyle.sourceforge.net/sun_style.html
>>>
>>> Checkstyle already detected a lot of problem in javadoc on openjdk9 (base on change set: 11061:9ade71a206f9 ) -
>>> http://checkstyle.sourceforge.net/reports/javadoc/openjdk9/
>>> That report contains only problems of Javadoc but  it could be as full as report over Guava - http://checkstyle.sourceforge.net/reports/google-style/guava/.
>>>
>>> Are you interested in such automatic validation of Sun/Oracle Code Standard ?
>>> To let openJDK comply their own code standard :), let automatically validate any contributions to project .
>>>
>>> thanks,
>>> Roman Ivanov

From jonathan.gibbons at oracle.com  Mon Jan  5 16:06:14 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Jan 2015 08:06:14 -0800
Subject: checkstyle tool to enforce Sun/Oracle code standard on openJdk
In-Reply-To: <1420356012.769135497@f90.i.mail.ru>
References: <1420356012.769135497@f90.i.mail.ru>
Message-ID: <54AAB676.5070302@oracle.com>

In general, I agree that using Checkstyle on new compilation units 
(files) is a generally good idea.  Of course, that does imply that we 
know what the style should be, which would be a milestone in itself.

As for existing code, you have to tread carefully.  Even applying 
checkstyle to the changes to existing code may be problematic, since it 
is generally considered good manners to mimic the surrounding style when 
making localized edits.  So there is a judgement call of "the bigger the 
chunk of new code, the more acceptable it is to improve the format."

There are some obvious considerations to bear in mind as well:

-- How actively is the code being updated? The more people working in an 
area, the harder the synchronization problems
-- Does the code originate in OpenJDK or is the code a copy of code in 
an upstream project?
-- How prevalent are the violations, meaning, how big would the patches 
be to clean up the code? A patch for a few isolated lines is way more 
acceptable than a white-space cleanup that affects every line
-- How serious are the violations, meaning, how susceptible are the 
violations to merge errors? Edits adding imports in different positions 
can be merged (badly) to produce files with duplicate imports, so 
agreeing on an order of import statements is a good start.

Also, although this discussion has started with checkstyle, I would 
include IDEs. For those of us that use IDEs to work on OpenJDK, can we 
configure the IDE to match the recommended style? For example, for my 
part, I work in NetBeans, and if I'm working on a file with only a 
couple of warning symbols, I'll tend to clean them up where possible, if 
they don't distract too much from what I'm really working on. It's much 
easier to keep a file clear of warnings if the IDEs play along.

Finally, I'd suggest to break the work down into small segments. With 
the warnings cleanup, it was easier to split the work up into blocks 
focussing on different types of warnings in the various components of 
the system, rather than doing all warnings for everything at once.   So, 
in a similar way for style cleanup, I would suggest to start by working 
on specific cleanups, like import-ordering, or spaces around parens,

-- Jon

On 01/03/2015 11:20 PM, Roman Ivanov wrote:
> Hi Jon,
>
> first of all lets deside on last version of "Code Standard", as it might be appeared that changes will be cosmetic.
>
> It might be reasonble to configure Checkstyle to enforce Code Standard on young/new projects or part of the project.
> If project have a lot of backporting and it might be reasonable to enforce Code Standard only in latest code - version 9, and all previous version keep as is.
>
> It also might be reasonable to after config is created, start to use it partly, and slowly increase amount of rules as project have time to resolve style stuff.
>
> The main point - old code/files stay unchanged, new files are created to follow all rules 100%, no backporting problems are guaranteed.
>
> thanks,
> Roman Ivanov
>
>> As attractive as the idea might be, it is not a slam dunk good idea to
>> update the code base to a consistent style.
>>
>> OpenJDK spans multiple versions, and patches get backported between
>> versions. And there are always many projects "in-flight" at any time, at
>> varying stages of development. Doing wholesale style-cleanup can cause
>> undue difficulties when trying to port changesets or merge lines of
>> development.
>>
>> I'm not saying it shouldn't be done; but if it is done, it should be
>> done carefully, in a considered manner, at an appropriate time.   Also,
>> we should consider the relative importance of the fixes.  For example,
>> fixing lint and doclint warnings that might indicate problematic code
>> and comments is more important that fixing errors in whitespace indentation.
>>
>> -- Jon
>>
>> On 12/30/2014 01:07 AM, Roman Ivanov wrote:
>>> Hi OpenJdk engineers,
>>>
>>> I am owner of Checkstyle project -  http://checkstyle.sourceforge.net/index.html   .
>>>    
>>> We had Sun code standard configuration that allow developers
>>> write code in the same approach as authors of Java do.
>>> But a lot of time passed from time that configuration is
>>> introduced, and I am not completely sure that we do complete
>>> and accurate in coverage  of Sun Java Standard.
>>>    
>>> This year we did complete code coverage for Google's style -
>>> http://checkstyle.sourceforge.net/google_style.html
>>>    
>>> Guava team already agreed on fixing problems
>>> and updating style guide to be more precise in some requirements -
>>> https://github.com/google/guava/issues/1891
>>>    
>>> I have an idea to create similar page for Sun/Oracle style -
>>> http://checkstyle.sourceforge.net/sun_style.html
>>>    
>>> Checkstyle already detected a lot of problem in javadoc on openjdk9 (base on change set: 11061:9ade71a206f9 ) -
>>> http://checkstyle.sourceforge.net/reports/javadoc/openjdk9/
>>> That report contains only problems of Javadoc but  it could be as full as report over Guava - http://checkstyle.sourceforge.net/reports/google-style/guava/.
>>>    
>>> Are you interested in such automatic validation of Sun/Oracle Code Standard ?
>>> To let openJDK comply their own code standard :), let automatically validate any contributions to project .
>>>
>>> thanks,
>>> Roman Ivanov


From ivanov-jr at mail.ru  Mon Jan  5 19:33:27 2015
From: ivanov-jr at mail.ru (=?UTF-8?B?Um9tYW4gSXZhbm92?=)
Date: Mon, 05 Jan 2015 22:33:27 +0300
Subject: =?UTF-8?B?UmVbMl06IGNoZWNrc3R5bGUgdG9vbCB0byBlbmZvcmNlIFN1bi9PcmFjbGUg?=
	=?UTF-8?B?Y29kZSBzdGFuZGFyZCBvbiBvcGVuSmRr?=
In-Reply-To: <54AAB676.5070302@oracle.com>
References: <1420356012.769135497@f90.i.mail.ru> <54AAB676.5070302@oracle.com>
Message-ID: <1420486407.250044953@f28.i.mail.ru>

Hi Jonathan,

>  Of course, that does imply that we know what the style should be, which would be a milestone in itself.

I think we should start from what is Code Standard (style) for OpenJdk project, or at least part of it.
Main idea to keep in mind is that style is adjustable to project needs, some changes to style is expected after first implementation of checkstyle configuration for Code Standard, It is even possible that some validations will be switched OFF.
Lets start with something basic.

>  can we configure the IDE to match the recommended style?  

you could end up with style that is reconsiled with used IDEs, we have integration with most IDEs:
http://checkstyle.sourceforge.net/#Related_Tools
I use Eclipse with Checkstyle for very long time.
The only problem could be in Indentation - but we could switch that validation off if it cause conflicts with IDEs settings.
All other validations should not have any conflicts.

>  I would suggest to start by working on specific cleanups, like import-ordering, or spaces around parens,

I stil not not have link to Code Standard to any projects. That will help me verify that all your needs are coverable by Checkstyle.
Some changes to Checkstyle migh be requierd to satisfy your style.

thanks,
Roman Ivanov


Mon, 05 Jan 2015 08:06:14 -0800 ?? Jonathan Gibbons <jonathan.gibbons at oracle.com>:
> In general, I agree that using Checkstyle on new compilation units 
> (files) is a generally good idea.  Of course, that does imply that we 
> know what the style should be, which would be a milestone in itself.
> 
> As for existing code, you have to tread carefully.  Even applying 
> checkstyle to the changes to existing code may be problematic, since it 
> is generally considered good manners to mimic the surrounding style when 
> making localized edits.  So there is a judgement call of "the bigger the 
> chunk of new code, the more acceptable it is to improve the format."
> 
> There are some obvious considerations to bear in mind as well:
> 
> -- How actively is the code being updated? The more people working in an 
> area, the harder the synchronization problems
> -- Does the code originate in OpenJDK or is the code a copy of code in 
> an upstream project?
> -- How prevalent are the violations, meaning, how big would the patches 
> be to clean up the code? A patch for a few isolated lines is way more 
> acceptable than a white-space cleanup that affects every line
> -- How serious are the violations, meaning, how susceptible are the 
> violations to merge errors? Edits adding imports in different positions 
> can be merged (badly) to produce files with duplicate imports, so 
> agreeing on an order of import statements is a good start.
> 
> Also, although this discussion has started with checkstyle, I would 
> include IDEs. For those of us that use IDEs to work on OpenJDK, can we 
> configure the IDE to match the recommended style? For example, for my 
> part, I work in NetBeans, and if I'm working on a file with only a 
> couple of warning symbols, I'll tend to clean them up where possible, if 
> they don't distract too much from what I'm really working on. It's much 
> easier to keep a file clear of warnings if the IDEs play along.
> 
> Finally, I'd suggest to break the work down into small segments. With 
> the warnings cleanup, it was easier to split the work up into blocks 
> focussing on different types of warnings in the various components of 
> the system, rather than doing all warnings for everything at once.   So, 
> in a similar way for style cleanup, I would suggest to start by working 
> on specific cleanups, like import-ordering, or spaces around parens,
> 
> -- Jon
> 
> On 01/03/2015 11:20 PM, Roman Ivanov wrote:
> > Hi Jon,
> >
> > first of all lets deside on last version of "Code Standard", as it might be appeared that changes will be cosmetic.
> >
> > It might be reasonble to configure Checkstyle to enforce Code Standard on young/new projects or part of the project.
> > If project have a lot of backporting and it might be reasonable to enforce Code Standard only in latest code - version 9, and all previous version keep as is.
> >
> > It also might be reasonable to after config is created, start to use it partly, and slowly increase amount of rules as project have time to resolve style stuff.
> >
> > The main point - old code/files stay unchanged, new files are created to follow all rules 100%, no backporting problems are guaranteed.
> >
> > thanks,
> > Roman Ivanov
> >
> >> As attractive as the idea might be, it is not a slam dunk good idea to
> >> update the code base to a consistent style.
> >>
> >> OpenJDK spans multiple versions, and patches get backported between
> >> versions. And there are always many projects "in-flight" at any time, at
> >> varying stages of development. Doing wholesale style-cleanup can cause
> >> undue difficulties when trying to port changesets or merge lines of
> >> development.
> >>
> >> I'm not saying it shouldn't be done; but if it is done, it should be
> >> done carefully, in a considered manner, at an appropriate time.   Also,
> >> we should consider the relative importance of the fixes.  For example,
> >> fixing lint and doclint warnings that might indicate problematic code
> >> and comments is more important that fixing errors in whitespace indentation.
> >>
> >> -- Jon
> >>
> >> On 12/30/2014 01:07 AM, Roman Ivanov wrote:
> >>> Hi OpenJdk engineers,
> >>>
> >>> I am owner of Checkstyle project -  http://checkstyle.sourceforge.net/index.html   .
> >>>    
> >>> We had Sun code standard configuration that allow developers
> >>> write code in the same approach as authors of Java do.
> >>> But a lot of time passed from time that configuration is
> >>> introduced, and I am not completely sure that we do complete
> >>> and accurate in coverage  of Sun Java Standard.
> >>>    
> >>> This year we did complete code coverage for Google's style -
> >>> http://checkstyle.sourceforge.net/google_style.html
> >>>    
> >>> Guava team already agreed on fixing problems
> >>> and updating style guide to be more precise in some requirements -
> >>> https://github.com/google/guava/issues/1891
> >>>    
> >>> I have an idea to create similar page for Sun/Oracle style -
> >>> http://checkstyle.sourceforge.net/sun_style.html
> >>>    
> >>> Checkstyle already detected a lot of problem in javadoc on openjdk9 (base on change set: 11061:9ade71a206f9 ) -
> >>> http://checkstyle.sourceforge.net/reports/javadoc/openjdk9/
> >>> That report contains only problems of Javadoc but  it could be as full as report over Guava - http://checkstyle.sourceforge.net/reports/google-style/guava/.
> >>>    
> >>> Are you interested in such automatic validation of Sun/Oracle Code Standard ?
> >>> To let openJDK comply their own code standard :), let automatically validate any contributions to project .
> >>>
> >>> thanks,
> >>> Roman Ivanov
> 
> 


Roman Ivanov

From Riaz.Aimandi at oracle.com  Tue Jan  6 15:15:32 2015
From: Riaz.Aimandi at oracle.com (Riaz Aimandi)
Date: Tue, 6 Jan 2015 10:15:32 -0500
Subject: Project Proposal: Kona
Message-ID: <BA12703F-63D6-4D98-9297-CC2B7165B18C@oracle.com>

I?d like to discuss the creation of the Kona Project with myself (Riaz Aimandi) as the Lead and the Core Libraries group as the sponsoring group. 

This project would define and implement Java APIs for networking technologies and protocols that are commonly used in the Internet of Things (IoT) domain. The primary goal of the project would be to define APIs that can be efficiently implemented and used on embedded devices. These APIs would be defined in such a way that they could be potentially used with Java ME, although the project would initially focus on the implementation for Java SE. 

The first protocol that will be included in this project is Constrained Application Protocol (CoAP) and is expected to be contributed by ARM. It should have support for UDP connector with Datagram Transport Layer Security (DTLS) authentication handled outside of the CoAP APIs. Other connectors like TCP could be added later. Eventually, other technologies and protocols such as bluetooth might be considered as well. At this point, we intend to create this project outside of JCP.

I lead the IoT gateway runtime team at Oracle, where I?ve been in the Java group since 2007. Before that I was a technical lead in SavaJe Technologies, where I represented the company in standards committees like JCP (MIDP3) and OMTP (Application Security Framework). I have been working with Java in mobile and embedded environments for 14 years. 

The initial Reviewers and Committers suggested here are members of the Oracle's IoT team and ARM?s mbed team

The initial Reviewers will be Bob Vandette, Richard Bair, Darryl Mocek, David Grieve & Jen Dority. 

The initial Committers will be Sujay Sarkhel, Frederick Smith, Stephen Flores, Nikolay Yatsenko, Richard Ratta, Brandon Passanisi, Kinsley Wong, Sergey Soldatov, Victor Shubov, Szymon Sasin(ARM), Kalle Vayrynen (ARM), Norbert David (ARM) and Ville Oikarinen (ARM).

From daniel.smith at oracle.com  Fri Jan  9 00:14:54 2015
From: daniel.smith at oracle.com (Dan Smith)
Date: Thu, 8 Jan 2015 17:14:54 -0700
Subject: Access to JBS for non-Authors
Message-ID: <5909412C-6344-4298-A4EE-199A308AAF18@oracle.com>

I've had a query from an interested OpenJDK observer about getting a JBS account in order to watch bugs.  He has no intent to submit patches, so it would not be appropriate to try to make him an Author [1].  I've read [2], which says that Authorship is a sufficient condition for getting an account, but doesn't describe any alternative conditions.  Are there any?

?Dan

[1] http://openjdk.java.net/projects/#project-author
[2] https://wiki.openjdk.java.net/display/general/JBS+Overview

From martijnverburg at gmail.com  Fri Jan  9 08:16:48 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 9 Jan 2015 08:16:48 +0000
Subject: Access to JBS for non-Authors
In-Reply-To: <5909412C-6344-4298-A4EE-199A308AAF18@oracle.com>
References: <5909412C-6344-4298-A4EE-199A308AAF18@oracle.com>
Message-ID: <CAP7YuARjTVV8uoh1F+_7uWe_WZniR3B7PpWQ1Xxi0r3Jy2c1rA@mail.gmail.com>

Hi Dan/All,

I (and some other adoption group members) would also be interested in more
advanced access.  I think we can aid a great deal in triaging issues etc.

Cheers,
Martijn

On Friday, 9 January 2015, Dan Smith <daniel.smith at oracle.com> wrote:

> I've had a query from an interested OpenJDK observer about getting a JBS
> account in order to watch bugs.  He has no intent to submit patches, so it
> would not be appropriate to try to make him an Author [1].  I've read [2],
> which says that Authorship is a sufficient condition for getting an
> account, but doesn't describe any alternative conditions.  Are there any?
>
> ?Dan
>
> [1] http://openjdk.java.net/projects/#project-author
> [2] https://wiki.openjdk.java.net/display/general/JBS+Overview



-- 
Cheers,
Martijn

From dalibor.topic at oracle.com  Fri Jan  9 11:56:41 2015
From: dalibor.topic at oracle.com (dalibor.topic at oracle.com)
Date: Fri, 9 Jan 2015 12:56:41 +0100
Subject: Access to JBS for non-Authors
In-Reply-To: <5909412C-6344-4298-A4EE-199A308AAF18@oracle.com>
References: <5909412C-6344-4298-A4EE-199A308AAF18@oracle.com>
Message-ID: <B07209DC-FA19-423D-8737-67D9E3BCBC48@oracle.com>

There is no need for a JBS account to watch bugs. See http://robilad.livejournal.com/139637.html

--
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214<tel:+494089091214> | Mobile:+491737185961<tel:+491737185961>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

> On 09.01.2015, at 01:14, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> I've had a query from an interested OpenJDK observer about getting a JBS account in order to watch bugs.  He has no intent to submit patches, so it would not be appropriate to try to make him an Author [1].  I've read [2], which says that Authorship is a sufficient condition for getting an account, but doesn't describe any alternative conditions.  Are there any?
> 
> ?Dan
> 
> [1] http://openjdk.java.net/projects/#project-author
> [2] https://wiki.openjdk.java.net/display/general/JBS+Overview

From behrangsa at gmail.com  Wed Jan 14 00:43:54 2015
From: behrangsa at gmail.com (Behrang Saeedzadeh)
Date: Wed, 14 Jan 2015 11:43:54 +1100
Subject: Is this the right mailing list for discussing propsals, ideas, etc.
	for Java?
Message-ID: <CAERAJ+_dMpqRiNyUWhjfJWV_WQTbNdQQ-f3dA0PeZdpf4TLKbA@mail.gmail.com>

Or should I use the jdk9-dev mailing list instead?

Best regards,
Behrang
http://www.behrang.org

From david.holmes at oracle.com  Wed Jan 14 07:30:05 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 14 Jan 2015 17:30:05 +1000
Subject: Is this the right mailing list for discussing propsals, ideas,
	etc. for Java?
In-Reply-To: <CAERAJ+_dMpqRiNyUWhjfJWV_WQTbNdQQ-f3dA0PeZdpf4TLKbA@mail.gmail.com>
References: <CAERAJ+_dMpqRiNyUWhjfJWV_WQTbNdQQ-f3dA0PeZdpf4TLKbA@mail.gmail.com>
Message-ID: <54B61AFD.2010700@oracle.com>

On 14/01/2015 10:43 AM, Behrang Saeedzadeh wrote:
> Or should I use the jdk9-dev mailing list instead?

Neither :)

From:

http://mail.openjdk.java.net/mailman/listinfo

discuss 	General discussion about the OpenJDK Community
jdk9-dev 	Technical discussion related to the JDK 9 Project

Depending on what area the idea/proposal is in you could use a technical 
mailing list for that area e.g.:
  - hotspot-dev
  - core-libs-dev

If these are "Big Idea" type proposals the you may want to see if they 
fit within existing projects - such as Valhalla or Panama etc.

HTH

David

> Best regards,
> Behrang
> http://www.behrang.org
>

From john.bergin at gmail.com  Wed Jan 14 20:35:48 2015
From: john.bergin at gmail.com (John Bergin)
Date: Wed, 14 Jan 2015 20:35:48 +0000
Subject: Java class file verification
Message-ID: <54B6D324.3090908@gmail.com>

Hi all.

I have a query regarding Java class file verification in particular
verification of the LocalVariableTable attribute defined by the Java
Virtual Machine 7 specification here,

http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.13

The specification states that "The value of start_pc must be a valid
index into the code array of this Code attribute and must be the index
of the opcode of an instruction." And in the example below the
start_pc for args is 0 and for s it is 3 and both these indexes are
valid code array offsets.

  public static void main(java.lang.String[]);
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=1, locals=2, args_size=1
         0: ldc           #2                  // String A string
         2: astore_1
         3: return
      LineNumberTable:
        line 3: 0
        line 4: 3
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
               0       4     0  args   [Ljava/lang/String;
               3       1     1     s   Ljava/lang/String;

My question is: a program I'm helping to develop is dynamically
generating Java class files where the start_pc indexes are NOT valid
indexes into the code array (in fact they're off by one) and OpenJDK
is not rejecting the class via a ClassFormatException. Has anyone got
any idea why this is the case?

Kind regards,
John.

From alex.buckley at oracle.com  Wed Jan 14 21:02:03 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 14 Jan 2015 13:02:03 -0800
Subject: Java class file verification
In-Reply-To: <54B6D324.3090908@gmail.com>
References: <54B6D324.3090908@gmail.com>
Message-ID: <54B6D94B.7080708@oracle.com>

Hi John,

Per 
http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7, 
LocalVariableTable is not critical to correct interpretation of the 
class file by the JVM, so a JVM implementation like HotSpot is permitted 
to leave constraint checking up to the libraries. (This happens with the 
Runtime*Annotations attributes, for example.)

That said, I believe HotSpot in JDK 8 does go to the trouble of throwing 
ClassFormatError for oddball LocalVariableTable attributes:

     LocalVariableTable - Throws CFE if:
         start_pc >= code_length
         start_pc + length > code_length
         name_index or descriptor_index is invalid
         the name at name_index is not a legal field name
         the signature at descriptor_index is not a legal field signature
         index is a valid index in the local variable array

Probably best if you file a HotSpot bug on bugs.java.com so we can 
diagnose details there, not on a general discuss list.

Alex

On 1/14/2015 12:35 PM, John Bergin wrote:
> Hi all.
>
> I have a query regarding Java class file verification in particular
> verification of the LocalVariableTable attribute defined by the Java
> Virtual Machine 7 specification here,
>
> http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.13
>
> The specification states that "The value of start_pc must be a valid
> index into the code array of this Code attribute and must be the index
> of the opcode of an instruction." And in the example below the
> start_pc for args is 0 and for s it is 3 and both these indexes are
> valid code array offsets.
>
>    public static void main(java.lang.String[]);
>      flags: ACC_PUBLIC, ACC_STATIC
>      Code:
>        stack=1, locals=2, args_size=1
>           0: ldc           #2                  // String A string
>           2: astore_1
>           3: return
>        LineNumberTable:
>          line 3: 0
>          line 4: 3
>        LocalVariableTable:
>          Start  Length  Slot  Name   Signature
>                 0       4     0  args   [Ljava/lang/String;
>                 3       1     1     s   Ljava/lang/String;
>
> My question is: a program I'm helping to develop is dynamically
> generating Java class files where the start_pc indexes are NOT valid
> indexes into the code array (in fact they're off by one) and OpenJDK
> is not rejecting the class via a ClassFormatException. Has anyone got
> any idea why this is the case?
>
> Kind regards,
> John.
>

From chf at redhat.com  Wed Jan 14 21:03:18 2015
From: chf at redhat.com (Christine Flood)
Date: Wed, 14 Jan 2015 16:03:18 -0500 (EST)
Subject: Java class file verification
In-Reply-To: <54B6D324.3090908@gmail.com>
References: <54B6D324.3090908@gmail.com>
Message-ID: <2086782119.7979610.1421269398872.JavaMail.zimbra@redhat.com>

If you look at the documentation:  https://docs.oracle.com/javase/specs/jvms/se5.0/html/ClassFile.doc.html

"start_pc, length
    The given local variable must have a value at indices into the code array in the interval [start_pc, start_pc+length], that is, between start_pc and start_pc+length inclusive. The value of start_pc must be a valid index into the code array of this Code attribute and must be the index of the opcode of an instruction. Either the value of start_pc+length must be a valid index into the code array of this Code attribute and be the index of the opcode of an instruction, or it must be the first index beyond the end of that code array."


The first index beyond the end of the code array is acceptable.

Christine

----- Original Message -----
> From: "John Bergin" <john.bergin at gmail.com>
> To: discuss at openjdk.java.net
> Sent: Wednesday, January 14, 2015 3:35:48 PM
> Subject: Java class file verification
> 
> Hi all.
> 
> I have a query regarding Java class file verification in particular
> verification of the LocalVariableTable attribute defined by the Java
> Virtual Machine 7 specification here,
> 
> http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.13
> 
> The specification states that "The value of start_pc must be a valid
> index into the code array of this Code attribute and must be the index
> of the opcode of an instruction." And in the example below the
> start_pc for args is 0 and for s it is 3 and both these indexes are
> valid code array offsets.
> 
>   public static void main(java.lang.String[]);
>     flags: ACC_PUBLIC, ACC_STATIC
>     Code:
>       stack=1, locals=2, args_size=1
>          0: ldc           #2                  // String A string
>          2: astore_1
>          3: return
>       LineNumberTable:
>         line 3: 0
>         line 4: 3
>       LocalVariableTable:
>         Start  Length  Slot  Name   Signature
>                0       4     0  args   [Ljava/lang/String;
>                3       1     1     s   Ljava/lang/String;
> 
> My question is: a program I'm helping to develop is dynamically
> generating Java class files where the start_pc indexes are NOT valid
> indexes into the code array (in fact they're off by one) and OpenJDK
> is not rejecting the class via a ClassFormatException. Has anyone got
> any idea why this is the case?
> 
> Kind regards,
> John.
> 

From john.bergin at gmail.com  Wed Jan 14 23:00:47 2015
From: john.bergin at gmail.com (John Bergin)
Date: Wed, 14 Jan 2015 23:00:47 +0000
Subject: Java class file verification
Message-ID: <54B6F51F.2060705@gmail.com>

Hi again, Alex. Many thanks for your response. It makes a lot of sense
to me. I guess the implementation of the Java Virtual Machine
specification isn't entirely upheld with regard to attributes. In fact
your note on Runtime*Annotations makes a lot of sense too since I have
a class containing a RuntimeVisibleAnnotation whose
attribute_name_index references a CONSTANT_String_info instead of a
CONSTANT_Utf8_info and this class passes verification at load-time but
once the annotation is reflected an exception is thrown.

Anyway, I'll move this discussion to a bug. Thanks again.

Kind regards,
John.



Date: Wed, 14 Jan 2015 13:02:03 -0800
From: Alex Buckley <alex.buckley at oracle.com>
To: discuss at openjdk.java.net
Subject: Re: Java class file verification
Message-ID: <54B6D94B.7080708 at oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi John,

Per
http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7,
LocalVariableTable is not critical to correct interpretation of the
class file by the JVM, so a JVM implementation like HotSpot is permitted
to leave constraint checking up to the libraries. (This happens with the
Runtime*Annotations attributes, for example.)

That said, I believe HotSpot in JDK 8 does go to the trouble of throwing
ClassFormatError for oddball LocalVariableTable attributes:

     LocalVariableTable - Throws CFE if:
         start_pc >= code_length
         start_pc + length > code_length
         name_index or descriptor_index is invalid
         the name at name_index is not a legal field name
         the signature at descriptor_index is not a legal field signature
         index is a valid index in the local variable array

Probably best if you file a HotSpot bug on bugs.java.com so we can
diagnose details there, not on a general discuss list.

Alex

On 1/14/2015 12:35 PM, John Bergin wrote:
> Hi all.
> 
> I have a query regarding Java class file verification in
> particular verification of the LocalVariableTable attribute defined
> by the Java Virtual Machine 7 specification here,
> 
> 
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.13
> 
> The specification states that "The value of start_pc must be a
> valid index into the code array of this Code attribute and must be
> the index of the opcode of an instruction." And in the example
> below the start_pc for args is 0 and for s it is 3 and both these
> indexes are valid code array offsets.
> 
> public static void main(java.lang.String[]); flags: ACC_PUBLIC,
> ACC_STATIC Code: stack=1, locals=2, args_size=1 0: ldc           #2
> // String A string 2: astore_1 3: return LineNumberTable: line 3:
> 0 line 4: 3 LocalVariableTable: Start  Length  Slot  Name
> Signature 0       4     0  args   [Ljava/lang/String; 3       1
> 1     s   Ljava/lang/String;
> 
> My question is: a program I'm helping to develop is dynamically 
> generating Java class files where the start_pc indexes are NOT
> valid indexes into the code array (in fact they're off by one) and
> OpenJDK is not rejecting the class via a ClassFormatException. Has
> anyone got any idea why this is the case?
> 
> Kind regards, John.
> 

From john.bergin at gmail.com  Wed Jan 14 23:01:47 2015
From: john.bergin at gmail.com (John Bergin)
Date: Wed, 14 Jan 2015 23:01:47 +0000
Subject: Java class file verification
In-Reply-To: <2086782119.7979610.1421269398872.JavaMail.zimbra@redhat.com>
References: <54B6D324.3090908@gmail.com>
	<2086782119.7979610.1421269398872.JavaMail.zimbra@redhat.com>
Message-ID: <54B6F55B.8060603@gmail.com>

Hi Christine. Many thanks for your reply.

I had a read of the sentence you linked to for the Java 5/6 Virtual
Machine Specification and I parse that sentence in two parts:

Part-one:
"The given local variable must have a value at indices into the code
array in the interval [start_pc, start_pc + length), that is, between
start_pc inclusive and start_pc + length exclusive."

To me this means a variable must hold a value in the defined interval.

Part-two:
"The value of start_pc must be a valid index into the code array of
this Code attribute and must be the index of the opcode of an
instruction."

To me this means the start_pc value must be the index of an opcode --
the opcode's starting code-array offset only, and not an interval for
the size of the opcode.

But maybe I am interpreting the specification incorrectly.

Anyway, the offending byte-code that prompted me to intially send this
e-mail is:

50: invokevirtual #314
53: goto          69
56: astore_3
57: new           #316
60: dup
61: ldc_w         #318
64: aload_3
65: invokespecial #321
68: athrow

LocalVariableTable:
Start  Length  Slot  Name   Signature
  55      11     3     e   Ljava/lang/Exception;

Kind regards,
John.

On 14/01/15 21:03, Christine Flood wrote:
> If you look at the documentation:
> https://docs.oracle.com/javase/specs/jvms/se5.0/html/ClassFile.doc.html
>
>  "start_pc, length The given local variable must have a value at
> indices into the code array in the interval [start_pc,
> start_pc+length], that is, between start_pc and start_pc+length
> inclusive. The value of start_pc must be a valid index into the
> code array of this Code attribute and must be the index of the
> opcode of an instruction. Either the value of start_pc+length must
> be a valid index into the code array of this Code attribute and be
> the index of the opcode of an instruction, or it must be the first
> index beyond the end of that code array."
> 
> 
> The first index beyond the end of the code array is acceptable.
> 
> Christine
> 
> ----- Original Message -----
>> From: "John Bergin" <john.bergin at gmail.com> To:
>> discuss at openjdk.java.net Sent: Wednesday, January 14, 2015
>> 3:35:48 PM Subject: Java class file verification
>> 
>> Hi all.
>> 
>> I have a query regarding Java class file verification in
>> particular verification of the LocalVariableTable attribute
>> defined by the Java Virtual Machine 7 specification here,
>> 
>> http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.13
>>
>>
>> 
The specification states that "The value of start_pc must be a valid
>> index into the code array of this Code attribute and must be the
>> index of the opcode of an instruction." And in the example below
>> the start_pc for args is 0 and for s it is 3 and both these
>> indexes are valid code array offsets.
>> 
>> public static void main(java.lang.String[]); flags: ACC_PUBLIC,
>> ACC_STATIC Code: stack=1, locals=2, args_size=1 0: ldc
>> #2                  // String A string 2: astore_1 3: return 
>> LineNumberTable: line 3: 0 line 4: 3 LocalVariableTable: Start
>> Length  Slot  Name   Signature 0       4     0  args
>> [Ljava/lang/String; 3       1     1     s   Ljava/lang/String;
>> 
>> My question is: a program I'm helping to develop is dynamically 
>> generating Java class files where the start_pc indexes are NOT
>> valid indexes into the code array (in fact they're off by one)
>> and OpenJDK is not rejecting the class via a
>> ClassFormatException. Has anyone got any idea why this is the
>> case?
>> 
>> Kind regards, John.
>> 


From adinn at redhat.com  Thu Jan 15 12:29:37 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 15 Jan 2015 12:29:37 +0000
Subject: Java class file verification
In-Reply-To: <54B6F55B.8060603@gmail.com>
References: <54B6D324.3090908@gmail.com>	<2086782119.7979610.1421269398872.JavaMail.zimbra@redhat.com>
	<54B6F55B.8060603@gmail.com>
Message-ID: <54B7B2B1.8080407@redhat.com>

On 14/01/15 23:01, John Bergin wrote:
> To me this means the start_pc value must be the index of an opcode --
> the opcode's starting code-array offset only, and not an interval for
> the size of the opcode.
> 
> But maybe I am interpreting the specification incorrectly.

That's how I read it i.e. a start pc index into the middle of a
multibyte bytecode instruction sequence (i.e. which address a bytecode
operand rather than the bytecode operator itself) is not valid according
to the spec.

Your summary above omits the extra requirement that the end pc index is
likewise constrained modulo the one special case that it can be the
first index beyond the end of the array.

However, I'll note that my experience over the last 6 years with Byteman
is that quite a few classfile transformer programs (both offline and
online) fail to update these indexes when they rewrite bytecode,
frequently leaving indices addressing instructuon operands ... and,
clearly, these programs were not punished for it by the JVM class file
checking routines or else they would have had to correct the omission.
That's been my experience on JDK5/6/7. I have not seen examples when
running on 8 but I don't believe it is any different.

regards,


Andrew Dinn
-----------


From john.bergin at gmail.com  Thu Jan 15 13:12:19 2015
From: john.bergin at gmail.com (John Bergin)
Date: Thu, 15 Jan 2015 13:12:19 +0000
Subject: Java class file verification
In-Reply-To: <54B7B2B1.8080407@redhat.com>
References: <54B6D324.3090908@gmail.com>	<2086782119.7979610.1421269398872.JavaMail.zimbra@redhat.com>
	<54B6F55B.8060603@gmail.com> <54B7B2B1.8080407@redhat.com>
Message-ID: <54B7BCB3.3000100@gmail.com>

Hi Andrew. I'm glad to hear you also have a similar
interpretation of the spec. And it does make sense
like you said that the JVM should not punish Java
class files that have invalid start_pc values potentially
due to instrumentation which is commonly done.

Thanks again for you response.

Kind regards,
John.

On 15/01/15 12:29, Andrew Dinn wrote:
> On 14/01/15 23:01, John Bergin wrote:
>> To me this means the start_pc value must be the index of an opcode --
>> the opcode's starting code-array offset only, and not an interval for
>> the size of the opcode.
>>
>> But maybe I am interpreting the specification incorrectly.
> That's how I read it i.e. a start pc index into the middle of a
> multibyte bytecode instruction sequence (i.e. which address a bytecode
> operand rather than the bytecode operator itself) is not valid according
> to the spec.
>
> Your summary above omits the extra requirement that the end pc index is
> likewise constrained modulo the one special case that it can be the
> first index beyond the end of the array.
>
> However, I'll note that my experience over the last 6 years with Byteman
> is that quite a few classfile transformer programs (both offline and
> online) fail to update these indexes when they rewrite bytecode,
> frequently leaving indices addressing instructuon operands ... and,
> clearly, these programs were not punished for it by the JVM class file
> checking routines or else they would have had to correct the omission.
> That's been my experience on JDK5/6/7. I have not seen examples when
> running on 8 but I don't believe it is any different.
>
> regards,
>
>
> Andrew Dinn
> -----------
>


From jakewharton at gmail.com  Thu Jan 22 00:36:44 2015
From: jakewharton at gmail.com (Jake Wharton)
Date: Thu, 22 Jan 2015 00:36:44 +0000
Subject: Assignment In Switch
Message-ID: <CADUeE3TSKRPzg+X2qS_AWmqCyrGL1Ud8mN_S_uK5nuebtMh03g@mail.gmail.com>

Seeing the newly-added, assignment-free try-with-resources in JDK 9, I was
reminded of a common nuisance regarding the switch statement.

A common pattern is obtaining a value, performing the switch, and acting on
the value in some way. Here's a trivial example:

String protocol = getProtocol();
switch (protocol) {
  case "http": return 80;
  case "https": return 443;
  default: throw new IllegalStateException("Unknown protocol: " + protocol);
}

In this example we only use it in the default case, but you can imagine
other examples which make use of it in the individual cases.

Having parity in the option to use either a value or do an assignment in
creating a switch block would be useful.

switch (String protocol = getProtocol()) {
  case "http": return 80;
  case "https": return 443;
  default: throw new IllegalStateException("Unknown protocol: " + protocol);
}

The extreme simplicity of this example serves only to trivialize the value
of this change. It can be seen as a bit more useful when multiple switches
(linear or nested) are used.

switch (int flag = (value>> 0) & 0xFF) { .. }
switch (int flag = (value>> 8) & 0xFF) { .. }
switch (int flag = (value>>16) & 0xFF) { .. }
switch (int flag = (value>>24) & 0xFF) { .. }

A seemingly minor improvement, but there's a few wins here:
 * Parity with the behavior of the try-with-resources block.
 * Avoiding the local in the outer scope when it's only use is inside the
switch. As mentioned before, multiple switches that are either written
linearly or nested need to use explicit blocks or add arbitrary variance to
their variable names.

and playing Devil's advocate to myself:
 * Relatively low-leverage change. Kills 1LOC in a bunch of places, but no
new magically awesome behavior as try-with-resources brought.

I think this would be a useful (albeit tiny) addition to ease a specific
use case.

From alex.buckley at oracle.com  Thu Jan 22 00:48:23 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 21 Jan 2015 16:48:23 -0800
Subject: Assignment In Switch
In-Reply-To: <CADUeE3TSKRPzg+X2qS_AWmqCyrGL1Ud8mN_S_uK5nuebtMh03g@mail.gmail.com>
References: <CADUeE3TSKRPzg+X2qS_AWmqCyrGL1Ud8mN_S_uK5nuebtMh03g@mail.gmail.com>
Message-ID: <54C048D7.9040108@oracle.com>

This is a variant of local variable declarations in expressions: 
http://mail.openjdk.java.net/pipermail/compiler-dev/2015-January/009233.html

More broadly, see the proposal for "Block Expressions for Java" in 
Project Coin (Feb/Mar 2009): 
http://mail.openjdk.java.net/pipermail/coin-dev/

Of course there is no limit to the number of tiny language features that 
can be suggested, but this is not a language design list.

Alex

On 1/21/2015 4:36 PM, Jake Wharton wrote:
> Seeing the newly-added, assignment-free try-with-resources in JDK 9, I was
> reminded of a common nuisance regarding the switch statement.
>
> A common pattern is obtaining a value, performing the switch, and acting on
> the value in some way. Here's a trivial example:
>
> String protocol = getProtocol();
> switch (protocol) {
>    case "http": return 80;
>    case "https": return 443;
>    default: throw new IllegalStateException("Unknown protocol: " + protocol);
> }
>
> In this example we only use it in the default case, but you can imagine
> other examples which make use of it in the individual cases.
>
> Having parity in the option to use either a value or do an assignment in
> creating a switch block would be useful.
>
> switch (String protocol = getProtocol()) {
>    case "http": return 80;
>    case "https": return 443;
>    default: throw new IllegalStateException("Unknown protocol: " + protocol);
> }
>
> The extreme simplicity of this example serves only to trivialize the value
> of this change. It can be seen as a bit more useful when multiple switches
> (linear or nested) are used.
>
> switch (int flag = (value>> 0) & 0xFF) { .. }
> switch (int flag = (value>> 8) & 0xFF) { .. }
> switch (int flag = (value>>16) & 0xFF) { .. }
> switch (int flag = (value>>24) & 0xFF) { .. }
>
> A seemingly minor improvement, but there's a few wins here:
>   * Parity with the behavior of the try-with-resources block.
>   * Avoiding the local in the outer scope when it's only use is inside the
> switch. As mentioned before, multiple switches that are either written
> linearly or nested need to use explicit blocks or add arbitrary variance to
> their variable names.
>
> and playing Devil's advocate to myself:
>   * Relatively low-leverage change. Kills 1LOC in a bunch of places, but no
> new magically awesome behavior as try-with-resources brought.
>
> I think this would be a useful (albeit tiny) addition to ease a specific
> use case.
>

From volker.simonis at gmail.com  Fri Jan 30 09:36:18 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 30 Jan 2015 10:36:18 +0100
Subject: OpenJDK Governing Board Minutes: 2015/01/15
In-Reply-To: <be7ae9ba-0717-4fd1-9a11-d43b09110878@default>
References: <be7ae9ba-0717-4fd1-9a11-d43b09110878@default>
Message-ID: <CA+3eh120e1xOFXyUEWEZZO05e0PEfGfVbJfFotD3UAFhsy_27g@mail.gmail.com>

Hi,

can sombody please explain what's the meaning of "CCC" in the context
of section "6. Any other business" of the minutes?

Thanks,
Volker

On Fri, Jan 30, 2015 at 4:27 AM, Iris Clark <iris.clark at oracle.com> wrote:
> The minutes of the OpenJDK Governing Board's meeting on 15 January 2015 are now available: http://openjdk.java.net/groups/gb/minutes/2015-01-15 .
>
> Thanks,
> Iris

From dl at cs.oswego.edu  Fri Jan 30 14:21:56 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 30 Jan 2015 09:21:56 -0500
Subject: OpenJDK Governing Board Minutes: 2015/01/15
In-Reply-To: <CA+3eh120e1xOFXyUEWEZZO05e0PEfGfVbJfFotD3UAFhsy_27g@mail.gmail.com>
References: <be7ae9ba-0717-4fd1-9a11-d43b09110878@default>
	<CA+3eh120e1xOFXyUEWEZZO05e0PEfGfVbJfFotD3UAFhsy_27g@mail.gmail.com>
Message-ID: <54CB9384.9000401@cs.oswego.edu>

On 01/30/2015 04:36 AM, Volker Simonis wrote:
> Hi,
>
> can sombody please explain what's the meaning of "CCC" in the context
> of section "6.

CCC is a committee/process for approving any change in JDK classes
that has a risk of impacting compatibility; for example, adding
a method to a class. This is one of the few remaining Oracle-only
processes, that have not yet been integrated into OpenJDK.
No one objects to the notion of imposing an extra safeguard step
for potential compatibility issues, but there are no OpenJDK rules
specifying committee composition, rules for when approval is needed,
and so on. In the mean time, Oracle engineers catch possible
cases where it applies and somehow do something about it.

-Doug


>
> Thanks,
> Volker
>
> On Fri, Jan 30, 2015 at 4:27 AM, Iris Clark <iris.clark at oracle.com> wrote:
>> The minutes of the OpenJDK Governing Board's meeting on 15 January 2015 are now available: http://openjdk.java.net/groups/gb/minutes/2015-01-15 .
>>
>> Thanks,
>> Iris
>


From maurizio.cimadamore at oracle.com  Fri Jan 30 14:35:02 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 30 Jan 2015 14:35:02 +0000
Subject: JDK IntelliJ project: beta version
Message-ID: <54CB9696.4040604@oracle.com>

Hi guys,
over the last few weeks, Chris and I have been busy putting together a 
configurable IntelliJ project for working on JDK. We decided that is now 
time to share what we have, so that you guys could give it a try.
In order to use it, you must have a full JDK repository (i.e. forest) 
somewhere in your local environment. The script will also assume that 
you have already successfully ran the build 'configure' script. Simply 
go there and apply the attached patch. You will see that the patch will 
add some stuff under 'make/idea'.

Setting up a new project is simple; from the toplevel just run:

sh make/idea/idea.sh <MODULE-NAMES>

Where <MODULE-NAMES> denotes a space-separated list of module names 
(i.e. "java.base jdk.compiler"); if you don't provide any module name, 
the script will assume that you want to add all the modules as source 
roots (which is fine too).

The script assumes you have Ant installed on some default location (it 
infers such location correctly on both Mac and Linux) - should the Ant 
lookup logic fail, you can help it out by running the build 'configure' 
script with the following option:

--with-ant-home <ANT_HOME>

And the idea.sh script will be able to pick that up.

Once the script completes, you should see a new (hidden) folder .idea 
under the toplevel - that's your brand new project folder. This means 
that you can now open the toplevel folder as an IntelliJ project.
The script does a good job at asking the build system which sources 
should be added as root of your IntelliJ project; note that the answer 
might depend on your OS, your HW - all things that the build system 
knows very well. This means that the project you have just created will 
be customized for your specific build configuration (we plan to add 
options in the future to allow to create projects for custom 
configurations).

All main build commands can be accessed under the Build menu (it might 
be necessary to click on the menu a couple of times because of an 
IntelliJ glitch when loading the project Ant file for the first time). 
You should see a new entry in the build menu named 'jdk' - which has 
three options underneath:

* clean --> clean the build and rerun configure
* build-module --> build modules selected as input in the above script
* images --> do a full image build

To be able to index files correctly and also to run JDK tests, you will 
have to set your Project JDK - which can be done by clicking on the top 
right button (just beside the search button). Just set Project JDK to 
point to a valid JDK installation and you are good to go. You should now 
be able to select a 'Run' configuration on the top bar (by clicking on 
the down arrow in the combo list). There are two configurations available:

* run jtreg test
* debug jtreg test

To run a jtreg test, first make sure that the 'java.target.home' ant 
variable is set to some meaningful path (where a JDK image can be found) 
then simply open the jtreg test, make sure the source has focus in the 
IDE, then press the 'play' button besides the 'jtreg' configuration. 
Alternatively, you can run jtreg tests on an entire folder - to do so, 
just select the test folder you want to run tests on (to do so you might 
need to switch to the Project View, by clicking on the list in the top 
left - the default view is the Packages View). Make sure the folder is 
selected in the panel and then click on 'play' - all tests in that 
folder should be executed.

Debugging works more or less the same way; you select the test you want 
to debug, make sure that you selected the 'jtreg (debug)' configuration, 
and then click on the debug icon. This will currently only work with 
'samevm' tests (testng work also well) - so if the test says something 
other than samevm, you might need to modify the test to be able to 
debug. Currently, test are not being added as source roots, which means 
you could have issues when trying to set breakpoints in the test 
themselves - although you should be able to set a breakpoint anywhere in 
the source code of your selected modules.

I guess that's it - I hope you will find this useful (we certainly 
did!); please let us know what we can do to improve this. Our plan is to 
collect all feedback, then eventually push it in the JDK 9 repo.

I would like to thank bgoetz, jfrank, prappo, psandoz, rriggs and smarks 
for providing some (very useful) initial feedback on the project. Also a 
big thank to the IntelliJ team (esp. to Anna Kozlova) for helping us 
finding the Right Way (TM) to do things ;-)

Thanks
Maurizio




-------------- next part --------------
A non-text attachment was scrubbed...
Name: idea-v4.5.patch
Type: text/x-patch
Size: 39719 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/discuss/attachments/20150130/59fa1409/idea-v4.5-0001.patch>

From martijnverburg at gmail.com  Fri Jan 30 15:03:55 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 30 Jan 2015 15:03:55 +0000
Subject: OpenJDK Governing Board Minutes: 2015/01/15
In-Reply-To: <54CB9384.9000401@cs.oswego.edu>
References: <be7ae9ba-0717-4fd1-9a11-d43b09110878@default>
	<CA+3eh120e1xOFXyUEWEZZO05e0PEfGfVbJfFotD3UAFhsy_27g@mail.gmail.com>
	<54CB9384.9000401@cs.oswego.edu>
Message-ID: <CAP7YuASgARtbL-RR+4FLzsjfEjW+mU0Tu0nsAqirab6xeSmd7w@mail.gmail.com>

It was raised by a couple of other non Oracle contributors recently as
well - I'll bring it up at FOSDEM and see if we can work towards an OpenJDK
solution for this.

Cheers,
Martijn

On Friday, 30 January 2015, Doug Lea <dl at cs.oswego.edu> wrote:

> On 01/30/2015 04:36 AM, Volker Simonis wrote:
>
>> Hi,
>>
>> can sombody please explain what's the meaning of "CCC" in the context
>> of section "6.
>>
>
> CCC is a committee/process for approving any change in JDK classes
> that has a risk of impacting compatibility; for example, adding
> a method to a class. This is one of the few remaining Oracle-only
> processes, that have not yet been integrated into OpenJDK.
> No one objects to the notion of imposing an extra safeguard step
> for potential compatibility issues, but there are no OpenJDK rules
> specifying committee composition, rules for when approval is needed,
> and so on. In the mean time, Oracle engineers catch possible
> cases where it applies and somehow do something about it.
>
> -Doug
>
>
>
>> Thanks,
>> Volker
>>
>> On Fri, Jan 30, 2015 at 4:27 AM, Iris Clark <iris.clark at oracle.com>
>> wrote:
>>
>>> The minutes of the OpenJDK Governing Board's meeting on 15 January 2015
>>> are now available: http://openjdk.java.net/groups/gb/minutes/2015-01-15
>>> .
>>>
>>> Thanks,
>>> Iris
>>>
>>
>>
>

-- 
Cheers,
Martijn