Re: Google Guava in Ignite 3

[Courtney Robinson]

Also, what impact will this have on peer class loading? Something I think
shading also resolves


On Thu, Aug 5, 2021 at 7:05 PM Courtney Robinson 
wrote:

> Can I suggest shading Guava?
> Guava and Netty are two notorious libraries for version conflicts because
> of their popularity and usefulness.
> Other projects (ES for example solved it by shading them it
> https://github.com/elastic/elasticsearch/issues/2091#issuecomment-7156766
> ).
>
> We use Ignite entirely as a thick client and already have Guava version
> conflicts from other projects (Calcite being one because we use it directly
> already) so Ignite bringing its own will only make this worse when we get
> to V3.
>
> Even Calcite itself already has Guava conflicts because of the Cassandra
> adapter. I'd +1 this but really only if it will be shaded.
>
> Regards,
> Courtney Robinson
> Founder and CEO, Hypi
> Tel: ++44 208 123 2413 (GMT+0) 
>
> 
> https://hypi.io
>
>
> On Thu, Aug 5, 2021 at 5:56 PM Zhenya Stanilovsky
>  wrote:
>
>>
>> alexpolovtcev please clarify what do you mean under : «possibility of
>> using Guava in Ignite 3», using how  necessary dependency of calcite or
>> using like «using in our code» ? If using in code, i -1 here.
>> thanks.
>>
>>
>> >Hello, dear Igniters!
>> >
>> >I would like to discuss the possibility of using Guava
>> >< https://github.com/google/guava > in Ignite 3. I know about the
>> restrictive
>> >policy of using it in Ignite 2, but I have the following reasons:
>> >
>> >1. We are de-facto using it already as an implicit dependency, since the
>> >Calcite module depends on it, and Calcite is going to stay for a while =)
>> >2. AFAIK, the "bytecode" module is copied into the codebase only to strip
>> >Guava away from it. We can remove this module, which will improve the
>> >maintainability of the project.
>> >3. We have some copy-paste of Guava code in the project. For example, see
>> >this
>> ><
>> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L136
>> >
>> >and this
>> ><
>> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L428
>> >
>> >.
>> >4. Regarding security concerns, this report
>> ><
>> https://www.cvedetails.com/product/52274/Google-Guava.html?vendor_id=1224
>> >
>> >shows no major vulnerability issues for the last three years.
>> >
>> >Taking these points into account, I propose to allow using Guava both in
>> >production and test code and to add it as an explicit dependency.
>> >
>> >What do you think?
>> >
>> >--
>> >With regards,
>> >Aleksandr Polovtcev
>>
>>
>>
>>
>
>

Re: Google Guava in Ignite 3

[Courtney Robinson]

Can I suggest shading Guava?
Guava and Netty are two notorious libraries for version conflicts because
of their popularity and usefulness.
Other projects (ES for example solved it by shading them it
https://github.com/elastic/elasticsearch/issues/2091#issuecomment-7156766).

We use Ignite entirely as a thick client and already have Guava version
conflicts from other projects (Calcite being one because we use it directly
already) so Ignite bringing its own will only make this worse when we get
to V3.

Even Calcite itself already has Guava conflicts because of the Cassandra
adapter. I'd +1 this but really only if it will be shaded.

Regards,
Courtney Robinson
Founder and CEO, Hypi
Tel: ++44 208 123 2413 (GMT+0) 


https://hypi.io


On Thu, Aug 5, 2021 at 5:56 PM Zhenya Stanilovsky
 wrote:

>
> alexpolovtcev please clarify what do you mean under : «possibility of
> using Guava in Ignite 3», using how  necessary dependency of calcite or
> using like «using in our code» ? If using in code, i -1 here.
> thanks.
>
>
> >Hello, dear Igniters!
> >
> >I would like to discuss the possibility of using Guava
> >< https://github.com/google/guava > in Ignite 3. I know about the
> restrictive
> >policy of using it in Ignite 2, but I have the following reasons:
> >
> >1. We are de-facto using it already as an implicit dependency, since the
> >Calcite module depends on it, and Calcite is going to stay for a while =)
> >2. AFAIK, the "bytecode" module is copied into the codebase only to strip
> >Guava away from it. We can remove this module, which will improve the
> >maintainability of the project.
> >3. We have some copy-paste of Guava code in the project. For example, see
> >this
> ><
> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L136
> >
> >and this
> ><
> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L428
> >
> >.
> >4. Regarding security concerns, this report
> ><
> https://www.cvedetails.com/product/52274/Google-Guava.html?vendor_id=1224
> >
> >shows no major vulnerability issues for the last three years.
> >
> >Taking these points into account, I propose to allow using Guava both in
> >production and test code and to add it as an explicit dependency.
> >
> >What do you think?
> >
> >--
> >With regards,
> >Aleksandr Polovtcev
>
>
>
>

Re: Google Guava in Ignite 3

[Zhenya Stanilovsky]

alexpolovtcev please clarify what do you mean under : «possibility of using 
Guava in Ignite 3», using how  necessary dependency of calcite or using like 
«using in our code» ? If using in code, i -1 here.
thanks.
 
 
>Hello, dear Igniters!
>
>I would like to discuss the possibility of using Guava
>< https://github.com/google/guava > in Ignite 3. I know about the restrictive
>policy of using it in Ignite 2, but I have the following reasons:
>
>1. We are de-facto using it already as an implicit dependency, since the
>Calcite module depends on it, and Calcite is going to stay for a while =)
>2. AFAIK, the "bytecode" module is copied into the codebase only to strip
>Guava away from it. We can remove this module, which will improve the
>maintainability of the project.
>3. We have some copy-paste of Guava code in the project. For example, see
>this
>< 
>https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L136
> >
>and this
>< 
>https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L428
> >
>.
>4. Regarding security concerns, this report
>< https://www.cvedetails.com/product/52274/Google-Guava.html?vendor_id=1224 >
>shows no major vulnerability issues for the last three years.
>
>Taking these points into account, I propose to allow using Guava both in
>production and test code and to add it as an explicit dependency.
>
>What do you think?
>
>--
>With regards,
>Aleksandr Polovtcev 
 
 
 
 

Re: Google Guava in Ignite 3

[Ivan Daschinsky]

>>   A user might want to use one more version.

Am I wrong, but user is supposed to use thin client in ignite 3? So why we
should care about guava since, frankly, it is not needed in thin client and
we can make it not dependent on guava at all?


чт, 5 авг. 2021 г. в 18:18, Alexander Polovtcev :

> Thanks for the feedback, Andrey.
>
> Let me address your arguments:
>
> > Original Bytecode module depends on 26.0-jre Calcite depends on 29.0-jre
> We
> maybe will use some other version. A user might want to use one more
> version.
>
> This problem exists regardless of the fact that we allow using Guava in
> Ignite. Many libraries use it and we will always have version clashes. At
> least we can force the usage of a single version across the project. Also,
> removing a copy-paste module is a definite improvement in terms of
> maintainability, because it will be easier to sync its code with the
> upstream in case we find any bugs or vulnerabilities.
>
> > Guava supports JDK-8. Is it possible to handle different
> versions of Guava in dependencies with JigSaw? What impact will have
> potential future CVEs (and the current one) with the JigSaw?
>
> Sorry, but I don't fully understand this question. I'm not very proficient
> with Jigsaw, but I'm not sure that it is possible to have multiple jars
> with different versions when using it.
>
> > Guava has an unresolved CVE
>
> We have multiple ways of dealing with that:
>
> 1. Wait for them to fix it.
> 2. Create a fork.
> 3. Prove that we don't use the method that exposes this vulnerability.
>
> I would also like to stress that this problem exists even now, because we
> already use Guava implicitly, so it is not very relevant to the original
> topic of this discussion.
>
> On Thu, Aug 5, 2021 at 5:24 PM Andrey Mashenkov <
> andrey.mashen...@gmail.com>
> wrote:
>
> > -1
> > It is sad to say -1, as Guava has very useful stuff and it looks easier
> to
> > add it as a dependency rather than copy-paste a code. My concerns are: 1.
> > Original Bytecode module depends on 26.0-jre Calcite depends on 29.0-jre
> We
> > maybe will use some other version. A user might want to use one more
> > version. So, I'd disagree legalizing Guava will help with maintainability
> > anyhow. 2. Guava supports JDK-8. Is it possible to handle different
> > versions of Guava in dependencies with JigSaw? What impact will have
> > potential future CVEs (and the current one) with the JigSaw? 3. Guava has
> > an unresolved CVE [1]. They just mark a vulnerable method as Deprecated
> and
> > didn't actually fix it [2]. [1]
> > https://github.com/google/guava/issues/4011
> > [2] https://github.com/google/guava/issues/4011
> >
> > On Thu, Aug 5, 2021 at 4:54 PM Konstantin Orlov 
> > wrote:
> >
> > > +1, I considered it a necessary evil
> > >
> > > --
> > > Regards,
> > > Konstantin Orlov
> > >
> > >
> > >
> > > > On 5 Aug 2021, at 16:37, Alexei Scherbakov <
> > alexey.scherbak...@gmail.com>
> > > wrote:
> > > >
> > > > +1
> > > >
> > > > чт, 5 авг. 2021 г. в 16:12, Alexander Polovtcev <
> > alexpolovt...@gmail.com
> > > >:
> > > >
> > > >> Hello, dear Igniters!
> > > >>
> > > >> I would like to discuss the possibility of using Guava
> > > >>  in Ignite 3. I know about the
> > > >> restrictive
> > > >> policy of using it in Ignite 2, but I have the following reasons:
> > > >>
> > > >> 1. We are de-facto using it already as an implicit dependency, since
> > the
> > > >> Calcite module depends on it, and Calcite is going to stay for a
> while
> > > =)
> > > >> 2. AFAIK, the "bytecode" module is copied into the codebase only to
> > > strip
> > > >> Guava away from it. We can remove this module, which will improve
> the
> > > >> maintainability of the project.
> > > >> 3. We have some copy-paste of Guava code in the project. For
> example,
> > > see
> > > >> this
> > > >> <
> > > >>
> > >
> >
> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L136
> > > >>>
> > > >> and this
> > > >> <
> > > >>
> > >
> >
> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L428
> > > >>>
> > > >> .
> > > >> 4. Regarding security concerns, this report
> > > >> <
> > >
> >
> https://www.cvedetails.com/product/52274/Google-Guava.html?vendor_id=1224
> > > >>>
> > > >> shows no major vulnerability issues for the last three years.
> > > >>
> > > >> Taking these points into account, I propose to allow using Guava
> both
> > in
> > > >> production and test code and to add it as an explicit dependency.
> > > >>
> > > >> What do you think?
> > > >>
> > > >> --
> > > >> With regards,
> > > >> Aleksandr Polovtcev
> > > >>
> > > >
> > > >
> > > > --
> > > >
> > > > Best regards,
> > > > Alexei Scherbakov
> > >
> > >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>
>
> --
> With regards,
> Aleksandr Polovtcev
>

Re: Google Guava in Ignite 3

[Alexander Polovtcev]

Thanks for the feedback, Andrey.

Let me address your arguments:

> Original Bytecode module depends on 26.0-jre Calcite depends on 29.0-jre
We
maybe will use some other version. A user might want to use one more
version.

This problem exists regardless of the fact that we allow using Guava in
Ignite. Many libraries use it and we will always have version clashes. At
least we can force the usage of a single version across the project. Also,
removing a copy-paste module is a definite improvement in terms of
maintainability, because it will be easier to sync its code with the
upstream in case we find any bugs or vulnerabilities.

> Guava supports JDK-8. Is it possible to handle different
versions of Guava in dependencies with JigSaw? What impact will have
potential future CVEs (and the current one) with the JigSaw?

Sorry, but I don't fully understand this question. I'm not very proficient
with Jigsaw, but I'm not sure that it is possible to have multiple jars
with different versions when using it.

> Guava has an unresolved CVE

We have multiple ways of dealing with that:

1. Wait for them to fix it.
2. Create a fork.
3. Prove that we don't use the method that exposes this vulnerability.

I would also like to stress that this problem exists even now, because we
already use Guava implicitly, so it is not very relevant to the original
topic of this discussion.

On Thu, Aug 5, 2021 at 5:24 PM Andrey Mashenkov 
wrote:

> -1
> It is sad to say -1, as Guava has very useful stuff and it looks easier to
> add it as a dependency rather than copy-paste a code. My concerns are: 1.
> Original Bytecode module depends on 26.0-jre Calcite depends on 29.0-jre We
> maybe will use some other version. A user might want to use one more
> version. So, I'd disagree legalizing Guava will help with maintainability
> anyhow. 2. Guava supports JDK-8. Is it possible to handle different
> versions of Guava in dependencies with JigSaw? What impact will have
> potential future CVEs (and the current one) with the JigSaw? 3. Guava has
> an unresolved CVE [1]. They just mark a vulnerable method as Deprecated and
> didn't actually fix it [2]. [1]
> https://github.com/google/guava/issues/4011
> [2] https://github.com/google/guava/issues/4011
>
> On Thu, Aug 5, 2021 at 4:54 PM Konstantin Orlov 
> wrote:
>
> > +1, I considered it a necessary evil
> >
> > --
> > Regards,
> > Konstantin Orlov
> >
> >
> >
> > > On 5 Aug 2021, at 16:37, Alexei Scherbakov <
> alexey.scherbak...@gmail.com>
> > wrote:
> > >
> > > +1
> > >
> > > чт, 5 авг. 2021 г. в 16:12, Alexander Polovtcev <
> alexpolovt...@gmail.com
> > >:
> > >
> > >> Hello, dear Igniters!
> > >>
> > >> I would like to discuss the possibility of using Guava
> > >>  in Ignite 3. I know about the
> > >> restrictive
> > >> policy of using it in Ignite 2, but I have the following reasons:
> > >>
> > >> 1. We are de-facto using it already as an implicit dependency, since
> the
> > >> Calcite module depends on it, and Calcite is going to stay for a while
> > =)
> > >> 2. AFAIK, the "bytecode" module is copied into the codebase only to
> > strip
> > >> Guava away from it. We can remove this module, which will improve the
> > >> maintainability of the project.
> > >> 3. We have some copy-paste of Guava code in the project. For example,
> > see
> > >> this
> > >> <
> > >>
> >
> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L136
> > >>>
> > >> and this
> > >> <
> > >>
> >
> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L428
> > >>>
> > >> .
> > >> 4. Regarding security concerns, this report
> > >> <
> >
> https://www.cvedetails.com/product/52274/Google-Guava.html?vendor_id=1224
> > >>>
> > >> shows no major vulnerability issues for the last three years.
> > >>
> > >> Taking these points into account, I propose to allow using Guava both
> in
> > >> production and test code and to add it as an explicit dependency.
> > >>
> > >> What do you think?
> > >>
> > >> --
> > >> With regards,
> > >> Aleksandr Polovtcev
> > >>
> > >
> > >
> > > --
> > >
> > > Best regards,
> > > Alexei Scherbakov
> >
> >
>
> --
> Best regards,
> Andrey V. Mashenkov
>


-- 
With regards,
Aleksandr Polovtcev

Re[2]: Google Guava in Ignite 3

[Zhenya Stanilovsky]

Andrey, seems we can use [1] it help us with point 1 in your comment, isn`t it ?
 
[1]  
https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
 
>-1
>It is sad to say -1, as Guava has very useful stuff and it looks easier to
>add it as a dependency rather than copy-paste a code. My concerns are: 1.
>Original Bytecode module depends on 26.0-jre Calcite depends on 29.0-jre We
>maybe will use some other version. A user might want to use one more
>version. So, I'd disagree legalizing Guava will help with maintainability
>anyhow. 2. Guava supports JDK-8. Is it possible to handle different
>versions of Guava in dependencies with JigSaw? What impact will have
>potential future CVEs (and the current one) with the JigSaw? 3. Guava has
>an unresolved CVE [1]. They just mark a vulnerable method as Deprecated and
>didn't actually fix it [2]. [1]  https://github.com/google/guava/issues/4011
>[2]  https://github.com/google/guava/issues/4011
>
>On Thu, Aug 5, 2021 at 4:54 PM Konstantin Orlov < kor...@gridgain.com > wrote:
> 
>> +1, I considered it a necessary evil
>>
>> --
>> Regards,
>> Konstantin Orlov
>>
>>
>>
>> > On 5 Aug 2021, at 16:37, Alexei Scherbakov < alexey.scherbak...@gmail.com >
>> wrote:
>> >
>> > +1
>> >
>> > чт, 5 авг. 2021 г. в 16:12, Alexander Polovtcev < alexpolovt...@gmail.com
>> >:
>> >
>> >> Hello, dear Igniters!
>> >>
>> >> I would like to discuss the possibility of using Guava
>> >> < https://github.com/google/guava > in Ignite 3. I know about the
>> >> restrictive
>> >> policy of using it in Ignite 2, but I have the following reasons:
>> >>
>> >> 1. We are de-facto using it already as an implicit dependency, since the
>> >> Calcite module depends on it, and Calcite is going to stay for a while
>> =)
>> >> 2. AFAIK, the "bytecode" module is copied into the codebase only to
>> strip
>> >> Guava away from it. We can remove this module, which will improve the
>> >> maintainability of the project.
>> >> 3. We have some copy-paste of Guava code in the project. For example,
>> see
>> >> this
>> >> <
>> >>
>>  
>> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L136
>> >>>
>> >> and this
>> >> <
>> >>
>>  
>> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L428
>> >>>
>> >> .
>> >> 4. Regarding security concerns, this report
>> >> <
>>  https://www.cvedetails.com/product/52274/Google-Guava.html?vendor_id=1224
>> >>>
>> >> shows no major vulnerability issues for the last three years.
>> >>
>> >> Taking these points into account, I propose to allow using Guava both in
>> >> production and test code and to add it as an explicit dependency.
>> >>
>> >> What do you think?
>> >>
>> >> --
>> >> With regards,
>> >> Aleksandr Polovtcev
>> >>
>> >
>> >
>> > --
>> >
>> > Best regards,
>> > Alexei Scherbakov
>>
>>
>--
>Best regards,
>Andrey V. Mashenkov 
 
 
 
 

Re: Google Guava in Ignite 3

[Konstantin Orlov]

Hi, Andrey!

But what should we do with Calcite then? It already brings Guava to the 
project. 
Should we considered exclusion of the main and only query engine from the 
Ignite-3.0?

-- 
Regards,
Konstantin Orlov




> On 5 Aug 2021, at 17:23, Andrey Mashenkov  wrote:
> 
> -1
> It is sad to say -1, as Guava has very useful stuff and it looks easier to
> add it as a dependency rather than copy-paste a code. My concerns are: 1.
> Original Bytecode module depends on 26.0-jre Calcite depends on 29.0-jre We
> maybe will use some other version. A user might want to use one more
> version. So, I'd disagree legalizing Guava will help with maintainability
> anyhow. 2. Guava supports JDK-8. Is it possible to handle different
> versions of Guava in dependencies with JigSaw? What impact will have
> potential future CVEs (and the current one) with the JigSaw? 3. Guava has
> an unresolved CVE [1]. They just mark a vulnerable method as Deprecated and
> didn't actually fix it [2]. [1] https://github.com/google/guava/issues/4011
> [2] https://github.com/google/guava/issues/4011
> 
> On Thu, Aug 5, 2021 at 4:54 PM Konstantin Orlov  wrote:
> 
>> +1, I considered it a necessary evil
>> 
>> --
>> Regards,
>> Konstantin Orlov
>> 
>> 
>> 
>>> On 5 Aug 2021, at 16:37, Alexei Scherbakov 
>> wrote:
>>> 
>>> +1
>>> 
>>> чт, 5 авг. 2021 г. в 16:12, Alexander Polovtcev >> :
>>> 
 Hello, dear Igniters!
 
 I would like to discuss the possibility of using Guava
  in Ignite 3. I know about the
 restrictive
 policy of using it in Ignite 2, but I have the following reasons:
 
 1. We are de-facto using it already as an implicit dependency, since the
 Calcite module depends on it, and Calcite is going to stay for a while
>> =)
 2. AFAIK, the "bytecode" module is copied into the codebase only to
>> strip
 Guava away from it. We can remove this module, which will improve the
 maintainability of the project.
 3. We have some copy-paste of Guava code in the project. For example,
>> see
 this
 <
 
>> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L136
> 
 and this
 <
 
>> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L428
> 
 .
 4. Regarding security concerns, this report
 <
>> https://www.cvedetails.com/product/52274/Google-Guava.html?vendor_id=1224
> 
 shows no major vulnerability issues for the last three years.
 
 Taking these points into account, I propose to allow using Guava both in
 production and test code and to add it as an explicit dependency.
 
 What do you think?
 
 --
 With regards,
 Aleksandr Polovtcev
 
>>> 
>>> 
>>> --
>>> 
>>> Best regards,
>>> Alexei Scherbakov
>> 
>> 
> 
> -- 
> Best regards,
> Andrey V. Mashenkov

Re: Google Guava in Ignite 3

[Andrey Mashenkov]

-1
It is sad to say -1, as Guava has very useful stuff and it looks easier to
add it as a dependency rather than copy-paste a code. My concerns are: 1.
Original Bytecode module depends on 26.0-jre Calcite depends on 29.0-jre We
maybe will use some other version. A user might want to use one more
version. So, I'd disagree legalizing Guava will help with maintainability
anyhow. 2. Guava supports JDK-8. Is it possible to handle different
versions of Guava in dependencies with JigSaw? What impact will have
potential future CVEs (and the current one) with the JigSaw? 3. Guava has
an unresolved CVE [1]. They just mark a vulnerable method as Deprecated and
didn't actually fix it [2]. [1] https://github.com/google/guava/issues/4011
[2] https://github.com/google/guava/issues/4011

On Thu, Aug 5, 2021 at 4:54 PM Konstantin Orlov  wrote:

> +1, I considered it a necessary evil
>
> --
> Regards,
> Konstantin Orlov
>
>
>
> > On 5 Aug 2021, at 16:37, Alexei Scherbakov 
> wrote:
> >
> > +1
> >
> > чт, 5 авг. 2021 г. в 16:12, Alexander Polovtcev  >:
> >
> >> Hello, dear Igniters!
> >>
> >> I would like to discuss the possibility of using Guava
> >>  in Ignite 3. I know about the
> >> restrictive
> >> policy of using it in Ignite 2, but I have the following reasons:
> >>
> >> 1. We are de-facto using it already as an implicit dependency, since the
> >> Calcite module depends on it, and Calcite is going to stay for a while
> =)
> >> 2. AFAIK, the "bytecode" module is copied into the codebase only to
> strip
> >> Guava away from it. We can remove this module, which will improve the
> >> maintainability of the project.
> >> 3. We have some copy-paste of Guava code in the project. For example,
> see
> >> this
> >> <
> >>
> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L136
> >>>
> >> and this
> >> <
> >>
> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L428
> >>>
> >> .
> >> 4. Regarding security concerns, this report
> >> <
> https://www.cvedetails.com/product/52274/Google-Guava.html?vendor_id=1224
> >>>
> >> shows no major vulnerability issues for the last three years.
> >>
> >> Taking these points into account, I propose to allow using Guava both in
> >> production and test code and to add it as an explicit dependency.
> >>
> >> What do you think?
> >>
> >> --
> >> With regards,
> >> Aleksandr Polovtcev
> >>
> >
> >
> > --
> >
> > Best regards,
> > Alexei Scherbakov
>
>

-- 
Best regards,
Andrey V. Mashenkov

Re: Google Guava in Ignite 3

[Konstantin Orlov]

+1, I considered it a necessary evil

-- 
Regards,
Konstantin Orlov



> On 5 Aug 2021, at 16:37, Alexei Scherbakov  
> wrote:
> 
> +1
> 
> чт, 5 авг. 2021 г. в 16:12, Alexander Polovtcev :
> 
>> Hello, dear Igniters!
>> 
>> I would like to discuss the possibility of using Guava
>>  in Ignite 3. I know about the
>> restrictive
>> policy of using it in Ignite 2, but I have the following reasons:
>> 
>> 1. We are de-facto using it already as an implicit dependency, since the
>> Calcite module depends on it, and Calcite is going to stay for a while =)
>> 2. AFAIK, the "bytecode" module is copied into the codebase only to strip
>> Guava away from it. We can remove this module, which will improve the
>> maintainability of the project.
>> 3. We have some copy-paste of Guava code in the project. For example, see
>> this
>> <
>> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L136
>>> 
>> and this
>> <
>> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L428
>>> 
>> .
>> 4. Regarding security concerns, this report
>> >> 
>> shows no major vulnerability issues for the last three years.
>> 
>> Taking these points into account, I propose to allow using Guava both in
>> production and test code and to add it as an explicit dependency.
>> 
>> What do you think?
>> 
>> --
>> With regards,
>> Aleksandr Polovtcev
>> 
> 
> 
> -- 
> 
> Best regards,
> Alexei Scherbakov

Re: Google Guava in Ignite 3

[Alexei Scherbakov]

+1

чт, 5 авг. 2021 г. в 16:12, Alexander Polovtcev :

> Hello, dear Igniters!
>
> I would like to discuss the possibility of using Guava
>  in Ignite 3. I know about the
> restrictive
> policy of using it in Ignite 2, but I have the following reasons:
>
> 1. We are de-facto using it already as an implicit dependency, since the
> Calcite module depends on it, and Calcite is going to stay for a while =)
> 2. AFAIK, the "bytecode" module is copied into the codebase only to strip
> Guava away from it. We can remove this module, which will improve the
> maintainability of the project.
> 3. We have some copy-paste of Guava code in the project. For example, see
> this
> <
> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L136
> >
> and this
> <
> https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L428
> >
> .
> 4. Regarding security concerns, this report
>  >
> shows no major vulnerability issues for the last three years.
>
> Taking these points into account, I propose to allow using Guava both in
> production and test code and to add it as an explicit dependency.
>
> What do you think?
>
> --
> With regards,
> Aleksandr Polovtcev
>


-- 

Best regards,
Alexei Scherbakov

Google Guava in Ignite 3

[Alexander Polovtcev]

Hello, dear Igniters!

I would like to discuss the possibility of using Guava
 in Ignite 3. I know about the restrictive
policy of using it in Ignite 2, but I have the following reasons:

1. We are de-facto using it already as an implicit dependency, since the
Calcite module depends on it, and Calcite is going to stay for a while =)
2. AFAIK, the "bytecode" module is copied into the codebase only to strip
Guava away from it. We can remove this module, which will improve the
maintainability of the project.
3. We have some copy-paste of Guava code in the project. For example, see
this

and this

.
4. Regarding security concerns, this report

shows no major vulnerability issues for the last three years.

Taking these points into account, I propose to allow using Guava both in
production and test code and to add it as an explicit dependency.

What do you think?

-- 
With regards,
Aleksandr Polovtcev