Hi all, If that’s an option … possibly considering an even bigger jump to 21 might be good.
17 had quite some language-level improvements, however with 21 the virtual threads came into play (In a useable way). Especially when working with multiple worker threads I see this has quite a positive impact on performance. Chris Von: Yuan Tian <[email protected]> Datum: Mittwoch, 1. April 2026 um 10:38 An: [email protected] <[email protected]> Betreff: Re: [DISCUSS] Singleton-Free IoTDB? Java 17? Jakarta? Hi Chris, I agree. Perhaps we could have Pengcheng collect information on our users' current deployment environments to see if upgrading to JDK 17 is feasible for them at this stage. Based on that feedback, we can then use various community channels to announce that IoTDB will phase out support for JVM environments below JDK 17 in a future release (e.g., version 2.0.12 and 1.4.0). Then we can do that change in our master branch. Best regards, Yuan Tian On Wed, Apr 1, 2026 at 1:42 PM Christofer Dutz <[email protected]> wrote: > Hi all, > > So how could this be brought back upstream? > It would be a breaking change. > > Chris > > Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Wang Critas <[email protected]> > Sent: Wednesday, April 1, 2026 5:10:30 AM > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS] Singleton-Free IoTDB? Java 17? Jakarta? > > Hi Chris > Cool ,I also copied a version at that time, hoping it would be helpful > https://github.com/apache/iotdb/pull/15239 > > Xuan Wang > > 发件人: Christofer Dutz <[email protected]> > 日期: 星期三, 2026年4月1日 00:18 > 收件人: [email protected] <[email protected]> > 主题: AW: [DISCUSS] Singleton-Free IoTDB? Java 17? Jakarta? > > Hi Yuan, > > Well, the first 3 segments I already have running … I’m working on the > „removal of sigletons“ … and yes … that’s a huge undertaking ;-) > > I didn’t look too deeply into the current state of IoTDB as when I last > worked for Timecho, I kept on being worried about datanode becoming fatter > and fatter. > If now all is externalized as modules, that makes my life easier. > > And yes … in most deployments I worked on (Deploying IoTDB to Ignition and > CtrlX) I didn’t like that the ConfigNode and DataNode were running in the > same VM but still using Network communication to communicate with each > other … Serializing, sending, parsing in both directions. I wanted to > update IoTDB do do direct inner-vm calls but whenever I brought this up in > the past, it was discarded as not being needed. > > I can whip up a PR, that handles the Java 17 and Jakarta update. > > Chris > > > Von: Yuan Tian <[email protected]> > Datum: Dienstag, 31. März 2026 um 02:55 > An: [email protected] <[email protected]> > Betreff: Re: [DISCUSS] Singleton-Free IoTDB? Java 17? Jakarta? > > Hi Chris, > > Personally, I am in favor of the following points: > > - > > Bumping the base Java version to Java 17 > - > > Switching from the JavaX to the Jakarta namespace > - > > Switching to the develop branch > > However, regarding the switch from Singletons to Dependency Injection, I > feel this would be a massive undertaking. We currently rely on a large > number of singletons, and refactoring all of them would consume a > significant amount of the community's energy while bringing relatively > limited benefits. > > Regarding *replacing the MQTT support with one based on an MQTT client > rather than a Broker*: I don't think a direct replacement is necessary. The > current MQTT implementation is already decoupled as an independent plugin. > You could implement your client-based approach as a new plugin under the > external-service package, and we could simply let users choose which MQTT > implementation they want to use via configuration. > > As for *stripping the DataNode into its bare essentials*: Have you outlined > what constitutes these "bare essentials"? In my view, apart from the code > related to Pipe and Subscription, the rest of the current DataNode > essentially belongs to the core read/write functionalities, especially > since protocol layers like MQTT and REST have already been extracted. > > Regarding *allowing inner-VM communication between ConfigNode and > DataNode*: > Actually, I have a similar plan to develop an embedded version of IoTDB > called embedded-iotdb (conceptually similar to SQLite). This plan involves > completely removing Thrift and ratis (which would make embedded-iotdb much > leaner) and replacing the communication between CN and DN with direct > function calls. I wonder if your goal aligns with this plan? > > Best regards, > > --------------------- > > Yuan Tian > > On Fri, Mar 27, 2026 at 4:18 PM Christofer Dutz <[email protected] > > > wrote: > > > Hi all, > > > > As you know, I have brought up several topics repeatedly over the last > few > > years. > > Things that I personally require to continue using IoTDB. > > > > > > * > > Living the base-java-version to Java 17 > > * > > Switching from JavaX to Jakarta namespace > > * > > Switching from Singletons to Dependency Injection (Spring) > > * > > Developing on „develop“ and not „master“ (We voted for that years ago but > > never did the switch) > > > > As recently all of them have been denied or ignored, I have created a > > personal fork where I applied these changes. > > > > So now I’m asking … is there interest in this from side of the Project? > If > > yes, I’m happy to whip up a PR (Even if it’s most probably a HUGE one). > If > > not, I’ll probably keep on working on my fork and keeping it closed but > > stop going the extra mile for making it able to go back into IoTDB and > > fully go nuts about it, forming it fully into what I would like it to be > > like. > > > > > > * > > Replacing the MQTT support with one based on an MQTT client and not an > > MQTT Broker. > > * > > Stripping DataNode into it’s bare essentials > > * > > Moving all current DataNode extensions into separate plugins. > > * > > Allowing inner-VM communication between config- and data-node. > > > > Chris > > >
