> David Radley wrote: > > Is it worth fixing and releasing Avatica first then release the new > Calcite version that depends on it?
In an ideal world, yes. But we are volunteer-driven, and a release takes time and effort. To make a release of Avatica, a few bugs will need to be fixed, and then several days for a release vote. It will inevitably delay the Calcite release. I'd rather finish the original goal, an RC of Calcite next week, hopefully followed by a release by the end of the month. > Looking around getSubject, is there alternative security calls we > should be making in its absence? If the getSubject() is resulting > in extra security (even if it is deprecated), should we remove it > only for java 23? I'm not an expert on Java security. But generally things get more secure over time, and when something is deprecated there's usually a (better) replacement that has been around for some time. I suspect that will be the case here. Having different code for different runtime environments is very tricky. (We have done it before, in a few cases, using reflection.) But I don't want to do something "tricky" when it relates to security. (Even though it's very tempting, because I just want to get the tests to pass, and the tests are not even about security.) Let's keep it simple: use the same, correct, security system in all environments. Julian On Fri, Sep 20, 2024 at 5:56 AM David Radley <david_rad...@uk.ibm.com> wrote: > > Hi, > Some thoughts on this. > > Is it worth fixing and releasing Avatica first then release the new Calcite > version that depends on it? > Looking around getSubject, is there alternative security calls we should be > making in its absence? > If the getSubject() is resulting in extra security (even if it is > deprecated), should we remove it only for java 23? > Kind regards, David > > From: Ruben Q L <rube...@gmail.com> > Date: Thursday, 19 September 2024 at 19:46 > To: dev@calcite.apache.org <dev@calcite.apache.org> > Subject: [EXTERNAL] Re: [DISCUSS] Towards Avatica 1.26.0 > +1, I think the proposed plan seems reasonable. > > Ruben > > > On Thu, Sep 19, 2024 at 5:31 PM Julian Hyde <jh...@apache.org> wrote: > > > While working towards releasing Calcite 1.38.0, I noticed that JDK 23 > > has been released, and decided to try to upgrade Calcite to support > > it[1]. And I found myself blocked by an Avatica bug, namely that > > Avatica uses a getSubject method that has been deprecated for some > > time and finally disabled in JDK 23. (Incidentally, Hadoop has the > > same problem [3]; people don't expect them to run on the current JDK, > > but we will need to disable our Spark and Pig adapter tests under JDK > > 23 until they fix it.) > > > > There's currently just one bug, to upgrade Avatica to JDK 23. This > > includes re-enabling the mode where we fail to compile if any > > deprecated methods are used, and removing uses of getSubject [2]. > > > > I think we can release Calcite 1.38.0 with limited JDK 23 support > > (i.e. a few tests disabled), but we're going to need a new Avatica > > release in the next month or two, and it will need to fix the > > getSubject issue. > > > > What do you think? > > > > Julian > > > > [1] https://issues.apache.org/jira/browse/CALCITE-6587 > > [2] https://issues.apache.org/jira/browse/CALCITE-6588 > > [3] https://issues.apache.org/jira/browse/HADOOP-19212 > > > > Unless otherwise stated above: > > IBM United Kingdom Limited > Registered in England and Wales with number 741598 > Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
