Re: Request for contributor permissions

[Jacob Barrett]

Maria,

There are no special permissions to contribute. Please read 
https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute 
 for 
details about contributing. Contributions can be made via GitHub’s pull request 
feature.

Thanks,
Jake


> On Jun 18, 2019, at 5:06 PM, Maria Shtutman  wrote:
> 
> Hello Geode Apache Commons team,
> I would like to start to contribute to Geode project, hence I request
> contributor permissions.
> 
> Thanks,
> Maria Shtutman

Request for contributor permissions

[Maria Shtutman]

Hello Geode Apache Commons team,
I would like to start to contribute to Geode project, hence I request
contributor permissions.

Thanks,
Maria Shtutman

Re: Unnecessary uses of final on local variables

[Kirk Lund]

Thanks for the very thoughtful and well-worded reply, Bill. I would
certainly welcome further discussion on how and where to consistently use
the final keyword (if that's desirable), especially within the context of
reviewing pull requests.

On Wed, Jun 19, 2019 at 11:23 AM Bill Burcham  wrote:

> -1 to the proposal as I understand it:
>
> Premise:
>
> a. Because the "final" modifier on local variables serves no function other
> than to inform compiler optimization and…
>
> b. because the compiler can tell if a variable is "effectively final"
> without an explicit "final" modifier in the source code
>
> Conclusion:
>
> • The "final" modifier is just "noise" in the source code, so…
>
> Ramifications:
>
> 1. Do not use the "final" modifier on local variables.
>
> 2. By extension, it would be not just ok, but in fact a positive change, to
> _remove_ the "final" keyword from local variables, because it is just
> noise.
>
> 3. I believe the proposal should be interpreted to apply to method
> parameters as well—not just local variables. (Local variables includes loop
> variables when using for-each syntax—those can potentially be declared
> "final" just like any other local variable).
>
>
> I am thumbs-down on the proposal, first, because I believe the premise of
> the proposal is flawed. If the only value of the "final" modifier on
> storage was compile-time optimization then my view might be different. The
> fact is that the "final" modifier on a variable (or for-each loop variable)
> or method parameter declaration expresses the developer's intention that
> the value not be modified after initialization. Any violation of that
> intention will be flagged and rejected by the compiler. As such, the
> "final" modifier on variable and method parameter declarations is part of
> our arsenal of Java language constructs, such as types (including generic
> types), that let us express our intentions to the compiler.
>
> Lurking in the proposal is a danger (ramification (2)): that some of us
> will think it's not only ok, but an _improvement_ to actively _remove_
> final modifiers from local variable declarations, parameter declarations
> and for-each loop variable declarations. This lurking danger is a clear and
> present threat which I feel requires urgent consensus.
>
> I, for one, put "final" where I mean to put "final". I shouldn't have to
> monitor every single PR to ensure my finals aren't removed as noise—any
> more than I should have to monitor PRs to ensure folks aren't turning
> List back into (pre-generic) List.
>
> Can we at least agree to this:
>
> • when we encounter a final local variable, method parameter, or for-each
> loop variable declaration, we agree to _not_ remove the final modifier
> unless we have to
>
> And by "have to", I mean, we actually need to mutate the variable to make
> the code work. Any aesthetic concern about "final" being "noise" would not
> count here.
>
> -Bill
>

Re: [PROPOSAL]: Improve OQL Method Invocation Security

[Jacob Barrett]

Thanks Juan!

> On Jun 19, 2019, at 9:55 AM, Juan José Ramos  wrote:
> 
> Hello all,
> 
> I've removed all "biased" words I could find from the original document so
> the *Proposal [1]* is ready for review and discussion now. All feedback is
> welcome.
> Best regards.
> 
> [1]:
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
> 
>> On Fri, Jun 14, 2019 at 8:39 PM Juan José Ramos  wrote:
>> 
>> Hey Jake,
>> 
>> Thanks for bringing this up. As you might have found out already, english
>> is not my native language, I actually had to do some research to find out
>> *exactly what you meant* regarding the bias around the "whitelist" word
>> :-|... It was an honest mistake and I sincerely apologize in advance if
>> anyone got offended in any way.
>> That said, I won't have time to go through the proposal and make the
>> required changes until next week, so I'll keep the document hidden until
>> all biased words are replaced.
>> Cheers.
>> 
>> 
>> On Sat, Jun 15, 2019 at 12:25 AM Jacob Barrett 
>> wrote:
>> 
 As part of GEODE-3247 ,
>>> several options were analysed and, after considering the wealth of security
>>> holes and the difficulty of determining which methods deployed by the
>>> developer were intended to be available for queries and which were not, the
>>> decision was made to tighten up the Security and, by default, disallow any
>>> method call not explicitly whitelisted.
>>> 
>>> Please avoid biased words, like whitelist, in source and proposals. There
>>> are several other places in this document that use these terms. Can you
>>> please update the document without them.
>>> 
>>> Thanks,
>>> Jake
>>> 
>>> 
>> 
>> --
>> Juan José Ramos Cassella
>> Senior Technical Support Engineer
>> Email: jra...@pivotal.io
>> Office#: +353 21 4238611
>> Mobile#: +353 87 2074066
>> After Hours Contact#: +1 877 477 2269
>> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
>> How to upload artifacts:
>> https://support.pivotal.io/hc/en-us/articles/204369073
>> How to escalate a ticket:
>> https://support.pivotal.io/hc/en-us/articles/203809556
>> 
>> [image: support]  [image: twitter]
>>  [image: linkedin]
>>  [image: facebook]
>>  [image: google plus]
>>  [image: youtube]
>> 
>> 
> 
> 
> -- 
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jra...@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
> 
> [image: support]  [image: twitter]
>  [image: linkedin]
>  [image: facebook]
>  [image: google plus]
>  [image: youtube]
> 

Re: Unnecessary uses of final on local variables

[Bill Burcham]

-1 to the proposal as I understand it:

Premise:

a. Because the "final" modifier on local variables serves no function other
than to inform compiler optimization and…

b. because the compiler can tell if a variable is "effectively final"
without an explicit "final" modifier in the source code

Conclusion:

• The "final" modifier is just "noise" in the source code, so…

Ramifications:

1. Do not use the "final" modifier on local variables.

2. By extension, it would be not just ok, but in fact a positive change, to
_remove_ the "final" keyword from local variables, because it is just noise.

3. I believe the proposal should be interpreted to apply to method
parameters as well—not just local variables. (Local variables includes loop
variables when using for-each syntax—those can potentially be declared
"final" just like any other local variable).


I am thumbs-down on the proposal, first, because I believe the premise of
the proposal is flawed. If the only value of the "final" modifier on
storage was compile-time optimization then my view might be different. The
fact is that the "final" modifier on a variable (or for-each loop variable)
or method parameter declaration expresses the developer's intention that
the value not be modified after initialization. Any violation of that
intention will be flagged and rejected by the compiler. As such, the
"final" modifier on variable and method parameter declarations is part of
our arsenal of Java language constructs, such as types (including generic
types), that let us express our intentions to the compiler.

Lurking in the proposal is a danger (ramification (2)): that some of us
will think it's not only ok, but an _improvement_ to actively _remove_
final modifiers from local variable declarations, parameter declarations
and for-each loop variable declarations. This lurking danger is a clear and
present threat which I feel requires urgent consensus.

I, for one, put "final" where I mean to put "final". I shouldn't have to
monitor every single PR to ensure my finals aren't removed as noise—any
more than I should have to monitor PRs to ensure folks aren't turning
List back into (pre-generic) List.

Can we at least agree to this:

• when we encounter a final local variable, method parameter, or for-each
loop variable declaration, we agree to _not_ remove the final modifier
unless we have to

And by "have to", I mean, we actually need to mutate the variable to make
the code work. Any aesthetic concern about "final" being "noise" would not
count here.

-Bill

Re: Unnecessary uses of final on local variables

[Udo Kohlmeyer]

I agree with Darrel, Bill has made some very compelling arguments.

I also add my vote of -1 to remove "noisy" final keywords from local 
variables.


I am VERY interested in understanding how the JVM would handle this, as 
final is a keyword that stops the reassignment of the variable with 
another value. It would never stop immutability concerns. This can only 
be achieved by following stricter rules regarding how Pojos are created 
and coding practices.


I believe it is better to be more secure and opt-out when not required, 
than trying to add-in being more secure (as you are more likely to miss 
things).


--Udo

On 6/19/19 08:41, Darrel Schneider wrote:

I find Bill's argument of using final by default on everything convincing
and removing it when you have something that needs to be changed.
It is not in keeping with my current practice but I'm willing to change.
So I vote -1 to not using "final" on local variables.


On Wed, Jun 19, 2019 at 7:29 AM Anthony Baker  wrote:


Just to confirm, the primary place where we make project decisions is on
the dev@geode list.  Thanks!

Anthony



On Jun 19, 2019, at 7:19 AM, Bill Burcham  wrote:

I feel that a lot more
conversation is needed, outside email. On the other hand, this mailing

list

is a fine place to deliberate. But to deliberate successfully on this
issue, via email, I think we'll have to break it down further, and we'll
have to be comfortable with the process taking a long time.

Re: [PROPOSAL]: Improve OQL Method Invocation Security

[Juan José Ramos]

Hello all,

I've removed all "biased" words I could find from the original document so
the *Proposal [1]* is ready for review and discussion now. All feedback is
welcome.
Best regards.

[1]:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security

On Fri, Jun 14, 2019 at 8:39 PM Juan José Ramos  wrote:

> Hey Jake,
>
> Thanks for bringing this up. As you might have found out already, english
> is not my native language, I actually had to do some research to find out
> *exactly what you meant* regarding the bias around the "whitelist" word
> :-|... It was an honest mistake and I sincerely apologize in advance if
> anyone got offended in any way.
> That said, I won't have time to go through the proposal and make the
> required changes until next week, so I'll keep the document hidden until
> all biased words are replaced.
> Cheers.
>
>
> On Sat, Jun 15, 2019 at 12:25 AM Jacob Barrett 
> wrote:
>
>> > As part of GEODE-3247 ,
>> several options were analysed and, after considering the wealth of security
>> holes and the difficulty of determining which methods deployed by the
>> developer were intended to be available for queries and which were not, the
>> decision was made to tighten up the Security and, by default, disallow any
>> method call not explicitly whitelisted.
>>
>> Please avoid biased words, like whitelist, in source and proposals. There
>> are several other places in this document that use these terms. Can you
>> please update the document without them.
>>
>> Thanks,
>> Jake
>>
>>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jra...@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support]  [image: twitter]
>  [image: linkedin]
>  [image: facebook]
>  [image: google plus]
>  [image: youtube]
> 
>


-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Re: Apache Geode 1.10 release

[Anthony Baker]

The nominal schedule as discussed previously [1] is quarterly.  I think we 
avoided doing a 1.10 release this quarterly so probably the next one is Q3 
2019…August / September?

Anthony

[1] 
https://lists.apache.org/thread.html/8626f7cc73b49cc90129ec5f6021adab3815469048787032935bfc1e@%3Cdev.geode.apache.org%3E
 



> On Jun 18, 2019, at 11:32 PM, Mario Kevo  wrote:
> 
> Hi all,
> 
> I saw that on Wiki pages is not updated when should be next Geode
> release? Does anyone know when it is planned?
> 
> Thanks in advance,
> Mario

Re: Unnecessary uses of final on local variables

[Darrel Schneider]

I find Bill's argument of using final by default on everything convincing
and removing it when you have something that needs to be changed.
It is not in keeping with my current practice but I'm willing to change.
So I vote -1 to not using "final" on local variables.


On Wed, Jun 19, 2019 at 7:29 AM Anthony Baker  wrote:

> Just to confirm, the primary place where we make project decisions is on
> the dev@geode list.  Thanks!
>
> Anthony
>
>
> > On Jun 19, 2019, at 7:19 AM, Bill Burcham  wrote:
> >
> > I feel that a lot more
> > conversation is needed, outside email. On the other hand, this mailing
> list
> > is a fine place to deliberate. But to deliberate successfully on this
> > issue, via email, I think we'll have to break it down further, and we'll
> > have to be comfortable with the process taking a long time.
>
>

Re: Unnecessary uses of final on local variables

[Anthony Baker]

Just to confirm, the primary place where we make project decisions is on the 
dev@geode list.  Thanks!

Anthony


> On Jun 19, 2019, at 7:19 AM, Bill Burcham  wrote:
> 
> I feel that a lot more
> conversation is needed, outside email. On the other hand, this mailing list
> is a fine place to deliberate. But to deliberate successfully on this
> issue, via email, I think we'll have to break it down further, and we'll
> have to be comfortable with the process taking a long time.

Re: Unnecessary uses of final on local variables

[Bill Burcham]

Shorter methods are better! Code is indeed better when it's understandable
in smaller chunks.

The reason shorter methods are better is because there is less you have to
hold in your mind when evaluating them. That's why I make fields, method
parameters, and local variables final by default—when final is the default
for those, I don't have to wonder, at some point in the code, whether they
have changed. Non-final variables stand out in stark relief.

Murtuza's point that "final in Java does not guarantee immutability" is
true on its face. What the final modifier does on a field/variable
declaration is ensure that the primitive value or reference is immutable.
Yes you can still construct classes whose instances are mutable because you
can choose to make one or more fields not final. But there is great value
in declaring your intention not to mutate certain fields/variables.
Declaring that intention lets you use the compiler to check that your
intentions are not violated.

I'm happy we have started this discussion, but from the magnitude of
divergence in the responses, this email thread seems like the wrong time
and place to lock down a group decision. I feel that a lot more
conversation is needed, outside email. On the other hand, this mailing list
is a fine place to deliberate. But to deliberate successfully on this
issue, via email, I think we'll have to break it down further, and we'll
have to be comfortable with the process taking a long time.

On Tue, Jun 18, 2019 at 3:23 PM Owen Nichols  wrote:

> I recommend:
> * Use final if you want to
> * Don’t -1 someone’s PR because they did or didn’t use final.
>
>
> Personally, there is one case where I like to use final on a local
> variable: forcing the compiler to tell me if I’ve covered all code paths.
> Here’s a very simple example:
>
> final int x;
> if (cond) {
>   x = 1;
> }
> else if(othercond) {
>  x = 2;
> }
>
> //this will fail to compile because there is still one codepath where x
> never gets initialized.
>
> Without final, you might be temped to write it more compactly as:
>
> int x = 2;
> if (cond) {
>   x = 1;
> }
>
> //in this case, instead of a compiler error, you get a very subtle bug.
> Let the compiler work for you whenever possible!
>
> This strategy is also handy if you’re initializing a variable with a
> switch statements, because the final declaration will protect you from
> missing break statements.
>
> > On Jun 18, 2019, at 3:02 PM, Murtuza Boxwala 
> wrote:
> >
> > What does "rough consensus"[1] look like on this thread? How do we make
> a decision and close it out?
> >
> > Kirk suggested an idea, there’s been a couple days of feedback, so we
> can:
> >
> > 1) reject the proposal and commit to using final ‘everywhere'
> > 2) accept the proposal and use final very sparingly
> > 3) continue the discussion over e-mail
> > 4) take other steps to come to a consensus like
> >   have a meeting with a few folks who are passionate about the topic
> >Try both approaches.  Pick one module and use final everywhere,
> and pick another and use it sparingly and see which approach we like
> >
> >
> > Personally, I don’t see any “fundamental flaws"[1] with using final or
> removing it.
> >
> >
> > Also, I might just be rushing the natural flow of conversation, so in
> that case, sorry for being impatient.
> >
> > 1-https://doist.com/blog/decision-making-flat-organization/ <
> https://doist.com/blog/decision-making-flat-organization/>
> >
> >> On Jun 18, 2019, at 2:48 PM, Jinmei Liao  wrote:
> >>
> >> I agree with Murtuza, most finals on local variables and method
> parameters
> >> are just noise to me. I only use "final" on these two situations:
> >> 1. to declare public static constants of immutable types (e.g. String,
> >> Integer)
> >> 2. to prevent children from overriding a method.
> >>
> >> But thought I can't offer an example, I don't want to put out a blank
> >> statement saying that "final" on local variables are entirely
> unnecessary.
> >> There must be a case that it could be useful, so even if we come to a
> >> consensus that local variables should not have final on it, I don't
> think
> >> using a static analysis tool to get rid of all of them is a good idea.
> >>
> >> On Tue, Jun 18, 2019 at 11:14 AM Anthony Baker 
> wrote:
> >>
> >>> I’ll offer this alternative:  perhaps shorter method bodies obviate the
> >>> need for explicit final vars.
> >>>
> >>> Anthony
> >>>
> >>>
>  On Jun 18, 2019, at 10:30 AM, Ernest Burghardt  >
> >>> wrote:
> 
>  +1 to auto-enforcement (if possible) post-consensus
> 
>  On Tue, Jun 18, 2019 at 8:33 AM Murtuza Boxwala 
> >>> wrote:
> 
> > final in Java does not guarantee immutability.  It would be AWESOME
> if
> >>> it
> > did but all it guarantees is that the variable cannot be reassigned.
> In
> > most cases the variable points to an object’s location (memory
> >>> address), so
> > you can still call methods on it, e.g.
> >
> > final var = new 

Apache Geode 1.10 release

[Mario Kevo]

Hi all,

I saw that on Wiki pages is not updated when should be next Geode
release? Does anyone know when it is planned?

Thanks in advance,
Mario