[VOTE] Requiring final keyword on every parameter and local variable

2021-04-14 Thread Kirk Lund 
Our coding standard and our Design Decisions does NOT require using final
on parameters and local variables.

Please do NOT request that I add or keep final on parameters or local
variables unless the community votes and decides that every parameter and
local variable should require the final keyword. I coded this way in the
past and I found that it resulted in noisy code with no benefit. We can
argue about using this keyword all you want but the fact is I'm against it,
and I will not embrace it unless this community decides that we need to use
it.

Using final on instance or class fields does have a concurrency benefit and
I support that only.

If you want to add final to every single parameter and local var in the
Geode codebase, then now is your chance to vote on it. Please vote.

Thanks,
Kirk

Re: [VOTE] Requiring final keyword on every parameter and local variable

2021-04-14 Thread Bill Burcham 
+1

I am 100% for putting final everywhere it is possible to put it. Call this
the "hard final" position.

What I've been advocating for, intermittently, in PRs (for example, in PR
#6310 ) is
more of a "soft final" position which I can formulate as:

The final keyword is valuable everywhere. When we encounter it in code, we
assume that the author put it there intentionally to communicate that the
variable will not change. Since the code compiled before our change, we
know that the variable does not change (the compiler has proven it!) When
modifying code, we do not remove the final keyword unless we have to (to
get the code to compile).

So that's the "soft final" position. But I'm all for Kirk's "hard final" if
others agree. I just don't see any downside—only upside on this one.

The final keyword is a vehicle, like types, for programmers to communicate
their intentions. In both cases, the compiler can provide valuable
validation. There is, unfortunately, some visual noise entailed (lots of
occurrences of "final" in the code). But this makes non-final (mutable)
variables much more apparent. Since they are (or should be) in the
minority, this is an aid to maintainers. This becomes apparent in longer,
more complex methods.

On Wed, Apr 14, 2021 at 12:56 PM Kirk Lund  wrote:

> Our coding standard and our Design Decisions does NOT require using final
> on parameters and local variables.
>
> Please do NOT request that I add or keep final on parameters or local
> variables unless the community votes and decides that every parameter and
> local variable should require the final keyword. I coded this way in the
> past and I found that it resulted in noisy code with no benefit. We can
> argue about using this keyword all you want but the fact is I'm against it,
> and I will not embrace it unless this community decides that we need to use
> it.
>
> Using final on instance or class fields does have a concurrency benefit and
> I support that only.
>
> If you want to add final to every single parameter and local var in the
> Geode codebase, then now is your chance to vote on it. Please vote.
>
> Thanks,
> Kirk
>

Re: [VOTE] Requiring final keyword on every parameter and local variable

2021-04-14 Thread Mark Hanson 
+1 To Kirk’s approach.
-1 To final everywhere.

I support Kirk’s approach of adding final where there is benefit. If we want to 
go further, we can have intellij find all of them and change them if we want. 
Final is not always a developer’s explicit statement. Sometimes something 
becomes final after the fact.

If we manually touch any code, I would much rather we deal with the use of raw 
types than have final everywhere. This strikes me as a minor issue compared to 
the rampant use of raw types.

E.g.
RegionFactory regionFactory = 
getCache().createRegionFactory(RegionShortcut.PARTITION_REDUNDANT);
Region region = regionFactory.create (“testRegion”);
Region.put(int, String);`

Thanks,
Mark

From: Bill Burcham 
Date: Wednesday, April 14, 2021 at 1:53 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and local 
variable
+1

I am 100% for putting final everywhere it is possible to put it. Call this
the "hard final" position.

What I've been advocating for, intermittently, in PRs (for example, in PR
#6310 
)
 is
more of a "soft final" position which I can formulate as:

The final keyword is valuable everywhere. When we encounter it in code, we
assume that the author put it there intentionally to communicate that the
variable will not change. Since the code compiled before our change, we
know that the variable does not change (the compiler has proven it!) When
modifying code, we do not remove the final keyword unless we have to (to
get the code to compile).

So that's the "soft final" position. But I'm all for Kirk's "hard final" if
others agree. I just don't see any downside—only upside on this one.

The final keyword is a vehicle, like types, for programmers to communicate
their intentions. In both cases, the compiler can provide valuable
validation. There is, unfortunately, some visual noise entailed (lots of
occurrences of "final" in the code). But this makes non-final (mutable)
variables much more apparent. Since they are (or should be) in the
minority, this is an aid to maintainers. This becomes apparent in longer,
more complex methods.

On Wed, Apr 14, 2021 at 12:56 PM Kirk Lund  wrote:

> Our coding standard and our Design Decisions does NOT require using final
> on parameters and local variables.
>
> Please do NOT request that I add or keep final on parameters or local
> variables unless the community votes and decides that every parameter and
> local variable should require the final keyword. I coded this way in the
> past and I found that it resulted in noisy code with no benefit. We can
> argue about using this keyword all you want but the fact is I'm against it,
> and I will not embrace it unless this community decides that we need to use
> it.
>
> Using final on instance or class fields does have a concurrency benefit and
> I support that only.
>
> If you want to add final to every single parameter and local var in the
> Geode codebase, then now is your chance to vote on it. Please vote.
>
> Thanks,
> Kirk
>

[VOTE] Apache Geode 1.12.2.RC1

2021-04-14 Thread Owen Nichols 
Hello Geode Dev Community,

Geode’s support/1.12 has gathered a few more fixes since 1.12.1 was released 
two months ago.  I’d like to propose another patch release.

This is a release candidate for Apache Geode version 1.12.2.RC1.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback (including the checks you performed).

Voting deadline:
3PM PDT Mon, April 19 2021.

Please note that we are voting upon the source tag:
rel/v1.12.2.RC1

Release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.2

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.12.2.RC1/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachegeode-1080

GitHub:
https://github.com/apache/geode/tree/rel/v1.12.2.RC1
https://github.com/apache/geode-examples/tree/rel/v1.12.2.RC1
https://github.com/apache/geode-native/tree/rel/v1.12.2.RC1
https://github.com/apache/geode-benchmarks/tree/rel/v1.12.2.RC1

Pipelines:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-rc

Geode's KEYS file containing PGP keys we use to sign the release:
https://github.com/apache/geode/blob/develop/KEYS

Command to run geode-examples:
./gradlew 
-PgeodeReleaseUrl=https://dist.apache.org/repos/dist/dev/geode/1.12.2.RC1 
-PgeodeRepositoryUrl=https://repository.apache.org/content/repositories/orgapachegeode-1080
 build runAll

Regards
Owen Nichols

Stats deprecations?

2021-04-14 Thread Mark Hanson 
Hi,

So I am making some stats changes that are pretty minor, but I was looking at 
the fact that we have a ton of deprecated stuff about incInt and getInt. Can we 
convert those to longs? This would mean changing storage and return types.

Thanks,
Mark

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

2021-04-14 Thread Donal Evans 
+1

Confirmed that performance in multiple scenarios is on par with the previous 
1.12 release.

From: Owen Nichols 
Sent: Wednesday, April 14, 2021 3:38 PM
To: dev@geode.apache.org 
Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

Hello Geode Dev Community,

Geode’s support/1.12 has gathered a few more fixes since 1.12.1 was released 
two months ago.  I’d like to propose another patch release.

This is a release candidate for Apache Geode version 1.12.2.RC1.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback (including the checks you performed).

Voting deadline:
3PM PDT Mon, April 19 2021.

Please note that we are voting upon the source tag:
rel/v1.12.2.RC1

Release notes:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.2&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FrmRSQZPUtL3pciiAZ7LnGokKWITJgbl6N9KNdCBidQ%3D&reserved=0

Source and binary distributions:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.2.RC1%2F&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0dc%2FB9Hnf1wK4NpLXBUpy7v7H1xj9btZgsf1EjHW2IY%3D&reserved=0

Maven staging repo:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1080&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2T06JC%2BaRCVgViSmbwDqP6Z%2F6Y10zeIlOaTNpVwWkRA%3D&reserved=0

GitHub:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VyruqqFrBFtwop5L9dPW%2BUI69D2ijqZS7rf1ZnHIloM%3D&reserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=keT%2FsAuuqJ2jh1OAQgyAysVqNHqP%2BSJzlV%2F%2B6Yfjc9k%3D&reserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=r8HofpAFHtOKoKaeDmZFQx3x%2FLViCem3fwB5Hd1Zjvs%3D&reserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fHlniSX58ttlHa1PegR5fY5y2ISh0hU8uPUH%2FQHsldg%3D&reserved=0

Pipelines:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-main&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ck4trXdfeLSrRB%2BZBU3gytEmfDHN3E52Dw6tYjKxeu0%3D&reserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rc&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Fg7B1wfQN09lrTi%2FhvdtwdiPj8DCZjq5dD9YDjTU1FQ%3D&reserved=0

Geode's KEYS file containing PGP keys we use to sign the release:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2FKEYS&data=04%7C01%7Cdoevans

Re: Stats deprecations?

2021-04-14 Thread Jacob Barrett 
The deprecated int methods are there for API compatibility but are backed by 
the LongAdder that backs the long stats.

If you find any stats still using the int methods feel free to update them to 
use the long methods.

See https://issues.apache.org/jira/browse/GEODE-6424 and related tickets.

-Jake


On Apr 14, 2021, at 3:43 PM, Mark Hanson 
mailto:hans...@vmware.com>> wrote:

Hi,

So I am making some stats changes that are pretty minor, but I was looking at 
the fact that we have a ton of deprecated stuff about incInt and getInt. Can we 
convert those to longs? This would mean changing storage and return types.

Thanks,
Mark

Re: Stats deprecations?

2021-04-14 Thread Dan Smith 
Looks like those methods were deprecated in GEODE-6850. If I'm reading that 
correctly, there is no reason not to change the calls to incLong, getLong, etc. 
I'd say go for it.

-Dan

From: Mark Hanson 
Sent: Wednesday, April 14, 2021 3:43 PM
To: dev@geode.apache.org 
Subject: Stats deprecations?

Hi,

So I am making some stats changes that are pretty minor, but I was looking at 
the fact that we have a ton of deprecated stuff about incInt and getInt. Can we 
convert those to longs? This would mean changing storage and return types.

Thanks,
Mark

Re: Stats deprecations?

2021-04-14 Thread Mark Hanson 
The one gotcha which I am totally fine with is that the actual calls like 
get will return long rather than int. Is that going to break anything?


On 4/14/21, 4:10 PM, "Dan Smith"  wrote:

Looks like those methods were deprecated in GEODE-6850. If I'm reading that 
correctly, there is no reason not to change the calls to incLong, getLong, etc. 
I'd say go for it.

-Dan

From: Mark Hanson 
Sent: Wednesday, April 14, 2021 3:43 PM
To: dev@geode.apache.org 
Subject: Stats deprecations?

Hi,

So I am making some stats changes that are pretty minor, but I was looking 
at the fact that we have a ton of deprecated stuff about incInt and getInt. Can 
we convert those to longs? This would mean changing storage and return types.

Thanks,
Mark

Re: [VOTE] Requiring final keyword on every parameter and local variable

2021-04-14 Thread Jason Huynh 
Just to confirm for myself... final doesn't necessarily make object immutable.. 
the reference is immutable but if it refers to say a list, the list is still 
mutable.

So if I see a final keyword, I should only expect the reference not to change, 
but it won't guarantee that the object isn't changing.

I'm a -1 on forcing the issue because I believe we currently have too many 
"edge cases" where we can't stick a final on.  So we end up adding complexity 
in reading without the benefit guaranteeing anything...  I'd dislike seeing 
something like this make it partway and then get abandoned...

Also are we only discussing local variables, class variables and method 
parameters?  Ignoring final on methods and classes?


On 4/14/21, 2:18 PM, "Mark Hanson"  wrote:

+1 To Kirk’s approach.
-1 To final everywhere.

I support Kirk’s approach of adding final where there is benefit. If we 
want to go further, we can have intellij find all of them and change them if we 
want. Final is not always a developer’s explicit statement. Sometimes something 
becomes final after the fact.

If we manually touch any code, I would much rather we deal with the use of 
raw types than have final everywhere. This strikes me as a minor issue compared 
to the rampant use of raw types.

E.g.
RegionFactory regionFactory = 
getCache().createRegionFactory(RegionShortcut.PARTITION_REDUNDANT);
Region region = regionFactory.create (“testRegion”);
Region.put(int, String);`

Thanks,
Mark

From: Bill Burcham 
Date: Wednesday, April 14, 2021 at 1:53 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and local 
variable
+1

I am 100% for putting final everywhere it is possible to put it. Call this
the "hard final" position.

What I've been advocating for, intermittently, in PRs (for example, in PR
#6310 
)
 is
more of a "soft final" position which I can formulate as:

The final keyword is valuable everywhere. When we encounter it in code, we
assume that the author put it there intentionally to communicate that the
variable will not change. Since the code compiled before our change, we
know that the variable does not change (the compiler has proven it!) When
modifying code, we do not remove the final keyword unless we have to (to
get the code to compile).

So that's the "soft final" position. But I'm all for Kirk's "hard final" if
others agree. I just don't see any downside—only upside on this one.

The final keyword is a vehicle, like types, for programmers to communicate
their intentions. In both cases, the compiler can provide valuable
validation. There is, unfortunately, some visual noise entailed (lots of
occurrences of "final" in the code). But this makes non-final (mutable)
variables much more apparent. Since they are (or should be) in the
minority, this is an aid to maintainers. This becomes apparent in longer,
more complex methods.

On Wed, Apr 14, 2021 at 12:56 PM Kirk Lund  wrote:

> Our coding standard and our Design Decisions does NOT require using final
> on parameters and local variables.
>
> Please do NOT request that I add or keep final on parameters or local
> variables unless the community votes and decides that every parameter and
> local variable should require the final keyword. I coded this way in the
> past and I found that it resulted in noisy code with no benefit. We can
> argue about using this keyword all you want but the fact is I'm against 
it,
> and I will not embrace it unless this community decides that we need to 
use
> it.
>
> Using final on instance or class fields does have a concurrency benefit 
and
> I support that only.
>
> If you want to add final to every single parameter and local var in the
> Geode codebase, then now is your chance to vote on it. Please vote.
>
> Thanks,
> Kirk
>

Re: [VOTE] Requiring final keyword on every parameter and local variable

2021-04-14 Thread Robert Houghton 
Does this really "add noise" instead of "add clarity and precision" ?

-Robert

On 4/14/21, 4:25 PM, "Jason Huynh"  wrote:

Just to confirm for myself... final doesn't necessarily make object 
immutable.. the reference is immutable but if it refers to say a list, the list 
is still mutable.

So if I see a final keyword, I should only expect the reference not to 
change, but it won't guarantee that the object isn't changing.

I'm a -1 on forcing the issue because I believe we currently have too many 
"edge cases" where we can't stick a final on.  So we end up adding complexity 
in reading without the benefit guaranteeing anything...  I'd dislike seeing 
something like this make it partway and then get abandoned...

Also are we only discussing local variables, class variables and method 
parameters?  Ignoring final on methods and classes?


On 4/14/21, 2:18 PM, "Mark Hanson"  wrote:

+1 To Kirk’s approach.
-1 To final everywhere.

I support Kirk’s approach of adding final where there is benefit. If we 
want to go further, we can have intellij find all of them and change them if we 
want. Final is not always a developer’s explicit statement. Sometimes something 
becomes final after the fact.

If we manually touch any code, I would much rather we deal with the use 
of raw types than have final everywhere. This strikes me as a minor issue 
compared to the rampant use of raw types.

E.g.
RegionFactory regionFactory = 
getCache().createRegionFactory(RegionShortcut.PARTITION_REDUNDANT);
Region region = regionFactory.create (“testRegion”);
Region.put(int, String);`

Thanks,
Mark

From: Bill Burcham 
Date: Wednesday, April 14, 2021 at 1:53 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and 
local variable
+1

I am 100% for putting final everywhere it is possible to put it. Call 
this
the "hard final" position.

What I've been advocating for, intermittently, in PRs (for example, in 
PR
#6310 
)
 is
more of a "soft final" position which I can formulate as:

The final keyword is valuable everywhere. When we encounter it in code, 
we
assume that the author put it there intentionally to communicate that 
the
variable will not change. Since the code compiled before our change, we
know that the variable does not change (the compiler has proven it!) 
When
modifying code, we do not remove the final keyword unless we have to (to
get the code to compile).

So that's the "soft final" position. But I'm all for Kirk's "hard 
final" if
others agree. I just don't see any downside—only upside on this one.

The final keyword is a vehicle, like types, for programmers to 
communicate
their intentions. In both cases, the compiler can provide valuable
validation. There is, unfortunately, some visual noise entailed (lots of
occurrences of "final" in the code). But this makes non-final (mutable)
variables much more apparent. Since they are (or should be) in the
minority, this is an aid to maintainers. This becomes apparent in 
longer,
more complex methods.

On Wed, Apr 14, 2021 at 12:56 PM Kirk Lund  wrote:

> Our coding standard and our Design Decisions does NOT require using 
final
> on parameters and local variables.
>
> Please do NOT request that I add or keep final on parameters or local
> variables unless the community votes and decides that every parameter 
and
> local variable should require the final keyword. I coded this way in 
the
> past and I found that it resulted in noisy code with no benefit. We 
can
> argue about using this keyword all you want but the fact is I'm 
against it,
> and I will not embrace it unless this community decides that we need 
to use
> it.
>
> Using final on instance or class fields does have a concurrency 
benefit and
> I support that only.
>
> If you want to add final to every single parameter and local var in 
the
> Geode codebase, then now is your chance to vote on it. Please vote.
>
> Thanks,
> Kirk
>

Re: [VOTE] Requiring final keyword on every parameter and local variable

2021-04-14 Thread Jacob Barrett 
If a method is longer than a handful of lines and I go in to refactor it I am 
going to start by making every variable I find final. Then I am going to figure 
out how to keep them final. By doing so you naturally produce smaller 
functional methods that are usually independently unit testable. Smaller 
methods can get jitted. Smaller methods can take less time to reach a safe 
point (see time to safe point issues in Java). 

For this reason I strongly prefer on final everywhere and if you think you need 
a variable to not be final you should use that as an indicator to refractor 
your code. 

So, +1 for me for final everywhere. 

Also, please stop declaring variables miles away from their use.

> On Apr 14, 2021, at 12:55 PM, Kirk Lund  wrote:
> 
> Our coding standard and our Design Decisions does NOT require using final
> on parameters and local variables.
> 
> Please do NOT request that I add or keep final on parameters or local
> variables unless the community votes and decides that every parameter and
> local variable should require the final keyword. I coded this way in the
> past and I found that it resulted in noisy code with no benefit. We can
> argue about using this keyword all you want but the fact is I'm against it,
> and I will not embrace it unless this community decides that we need to use
> it.
> 
> Using final on instance or class fields does have a concurrency benefit and
> I support that only.
> 
> If you want to add final to every single parameter and local var in the
> Geode codebase, then now is your chance to vote on it. Please vote.
> 
> Thanks,
> Kirk

Re: [VOTE] Requiring final keyword on every parameter and local variable

2021-04-14 Thread Jason Huynh 
Yeah, understood just an opinion about noise __  The clarity and precision part 
I'm debating a bit but  I also don't do code review or work in the actual code 
base as much as before so I'll go with a -0 vote for me and let everyone else 
that does see the code more often decide __

On 4/14/21, 4:28 PM, "Robert Houghton"  wrote:

Does this really "add noise" instead of "add clarity and precision" ?

-Robert

On 4/14/21, 4:25 PM, "Jason Huynh"  wrote:

Just to confirm for myself... final doesn't necessarily make object 
immutable.. the reference is immutable but if it refers to say a list, the list 
is still mutable.

So if I see a final keyword, I should only expect the reference not to 
change, but it won't guarantee that the object isn't changing.

I'm a -1 on forcing the issue because I believe we currently have too 
many "edge cases" where we can't stick a final on.  So we end up adding 
complexity in reading without the benefit guaranteeing anything...  I'd dislike 
seeing something like this make it partway and then get abandoned...

Also are we only discussing local variables, class variables and method 
parameters?  Ignoring final on methods and classes?


On 4/14/21, 2:18 PM, "Mark Hanson"  wrote:

+1 To Kirk’s approach.
-1 To final everywhere.

I support Kirk’s approach of adding final where there is benefit. 
If we want to go further, we can have intellij find all of them and change them 
if we want. Final is not always a developer’s explicit statement. Sometimes 
something becomes final after the fact.

If we manually touch any code, I would much rather we deal with the 
use of raw types than have final everywhere. This strikes me as a minor issue 
compared to the rampant use of raw types.

E.g.
RegionFactory regionFactory = 
getCache().createRegionFactory(RegionShortcut.PARTITION_REDUNDANT);
Region region = regionFactory.create (“testRegion”);
Region.put(int, String);`

Thanks,
Mark

From: Bill Burcham 
Date: Wednesday, April 14, 2021 at 1:53 PM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and 
local variable
+1

I am 100% for putting final everywhere it is possible to put it. 
Call this
the "hard final" position.

What I've been advocating for, intermittently, in PRs (for example, 
in PR
#6310 
)
 is
more of a "soft final" position which I can formulate as:

The final keyword is valuable everywhere. When we encounter it in 
code, we
assume that the author put it there intentionally to communicate 
that the
variable will not change. Since the code compiled before our 
change, we
know that the variable does not change (the compiler has proven 
it!) When
modifying code, we do not remove the final keyword unless we have 
to (to
get the code to compile).

So that's the "soft final" position. But I'm all for Kirk's "hard 
final" if
others agree. I just don't see any downside—only upside on this one.

The final keyword is a vehicle, like types, for programmers to 
communicate
their intentions. In both cases, the compiler can provide valuable
validation. There is, unfortunately, some visual noise entailed 
(lots of
occurrences of "final" in the code). But this makes non-final 
(mutable)
variables much more apparent. Since they are (or should be) in the
minority, this is an aid to maintainers. This becomes apparent in 
longer,
more complex methods.

On Wed, Apr 14, 2021 at 12:56 PM Kirk Lund  wrote:

> Our coding standard and our Design Decisions does NOT require 
using final
> on parameters and local variables.
>
> Please do NOT request that I add or keep final on parameters or 
local
> variables unless the community votes and decides that every 
parameter and
> local variable should require the final keyword. I coded this way 
in the
> past and I found that it resulted in noisy code with no benefit. 
We can
> argue about using this keyword all you want but the fact is I'm 
against it,
> and I will not embrace it unless this community decides that we

Re: Stats deprecations?

2021-04-14 Thread Darrel Schneider 
It might break something but it should not be too bad. Internal product 
features are not supposed to read stat values and make decisions based on them 
because geode allows stat storage to be disabled. Also all these callers of the 
deprecated methods will be internal. So most of the code that calls a gettor 
for a stat value is probably a test. Since we now store that stat as a 64-bit 
value (instead of 32-bit) it would probably be best if we didn't truncate when 
we read it which is what is happening now when getInt is called. It would be 
good to do this in its own PR since it will touch a lot of code.

From: Mark Hanson 
Sent: Wednesday, April 14, 2021 4:13 PM
To: dev@geode.apache.org 
Subject: Re: Stats deprecations?

The one gotcha which I am totally fine with is that the actual calls like 
get will return long rather than int. Is that going to break anything?


On 4/14/21, 4:10 PM, "Dan Smith"  wrote:

Looks like those methods were deprecated in GEODE-6850. If I'm reading that 
correctly, there is no reason not to change the calls to incLong, getLong, etc. 
I'd say go for it.

-Dan

From: Mark Hanson 
Sent: Wednesday, April 14, 2021 3:43 PM
To: dev@geode.apache.org 
Subject: Stats deprecations?

Hi,

So I am making some stats changes that are pretty minor, but I was looking 
at the fact that we have a ton of deprecated stuff about incInt and getInt. Can 
we convert those to longs? This would mean changing storage and return types.

Thanks,
Mark

Re: [VOTE] Requiring final keyword on every parameter and local variable

2021-04-14 Thread Patrick Johnson 
-1 for requiring final for all method parameters. While I have nothing against 
using final here, I don’t think it’s worth mandating and would be better left 
up to the individual and the specific circumstance.

On Apr 14, 2021, at 4:33 PM, Jason Huynh 
mailto:jhu...@vmware.com>> wrote:

Yeah, understood just an opinion about noise __  The clarity and precision part 
I'm debating a bit but  I also don't do code review or work in the actual code 
base as much as before so I'll go with a -0 vote for me and let everyone else 
that does see the code more often decide __

On 4/14/21, 4:28 PM, "Robert Houghton" 
mailto:rhough...@vmware.com>> wrote:

   Does this really "add noise" instead of "add clarity and precision" ?

   -Robert

   On 4/14/21, 4:25 PM, "Jason Huynh" 
mailto:jhu...@vmware.com>> wrote:

   Just to confirm for myself... final doesn't necessarily make object 
immutable.. the reference is immutable but if it refers to say a list, the list 
is still mutable.

   So if I see a final keyword, I should only expect the reference not to 
change, but it won't guarantee that the object isn't changing.

   I'm a -1 on forcing the issue because I believe we currently have too 
many "edge cases" where we can't stick a final on.  So we end up adding 
complexity in reading without the benefit guaranteeing anything...  I'd dislike 
seeing something like this make it partway and then get abandoned...

   Also are we only discussing local variables, class variables and method 
parameters?  Ignoring final on methods and classes?


   On 4/14/21, 2:18 PM, "Mark Hanson" 
mailto:hans...@vmware.com>> wrote:

   +1 To Kirk’s approach.
   -1 To final everywhere.

   I support Kirk’s approach of adding final where there is benefit. If 
we want to go further, we can have intellij find all of them and change them if 
we want. Final is not always a developer’s explicit statement. Sometimes 
something becomes final after the fact.

   If we manually touch any code, I would much rather we deal with the 
use of raw types than have final everywhere. This strikes me as a minor issue 
compared to the rampant use of raw types.

   E.g.
   RegionFactory regionFactory = 
getCache().createRegionFactory(RegionShortcut.PARTITION_REDUNDANT);
   Region region = regionFactory.create (“testRegion”);
   Region.put(int, String);`

   Thanks,
   Mark

   From: Bill Burcham 
mailto:bill.burc...@gmail.com>>
   Date: Wednesday, April 14, 2021 at 1:53 PM
   To: dev@geode.apache.org 
mailto:dev@geode.apache.org>>
   Subject: Re: [VOTE] Requiring final keyword on every parameter and 
local variable
   +1

   I am 100% for putting final everywhere it is possible to put it. 
Call this
   the "hard final" position.

   What I've been advocating for, intermittently, in PRs (for example, 
in PR
   #6310 
)
 is
   more of a "soft final" position which I can formulate as:

   The final keyword is valuable everywhere. When we encounter it in 
code, we
   assume that the author put it there intentionally to communicate 
that the
   variable will not change. Since the code compiled before our change, 
we
   know that the variable does not change (the compiler has proven it!) 
When
   modifying code, we do not remove the final keyword unless we have to 
(to
   get the code to compile).

   So that's the "soft final" position. But I'm all for Kirk's "hard 
final" if
   others agree. I just don't see any downside—only upside on this one.

   The final keyword is a vehicle, like types, for programmers to 
communicate
   their intentions. In both cases, the compiler can provide valuable
   validation. There is, unfortunately, some visual noise entailed 
(lots of
   occurrences of "final" in the code). But this makes non-final 
(mutable)
   variables much more apparent. Since they are (or should be) in the
   minority, this is an aid to maintainers. This becomes apparent in 
longer,
   more complex methods.

   On Wed, Apr 14, 2021 at 12:56 PM Kirk Lund 
mailto:kl...@apache.org>> wrote:

Our coding standard and our Design Decisions does NOT require using final
on parameters and local variables.

Please do NOT request that I add or keep final on parameters or local
variables unless the community votes and d

Re: [VOTE] Requiring final keyword on every parameter and local variable

2021-04-14 Thread Udo Kohlmeyer 
"+1" to ENCOURAGING developers to make "final" a requirement for method 
arguments.
"-1" to making it a hard rule.

If we want to enforce this rule on the basis of readability or performance, I 
fear that we might be beating the wrong horse here for the wrong reasons!! 

Short reasoning:

If we really want to effect real lasting change, is to adopt principles that 
Rust (object owners) and Kotlin (immutable collections) make core to the 
language. Immutable POJOs and possibly an extension for collections to make 
intent of immutability clear would be far more effective. As code reviewers 
would be able to look at a method definition and instantly know what arguments 
are mutable.

Adding "final" on fields, methods and classes has a far greater effect than 
that of method arguments. If we intent to enforce it based on readability, then 
we should really consider applying different approaches (as stated in the 
paragraph above) that can be used with far greater effectiveness.

Longer reasoning:

I think all arguments relating to "indicating authors intent" or "variable  
does not change" are great, but in reality we as developers should always 
assume that this was the intent. I think if we really want to improve our code 
base, let's opt for IMMUTABLE data objects. The "final" keyword has no benefit 
if you pass around POJOs (including Collections). As long as you don't change 
the instance reference, the "final" keyword has absolutely no effect. It does 
not mean that you cannot change every field internal of the POJO. The "final" 
keyword is only effective against the re-assignment of that variable/argument 
within a method. But a better practice is to avoid the re-assignment of any 
variable/argument in the first place.

Kotlin has a great language (one of many) that method/function arguments are 
naturally final and this behavior cannot be changed. In addition there is a the 
feature that the collections are immutable and as a developer you have to be 
explicit if you want a collection to be mutable, by defining the collection as 
a "Mutable*" i.e MutableMap, MutableSet, MutableList 

@Jake the idea of smaller methods is great and we should ALWAYS strive for 
that. But that argument is completely irrelevant in this discussion. As making 
method arguments final does not naturally guide a developer to creating smaller 
methods. Nor does a smaller method mean it can/will be jitted. Too many factors 
(to discuss here) are part of that decision, also it is not relevant in this 
discussion. But more on that topic read THIS.

--Udo

On 4/15/21, 9:29 AM, "Jacob Barrett"  wrote:

If a method is longer than a handful of lines and I go in to refactor it I 
am going to start by making every variable I find final. Then I am going to 
figure out how to keep them final. By doing so you naturally produce smaller 
functional methods that are usually independently unit testable. Smaller 
methods can get jitted. Smaller methods can take less time to reach a safe 
point (see time to safe point issues in Java). 

For this reason I strongly prefer on final everywhere and if you think you 
need a variable to not be final you should use that as an indicator to 
refractor your code. 

So, +1 for me for final everywhere. 

Also, please stop declaring variables miles away from their use.

> On Apr 14, 2021, at 12:55 PM, Kirk Lund  wrote:
> 
> Our coding standard and our Design Decisions does NOT require using final
> on parameters and local variables.
> 
> Please do NOT request that I add or keep final on parameters or local
> variables unless the community votes and decides that every parameter and
> local variable should require the final keyword. I coded this way in the
> past and I found that it resulted in noisy code with no benefit. We can
> argue about using this keyword all you want but the fact is I'm against 
it,
> and I will not embrace it unless this community decides that we need to 
use
> it.
> 
> Using final on instance or class fields does have a concurrency benefit 
and
> I support that only.
> 
> If you want to add final to every single parameter and local var in the
> Geode codebase, then now is your chance to vote on it. Please vote.
> 
> Thanks,
> Kirk

Re: [VOTE] Requiring final keyword on every parameter and local variable

2021-04-14 Thread Jacob Barrett 


> On Apr 14, 2021, at 7:46 PM, Udo Kohlmeyer  wrote:
> @Jake the idea of smaller methods is great and we should ALWAYS strive for 
> that. But that argument is completely irrelevant in this discussion. As 
> making method arguments final does not naturally guide a developer to 
> creating smaller methods. Nor does a smaller method mean it can/will be 
> jitted. Too many factors (to discuss here) are part of that decision, also it 
> is not relevant in this discussion. But more on that topic read THIS.

The original subject is in regards to parameters and local variables.

Irrelevant is certainly an opinion you are welcome to have but let me challenge 
you. Goto DistributedCacheOperation._distribute(). 

First challenge, look at around line 333: 
boolean reliableOp = isOperationReliable() && region.requiresReliabilityCheck();

Without scrolling do you see that variable used? Nope, because it is first used 
on line 439, ~100 lines away. Does it mutate between there, well I can search 
for all uses and find out or I could be nice to the next person and intend for 
it to never mutate by adding final. Intent communicated!

Second challenge, mark all the local variables in the method as final. Now make 
it compile without introducing more mutable variables. At the end of this 
journey you will have about a dozen unit testable methods and a _distribute 
method that goes from ~370 lines to  ~90 with no mutable local variables. 

I argue it is relevant as good guardrail for writing good code. While we should 
ALWAYS strive for it we don’t. Every little nudge helps.


-Jake