Good day, Stephen. If it will be possible to: 1. Update library visions. 2. Add JDK 25 support (I have seen a PR there, and we also work on JDK 25, and what I see is the issue only in Groovy).
That will unlock us to provide our contributions if I got everything correctly. On Wed, Jan 21, 2026 at 2:14 PM Stephen Mallette <[email protected]> wrote: > Hi Andrii - now that 3.8.x is out, I think most new features will be > targeted for 4.x with particular focus on addressing the gaps that > currently exist there (like transactions). It's not clear how long that > will take as of yet. While most effort will be on 4.x, if you think that > you have more contributions like this change with call/antlr, I think that > we could talk about doing a 3.9.x if that is helpful to you. > > Roughly speaking, I think 3.9.x changes would merge to 4.x and would need > to maintain Gremlin semantics established in 3.8.x and avoid any breaking > changes to drivers. Additive features would be less of an issue (like > call/antlr) but like all features, we'd take each one on a case by case > basis to decide what release line they are best for. > > Do you feel like you would like a 3.9.0? > > Also, happy to hear from other contributors on this topic. We hadn't > planned a 3.9.0, so please consider this an open discussion. > > > > On Wed, Jan 21, 2026 at 2:14 AM Andrii Lomakin < > [email protected]> wrote: > >> Good day. >> >> I suppose I need to add more context. >> We cannot use 4.0 if it will be released with the current feature set >> (for reasons I mentioned in other topics), so all development we do is on >> top of the 3.8 release branch. >> >> I think it would be beneficial to backport our changes to 3.8 if >> possible, but given the release policy situation, I am not sure it is. >> Would be glad if the TinkerPop team could share any ideas with us. >> >> Also, I invite anyone to join our Zulip chat to participate in >> discussions about our early-stage implementation of GQL. >> We, of course, will contact you once it is ready to refine the spec of >> the match step anyway. >> >> >> On Tue, Jan 20, 2026 at 4:11 PM Andrii Lomakin < >> [email protected]> wrote: >> >>> No, we based our changes on 3.8-dev. >>> >>> >Out of curiosity, you mentioned this update as a "need" - is there >>> something specific in the newer version that is required for the >>> implementation? >>> >>> We had problems generating visitors for the updated grammar. >>> >>> On Tue, Jan 20, 2026 at 1:24 PM Stephen Mallette <[email protected]> >>> wrote: >>> >>>> I assume you're targeting the master branch with this change. If so, >>>> then I don't think there is a problem with going to a newer version. >>>> >>>> Out of curiosity, you mentioned this update as a "need" - is there >>>> something specific in the newer version that is required for the >>>> implementation? >>>> >>>> On Tue, Jan 20, 2026 at 4:47 AM Andrii Lomakin via dev < >>>> [email protected]> wrote: >>>> >>>>> Good day, TP team. >>>>> To implement this feature, we need to update ANTLR to the latest >>>>> version. >>>>> Do you have any objections ? >>>>> If not, we will provide PR soon. >>>>> >>>>> On Mon, Jan 19, 2026 at 4:39 PM Andrii Lomakin < >>>>> [email protected]> >>>>> wrote: >>>>> >>>>> > Good day. >>>>> > As part of our efforts to implement GQL, we started working on this >>>>> issue: >>>>> > >>>>> https://youtrack.jetbrains.com/issue/YTDB-505/Implement-the-ability-to-convert-non-standard-method-calls-into-the-registered-service-calls >>>>> > . >>>>> > Sandra will provide PR once it is ready. >>>>> > >>>>> > On Fri, Nov 21, 2025 at 1:52 PM Andrii Lomakin < >>>>> [email protected]> >>>>> > wrote: >>>>> > >>>>> >> Good day, >>>>> >> >>>>> >> Following up on Ken's point about the discrepancy between scripts >>>>> and >>>>> >> traversals, I have an alternative idea that could resolve this >>>>> issue, in >>>>> >> addition to the proposal I mentioned in the other thread. >>>>> >> >>>>> >> The proposal is to introduce a mechanism that allows a user to >>>>> create a >>>>> >> part of a graph traversal in script form, such as: >>>>> >> `g.gScript("V(id).hasName()")` >>>>> >> >>>>> >> The responsibility for handling this script would then fall to the >>>>> GLV, >>>>> >> which would have two primary options: >>>>> >> >>>>> >> 1. Pass the script string to the server for parsing. >>>>> >> 2. Convert the script to local steps before passing the steps to the >>>>> >> server >>>>> >> (my preferred approach). >>>>> >> >>>>> >> For the latter, a more advanced option could be available for >>>>> vendors >>>>> >> working on Java: they could use a ClassLoader to dynamically >>>>> download the >>>>> >> vendor’s JAR from Gremlin Server into the client’s classpath. If >>>>> this >>>>> >> approach were adopted, the ClassLoading mechanism would need to >>>>> become a >>>>> >> formal part of the Gremlin Server protocol, as the vendor does not >>>>> control >>>>> >> the client at this stage. >>>>> >> >>>>> >> This dynamic approach could also address issues related to custom >>>>> >> serializers, though it would likely only be applicable to Java and >>>>> other >>>>> >> dynamic languages, and not to languages like Go. However, for >>>>> drivers such >>>>> >> as .NET, JavaScript, and Python, a similar level of abstraction >>>>> could >>>>> >> potentially be implemented within the protocol to achieve the same >>>>> result. >>>>> >> >>>>> >> Best regards, >>>>> >> >>>>> >> Andrii Lomakin >>>>> >> YouTrackDB development lead. >>>>> >> >>>>> >> On Thu, Nov 20, 2025 at 7:09 PM Ken Hu <[email protected]> wrote: >>>>> >> >>>>> >> > I think the initial challenge that I pointed out still exists, >>>>> which is, >>>>> >> > scripts and traversals won't have the same capabilities >>>>> out-of-the-box. >>>>> >> > Again, I'm in favor of this proposal and would like to see it >>>>> >> implemented. >>>>> >> > All I'm trying to say is, can we also come up with an equivalent >>>>> >> proposal >>>>> >> > for remote traversals. >>>>> >> > >>>>> >> > On Thu, Nov 20, 2025 at 5:18 AM Stephen Mallette < >>>>> [email protected]> >>>>> >> > wrote: >>>>> >> > >>>>> >> > > I think Ken provides a good point to consider about external >>>>> >> > dependencies. >>>>> >> > > Andrii, for further context, traditionally, we've found that >>>>> users >>>>> >> tend >>>>> >> > to >>>>> >> > > expect TinkerPop to just work with any provider. They want to >>>>> >> download a >>>>> >> > > driver in their programming language and get to work writing >>>>> their >>>>> >> > > applications. What they have found is that in some cases it's >>>>> not >>>>> >> quite >>>>> >> > as >>>>> >> > > easy as that. For example, Ken alludes to the serializers where >>>>> users >>>>> >> > often >>>>> >> > > learn in a very hard way that if they use JanusGraph they need >>>>> to add >>>>> >> in >>>>> >> > a >>>>> >> > > customer serializer for certain operations to work. We've made >>>>> it a >>>>> >> goal >>>>> >> > > for TinkerPop 4.x to not require TinkerPop drivers to have those >>>>> >> kinds of >>>>> >> > > dependencies that complicate the user experience. >>>>> >> > > >>>>> >> > > I think in this case, a DSL offers as a separate dependency by a >>>>> >> provider >>>>> >> > > doesn't exactly conflict with this goal because the DSL simply >>>>> >> enhances >>>>> >> > the >>>>> >> > > experience the user has, but doesn't require it for standard >>>>> TinkerPop >>>>> >> > > features to work. A user could even fallback to raw call() steps >>>>> >> without >>>>> >> > > using the DSL at all and still access the same functionality. >>>>> The DSL >>>>> >> is >>>>> >> > > merely a (highly useful) convenience in this case. Ken, do you >>>>> think >>>>> >> that >>>>> >> > > perspective helps align this idea to the goal of trying to keep >>>>> things >>>>> >> > > working out-of-the-box? >>>>> >> > > >>>>> >> > > On Wed, Nov 19, 2025 at 12:25 PM Ken Hu <[email protected]> >>>>> wrote: >>>>> >> > > >>>>> >> > > > That's not necessarily the case. If you think that there are >>>>> users >>>>> >> that >>>>> >> > > > don't mind doing that then it is fine. I've just seen >>>>> questions from >>>>> >> > > users >>>>> >> > > > in the past about how to make the GLV work with specific >>>>> providers >>>>> >> > > because >>>>> >> > > > they didn't realize they needed additional dependencies and >>>>> where to >>>>> >> > find >>>>> >> > > > those dependencies. I'm just wondering how and if it impacts >>>>> user >>>>> >> > > > experience. >>>>> >> > > > >>>>> >> > > > On Wed, Nov 19, 2025 at 9:18 AM Andrii Lomakin >>>>> >> > > > <[email protected]> wrote: >>>>> >> > > > >>>>> >> > > > > Is my understanding correct that you don't support this >>>>> change if >>>>> >> it >>>>> >> > > > > requires additional dependencies from vendor ? >>>>> >> > > > > >>>>> >> > > > > On Wed, 19 Nov 2025, 17:51 Ken Hu, <[email protected]> >>>>> wrote: >>>>> >> > > > > >>>>> >> > > > > > I don't think this proposal requires custom serializers. >>>>> I was >>>>> >> > trying >>>>> >> > > > to >>>>> >> > > > > > say that based on my understanding of this proposal, >>>>> there may >>>>> >> be >>>>> >> > an >>>>> >> > > > > issue >>>>> >> > > > > > that is similar to the one we see with custom >>>>> serializers. That >>>>> >> > issue >>>>> >> > > > > > being, how is this custom provider DSL packaged with the >>>>> GLV so >>>>> >> > that >>>>> >> > > > > users >>>>> >> > > > > > can gain access to those additional methods in remote >>>>> traversals >>>>> >> > > > without >>>>> >> > > > > > needing to add an additional dependency from the provider >>>>> >> itself? >>>>> >> > > > > > >>>>> >> > > > > > On Tue, Nov 18, 2025 at 10:46 PM Andrii Lomakin >>>>> >> > > > > > <[email protected]> wrote: >>>>> >> > > > > > >>>>> >> > > > > > > Good day, Ken. >>>>> >> > > > > > > >>>>> >> > > > > > > Could you clarify why you think that this proposal >>>>> requires >>>>> >> > custom >>>>> >> > > > > > > serializers? >>>>> >> > > > > > > >>>>> >> > > > > > > On Tue, Nov 18, 2025 at 11:39 PM Ken Hu < >>>>> [email protected]> >>>>> >> > > wrote: >>>>> >> > > > > > > >>>>> >> > > > > > > > I guess I'm still not certain how this DSL would get >>>>> >> packaged >>>>> >> > > with >>>>> >> > > > > the >>>>> >> > > > > > > > GLVs. One of the situations I'm trying to avoid is >>>>> the one >>>>> >> we >>>>> >> > > face >>>>> >> > > > > with >>>>> >> > > > > > > > custom type serialization. Providers with custom types >>>>> >> > generally >>>>> >> > > > need >>>>> >> > > > > > to >>>>> >> > > > > > > > package their serializers as a separate module which >>>>> users >>>>> >> of >>>>> >> > the >>>>> >> > > > GLV >>>>> >> > > > > > > will >>>>> >> > > > > > > > then add as a dependency. This creates confusion for >>>>> users >>>>> >> as >>>>> >> > > they >>>>> >> > > > > > aren't >>>>> >> > > > > > > > able to just use the GLV by itself. They need to grab >>>>> an >>>>> >> > > additional >>>>> >> > > > > > > > dependency from their provider as well. It isn't >>>>> always >>>>> >> clear >>>>> >> > to >>>>> >> > > > them >>>>> >> > > > > > > that >>>>> >> > > > > > > > this is the case. >>>>> >> > > > > > > > >>>>> >> > > > > > > > On Fri, Nov 14, 2025 at 10:04 AM Andrii Lomakin < >>>>> >> > > > > > > [email protected]> >>>>> >> > > > > > > > wrote: >>>>> >> > > > > > > > >>>>> >> > > > > > > > > Hi Ken, >>>>> >> > > > > > > > > >>>>> >> > > > > > > > > To clarify, the functionality you mentioned >>>>> regarding >>>>> >> remote >>>>> >> > > > > > Traversal >>>>> >> > > > > > > > > from a GLV is already fully supported by TinkerPop. >>>>> >> > > > > > > > > >>>>> >> > > > > > > > > While there are some current issues with the DSL >>>>> >> processor, >>>>> >> > > they >>>>> >> > > > > are >>>>> >> > > > > > > > > implementation details that we intend to resolve >>>>> through >>>>> >> the >>>>> >> > > > > > > > > contribution of our version of an annotation >>>>> processor, >>>>> >> which >>>>> >> > > > will >>>>> >> > > > > > not >>>>> >> > > > > > > > > require any changes to the TinkerPop documentation. >>>>> >> > > > > > > > > >>>>> >> > > > > > > > > For a concrete example of our implementation of DSL, >>>>> >> please >>>>> >> > see >>>>> >> > > > the >>>>> >> > > > > > > > > following: >>>>> >> > > > > > > > > >>>>> >> > > > > > > > > >>>>> >> > > > > > > > >>>>> >> > > > > > > >>>>> >> > > > > > >>>>> >> > > > > >>>>> >> > > > >>>>> >> > > >>>>> >> > >>>>> >> >>>>> https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalDSL.java >>>>> >> > > > > > > > > ( >>>>> >> > > > > > > > > >>>>> >> > > > > > > > >>>>> >> > > > > > > >>>>> >> > > > > > >>>>> >> > > > > >>>>> >> > > > >>>>> >> > > >>>>> >> > >>>>> >> >>>>> https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalDSL.java >>>>> >> > > > > > > > > ) >>>>> >> > > > > > > > > >>>>> >> > > > > > > > > Andrii Lomakin, >>>>> >> > > > > > > > > YouTrackDB development lead. >>>>> >> > > > > > > > > >>>>> >> > > > > > > > > On Fri, Nov 14, 2025 at 6:59 PM Andrii Lomakin < >>>>> >> > > > > > > [email protected] >>>>> >> > > > > > > > > >>>>> >> > > > > > > > > wrote: >>>>> >> > > > > > > > > > >>>>> >> > > > > > > > > > Hi Ken, >>>>> >> > > > > > > > > > >>>>> >> > > > > > > > > > The scenario you described regarding remote >>>>> Traversal >>>>> >> from >>>>> >> > a >>>>> >> > > > GLV >>>>> >> > > > > is >>>>> >> > > > > > > > > > automatically handled. >>>>> >> > > > > > > > > > >>>>> >> > > > > > > > > > The GLV would provide code similar to the existing >>>>> >> > > > implementation >>>>> >> > > > > > we >>>>> >> > > > > > > > > > already have, which can be found here: >>>>> >> > > > > > > > > > >>>>> >> > > > > > > > > >>>>> >> > > > > > > > >>>>> >> > > > > > > >>>>> >> > > > > > >>>>> >> > > > > >>>>> >> > > > >>>>> >> > > >>>>> >> > >>>>> >> >>>>> https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalSourceDSL.java#L95 >>>>> >> > > > > > > > > > >>>>> >> > > > > > > > > > Andrii Lomakin, >>>>> >> > > > > > > > > > YouTrackDB development lead. >>>>> >> > > > > > > > > > >>>>> >> > > > > > > > > > On Fri, Nov 14, 2025 at 6:40 PM Ken Hu < >>>>> >> [email protected] >>>>> >> > > >>>>> >> > > > > wrote: >>>>> >> > > > > > > > > > > >>>>> >> > > > > > > > > > > What does this mean if someone tries to send a >>>>> remote >>>>> >> > > > Traversal >>>>> >> > > > > > > from >>>>> >> > > > > > > > a >>>>> >> > > > > > > > > GLV? >>>>> >> > > > > > > > > > > I'm guessing that is what makes "1. Providing >>>>> DSL that >>>>> >> > does >>>>> >> > > > the >>>>> >> > > > > > > same >>>>> >> > > > > > > > > call" >>>>> >> > > > > > > > > > > necessary. I think that scripts and traversals >>>>> need to >>>>> >> > have >>>>> >> > > > the >>>>> >> > > > > > > same >>>>> >> > > > > > > > > > > capabilities "out of the box" when using the >>>>> GLVs. So >>>>> >> > > while I >>>>> >> > > > > > think >>>>> >> > > > > > > > > this is >>>>> >> > > > > > > > > > > a good idea, I would also like to see a >>>>> proposal on >>>>> >> what >>>>> >> > > can >>>>> >> > > > be >>>>> >> > > > > > > done >>>>> >> > > > > > > > > for >>>>> >> > > > > > > > > > > remote Traversals. >>>>> >> > > > > > > > > > > >>>>> >> > > > > > > > > > > On Thu, Nov 6, 2025 at 9:47 AM Andrea Child >>>>> >> > > > > > > > > > > <[email protected]> wrote: >>>>> >> > > > > > > > > > > >>>>> >> > > > > > > > > > > > Hi Andrii, >>>>> >> > > > > > > > > > > > >>>>> >> > > > > > > > > > > > I like your idea as it would improve >>>>> readability of >>>>> >> > > > > traversals >>>>> >> > > > > > to >>>>> >> > > > > > > > be >>>>> >> > > > > > > > > able >>>>> >> > > > > > > > > > > > to reference the service directly in the >>>>> grammar >>>>> >> > instead >>>>> >> > > of >>>>> >> > > > > via >>>>> >> > > > > > > the >>>>> >> > > > > > > > > call >>>>> >> > > > > > > > > > > > step. Looking forward to the contribution! >>>>> >> > > > > > > > > > > > >>>>> >> > > > > > > > > > > > Andrea >>>>> >> > > > > > > > > > > > >>>>> >> > > > > > > > > > > > From: Andrii Lomakin < >>>>> [email protected] >>>>> >> > > > .INVALID> >>>>> >> > > > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM >>>>> >> > > > > > > > > > > > To: [email protected] < >>>>> >> [email protected] >>>>> >> > > >>>>> >> > > > > > > > > > > > Subject: Proposal: Intorduction of equalence >>>>> between >>>>> >> > > > > > > > > call(serviceName, >>>>> >> > > > > > > > > > > > args:List) and method call in scripts >>>>> >> > > > > > > > > > > > >>>>> >> > > > > > > > > > > > Good day, colleagues. >>>>> >> > > > > > > > > > > > >>>>> >> > > > > > > > > > > > I would like to propose an approach to >>>>> enhancing the >>>>> >> > > > > > > extensibility >>>>> >> > > > > > > > > of the >>>>> >> > > > > > > > > > > > Gremlin script, which, although it does not >>>>> solve >>>>> >> all >>>>> >> > > > > problems, >>>>> >> > > > > > > > will >>>>> >> > > > > > > > > make >>>>> >> > > > > > > > > > > > many Gremlin extensions feel native. >>>>> >> > > > > > > > > > > > The Idea, as you may have already guessed >>>>> from the >>>>> >> > title, >>>>> >> > > > is >>>>> >> > > > > > > > simple: >>>>> >> > > > > > > > > if a >>>>> >> > > > > > > > > > > > service is registered in TinkerPop to treat >>>>> it as a >>>>> >> > > method >>>>> >> > > > > call >>>>> >> > > > > > > > with >>>>> >> > > > > > > > > > > > parameters, such as args: List<Object> as an >>>>> >> argument. >>>>> >> > > > > > > > > > > > >>>>> >> > > > > > > > > > > > So call like: g.schemClass("User") will be >>>>> >> translated >>>>> >> > to >>>>> >> > > > > > > > > > > > g.call("schemaClass", "args" : ["User]) >>>>> >> > > > > > > > > > > > >>>>> >> > > > > > > > > > > > In such a case, providers will extend Gremlin >>>>> >> twofold: >>>>> >> > > > > > > > > > > > 1. Providing DSL that does the same call. >>>>> >> > > > > > > > > > > > 2. Registering related service. >>>>> >> > > > > > > > > > > > >>>>> >> > > > > > > > > > > > If you agree with this proposal, I would be >>>>> glad to >>>>> >> > > > > contribute >>>>> >> > > > > > > it, >>>>> >> > > > > > > > > as I >>>>> >> > > > > > > > > > > > mentioned, it does not solve all issues, such >>>>> as the >>>>> >> > > usage >>>>> >> > > > of >>>>> >> > > > > > > > custom >>>>> >> > > > > > > > > > > > predicates, but I am under the impression >>>>> that it >>>>> >> can >>>>> >> > be >>>>> >> > > > > > extended >>>>> >> > > > > > > > to >>>>> >> > > > > > > > > that >>>>> >> > > > > > > > > > > > case too in the future. >>>>> >> > > > > > > > > > > > >>>>> >> > > > > > > > > >>>>> >> > > > > > > > >>>>> >> > > > > > > >>>>> >> > > > > > >>>>> >> > > > > >>>>> >> > > > >>>>> >> > > >>>>> >> > >>>>> >> >>>>> > >>>>> > >>>>> > -- >>>>> > Andrii Lomakin >>>>> > YouTrackDB development lead >>>>> > >>>>> >>>>> >>>>> -- >>>>> Andrii Lomakin >>>>> YouTrackDB development lead >>>>> >>>> >>> >>> -- >>> Andrii Lomakin >>> YouTrackDB development lead >>> >> >> >> -- >> Andrii Lomakin >> YouTrackDB development lead >> > -- Andrii Lomakin YouTrackDB development lead
