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 <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 > -- With regards, Aleksandr Polovtcev
