Re: [DISCUSS] Retiring Derby
On 23/09/2025 16:14, Zerro wrote: Maybe as one of the last users of Derby I can understand you stop with it. Setting the project into a read-only state sounds as a logical step. The sources will remain available I suppose. So what are others now using instead of Derby? And whatever happened to Derby being JavaDB, bundled with the JDK? -- John English -- This email has been checked for viruses by AVG antivirus software. www.avg.com
Re: [DISCUSS] Retiring Derby
Some responses inline... On 9/29/25 7:51 AM, fed wrote: Hi Rick, I'm currently using version 10.15.2.0 with Java 11 in production. Can this version also be considered stable and reliable like the 10.14.2.0 you mentioned? Yes, 10.15.2.0 is a stable release, meant to be run on JVMs which support the JPMS module system. Also, are Derby versions strictly tied to the JVM version for optimal performance? We started tying Derby versions to JVM levels with the 10.15 branch--because of the disruption caused by modularizing Derby. In the last decade, no changes have been made to Derby to take advantage of JVM performance improvements. Could I theoretically use 10.14.2.0 (which targets Java 8) with Java 11, or is it better to stick with 10.15.x which is specific for Java 9+? It might work. I don't remember testing that combination. It's simplest and safest to match Derby versions to the JVM levels recommended by https://db.apache.org/derby/derby_downloads.html. A major disruption occurred with Derby 10.16.1.1 due to the deprecation of the Java Security Manager. Thanks On Thu, 25 Sept 2025 at 01:04, Rick Hillegas wrote: Some comments inline... On 9/24/25 11:53 AM, Jerry Lampi wrote: We use Derby daily. Our customers use Derby daily. Our sentiments precisely match Roy Minet's: "Retiring Derby" sounds unnecessarily scary. What it means is ending further development and support, but Derby will continue to be alive, well, and available. Is that correct? The source code will still be available via subversion. The website will still be available, containing a wealth of information, including full documentation on all release families. The following resources, however, will disappear: o Apache-hosted Derby distributions will no longer be available. Nevertheless, I expect that distros will still be available from the maven artifactories. o Apache-hosted Derby mailing lists will no longer function, although their twenty-years of archives will still be browsable. Questions about Derby should be directed to general-purpose support forums. o There will no longer be an Apache-hosted mechanism for logging new bugs or bug fixes. However, old bug reports will still be browsable via read-only JIRA. I have used Derby for years and have yet to have any problems with it. I employ a good range of SQL capabilities, but try to avoid (what I would consider) excessive complexity. Derby is good and valuable software and I thank you profusely for it! I'm about five years behind (using 10.14.2.0), but have not so far been motivated to move to a latter version (if it ain't broke, don't fix it). Of course, there are alternatives to Derby as well, but I have not so far seen any reason to change. What I am most interested in is your advice for someone in my situation. 1. Stick with 10.14.2.0. It's possible that some change in a latter version could cause a problem. I would stick with 10.14.2.0 as long as you can remain on Java 8. I agree that there's no point in fixing something that already works well for you. When the time comes to upgrade to a later Java version, you can download the corresponding Derby version from the maven artifactories. In a pinch, you can always download the Derby source code from the appropriate subversion-managed release branch and build the jar files yourself. Each release branch describes the exact steps for doing this. 2. Move to (the apparently final version) 10.17.1.0 and "standardize" on that. There are some enhancements and bug fixes in there that I may encounter the need for in the future. The final version is the unreleased development mainline (10.18.0.0). I have successfully tested the development mainline against the latest LTS Java version (JDK 25, see https://issues.apache.org/jira/browse/DERBY-7175). Oracle has committed to maintaining Java 25 until 2033, according to https://www.oracle.com/java/technologies/java-se-support-roadmap.html 3. Move to one of the other embeddable RDBMS. (Which would you recommend?) I have no recommendation. We are eternally grateful to Rick, Bryan, and the Derby community. It's a wonderful piece of software. Thanks, much appreciated. Jerry Lampi From: Rick Hillegas Sent: Monday, September 22, 2025 12:26 PM To: [email protected] ; Derby Discussion Subject: [DISCUSS] Retiring Derby It has been almost two years since the Derby sub-project published a new version. I myself have no interest in managing another Derby release. Bryan is the only other active Derby committer. Bugs are reported occasionally but they are never fixed. Mailing-list activity consists almost entirely of spam rejects. No-one has volunteered to refresh the Derby website with the new Apache logo. I think that the time has come to retire Derby. As I understand it, this means putting Derby into a read-only state: o The Derby repository would become read-only. o Distributions would be removed from the Download t
Re: [DISCUSS] Retiring Derby
On 9/22/25 7:26 PM, Rick Hillegas wrote: It has been almost two years since the Derby sub-project published a new version. I myself have no interest in managing another Derby release. Bryan is the only other active Derby committer. Bugs are reported occasionally but they are never fixed. Mailing-list activity consists almost entirely of spam rejects. No-one has volunteered to refresh the Derby website with the new Apache logo. I think that the time has come to retire Derby. As I understand it, this means putting Derby into a read-only state: o The Derby repository would become read-only. o Distributions would be removed from the Download tab. o The developer and user lists would be closed down. Mailing list archives would still be browsable. o A prominent banner would be added to the Derby website landing page, stating that Derby was now retired and read-only. o The Derby website, JIRA, and wiki would be placed in read-only mode. Before calling a retirement vote, I would like to give the developer and user communities an opportunity to discuss this change. What are your thoughts? -Rick Maybe as one of the last users of Derby I can understand you stop with it. Setting the project into a read-only state sounds as a logical step. The sources will remain available I suppose. Kind regards, ~Zerro
Re: [DISCUSS] Retiring Derby
I have no statistics on Derby downloads. I think that most downloads today are from the maven artifactories. As far as I know, Derby distros will remain in the artifactories. There are no hard and fast rules about how often a project must produce a release. However, two years is a long time to go without a new version. The fact that bugs are not being fixed is more concerning to me. Thank you for your kind words. -Rick On 9/23/25 6:43 PM, bruehlicke wrote: Uh, scary news. I have not had the need to change the Derby I use and it has worked flawlessly since the one bug/show-stopper I found years ago with some triggers (and suggested a fix and got it committed) Any statistics around who might be using it or if there are active downloads ? I remember I was checking H2 back years ago and decided rather to use Derby. Hmm ... are there any mandatory requirements in the Apache world to have frequent releases causing the "need" to put it into retirement mode? Rick & Bryan you have had an enormous impact on that I could use this tool (even today) - Thank you ! Bernd On Mon, Sep 22, 2025 at 12:26 PM Rick Hillegas wrote: It has been almost two years since the Derby sub-project published a new version. I myself have no interest in managing another Derby release. Bryan is the only other active Derby committer. Bugs are reported occasionally but they are never fixed. Mailing-list activity consists almost entirely of spam rejects. No-one has volunteered to refresh the Derby website with the new Apache logo. I think that the time has come to retire Derby. As I understand it, this means putting Derby into a read-only state: o The Derby repository would become read-only. o Distributions would be removed from the Download tab. o The developer and user lists would be closed down. Mailing list archives would still be browsable. o A prominent banner would be added to the Derby website landing page, stating that Derby was now retired and read-only. o The Derby website, JIRA, and wiki would be placed in read-only mode. Before calling a retirement vote, I would like to give the developer and user communities an opportunity to discuss this change. What are your thoughts? -Rick
Re: [DISCUSS] Retiring Derby
> "Alex O'Ree" : > I've used derby as a fast alternative to sqlite and postgres. It's been a > reliable database over the years. Appreciate the hard work that went into > it. It's also useful for unit testing for when I don't want to spin up a > postgres image just for the tests. I'm using derby for unit tests and dummy data versions of my apps (and postgresql for production). I picked derby over h2 back in 2016, since everybody else seemed to be using h2 and since I knew people who had been working on derby.
Re: [DISCUSS] Retiring Derby
I just opened a discussion on ActiveMQ dev list. I would -1 on retiring it. I'm not active on this co0debase, and I wonder what would be required to keep it alive? I hope some other members from the ActiveMQ community could jump on this discussion as well. On Wed, Sep 24, 2025 at 3:01 PM Clebert Suconic wrote: > > I still use Derby as part of ActiveMQ Artemis, and also ActiveMQ > class, for our tests. > > As part of our testsuite, I need to validate our basic SQL interfaces > would work as required.. it has been a good tool for our testsuite. > > If you intend to retire Derby I wonder what I would use into our > testsuite validation though? > > > > On Wed, Sep 24, 2025 at 2:55 PM Jerry Lampi wrote: > > > > We use Derby daily. Our customers use Derby daily. > > Our sentiments precisely match Roy Minet's: > > > > "Retiring Derby" sounds unnecessarily scary. What it means is ending > > further development and support, but Derby will continue to be alive, well, > > and available. Is that correct? > > > > I have used Derby for years and have yet to have any problems with it. I > > employ a good range of SQL capabilities, but try to avoid (what I would > > consider) excessive complexity. Derby is good and valuable software and I > > thank you profusely for it! > > > > I'm about five years behind (using 10.14.2.0), but have not so far been > > motivated to move to a latter version (if it ain't broke, don't fix it). Of > > course, there are alternatives to Derby as well, but I have not so far seen > > any reason to change. What I am most interested in is your advice for > > someone in my situation. > > > > > > Stick with 10.14.2.0. It's possible that some change in a latter version > > could cause a problem. > > Move to (the apparently final version) 10.17.1.0 and "standardize" on that. > > There are some enhancements and bug fixes in there that I may encounter the > > need for in the future. > > Move to one of the other embeddable RDBMS. (Which would you recommend?) > > > > We are eternally grateful to Rick, Bryan, and the Derby community. It's a > > wonderful piece of software. > > > > Jerry Lampi > > > > > > From: Rick Hillegas > > Sent: Monday, September 22, 2025 12:26 PM > > To: [email protected] ; Derby Discussion > > > > Subject: [DISCUSS] Retiring Derby > > > > It has been almost two years since the Derby sub-project published a new > > version. I myself have no interest in managing another Derby release. > > Bryan is the only other active Derby committer. Bugs are reported > > occasionally but they are never fixed. Mailing-list activity consists > > almost entirely of spam rejects. No-one has volunteered to refresh the > > Derby website with the new Apache logo. > > > > I think that the time has come to retire Derby. As I understand it, this > > means putting Derby into a read-only state: > > > > o The Derby repository would become read-only. > > > > o Distributions would be removed from the Download tab. > > > > o The developer and user lists would be closed down. Mailing list > > archives would still be browsable. > > > > o A prominent banner would be added to the Derby website landing page, > > stating that Derby was now retired and read-only. > > > > o The Derby website, JIRA, and wiki would be placed in read-only mode. > > > > Before calling a retirement vote, I would like to give the developer and > > user communities an opportunity to discuss this change. > > > > What are your thoughts? > > > > -Rick > > > > > > > > > -- > Clebert Suconic -- Clebert Suconic
Re: [DISCUSS] Retiring Derby
"Retiring Derby" sounds unnecessarily scary. What it means is ending further development and support, but Derby will continue to be alive, well, and available. Is that correct? I have used Derby for years and have yet to have any problems with it. I employ a good range of SQL capabilities, but try to avoid (what I would consider) excessive complexity. Derby is good and valuable software and I thank you profusely for it! I'm about five years behind (using 10.14.2.0), but have not so far been motivated to move to a latter version (if it ain't broke, don't fix it). Of course, there are alternatives to Derby as well, but I have not so far seen any reason to change. What I am most interested in is your advice for someone in my situation. 1. Stick with 10.14.2.0. It's possible that some change in a latter version could cause a problem. 2. Move to (the apparently final version) 10.17.1.0 and "standardize" on that. There are some enhancements and bug fixes in there that I may encounter the need for in the future. 3. Move to one of the other embeddable RDBMS. (Which would you recommend?) Thank you for your advice and help over the years. Roy Minet > On 09/22/2025 1:26 PM EDT Rick Hillegas mailto:[email protected]> wrote: > > > It has been almost two years since the Derby sub-project published a new > version. I myself have no interest in managing another Derby release. > Bryan is the only other active Derby committer. Bugs are reported > occasionally but they are never fixed. Mailing-list activity consists > almost entirely of spam rejects. No-one has volunteered to refresh the > Derby website with the new Apache logo. > > I think that the time has come to retire Derby. As I understand it, this > means putting Derby into a read-only state: > > o The Derby repository would become read-only. > > o Distributions would be removed from the Download tab. > > o The developer and user lists would be closed down. Mailing list > archives would still be browsable. > > o A prominent banner would be added to the Derby website landing page, > stating that Derby was now retired and read-only. > > o The Derby website, JIRA, and wiki would be placed in read-only mode. > > Before calling a retirement vote, I would like to give the developer and > user communities an opportunity to discuss this change. > > What are your thoughts? > > -Rick >
Re: [DISCUSS] Retiring Derby
I've used derby as a fast alternative to sqlite and postgres. It's been a reliable database over the years. Appreciate the hard work that went into it. It's also useful for unit testing for when I don't want to spin up a postgres image just for the tests. On Tue, Sep 23, 2025, 1:03 PM John English wrote: > On 23/09/2025 16:14, Zerro wrote: > > Maybe as one of the last users of Derby I can understand you stop with > it. > > > > Setting the project into a read-only state sounds as a logical step. > > The sources will remain available I suppose. > > So what are others now using instead of Derby? > > And whatever happened to Derby being JavaDB, bundled with the JDK? > > -- > John English > > -- > This email has been checked for viruses by AVG antivirus software. > www.avg.com >
Re: [DISCUSS] Retiring Derby
Those are all fine alternatives. I suspect that if Derby worked well as a testbed for the last decade, it will continue to work well for the next decade, even without an active community behind it. On 9/24/25 2:44 PM, Clebert Suconic wrote: so, I spoke to folks on our slack channel for ActiveMQ. We use it for our testsute, and never in production... We can easily replace it by either dockerized databases (e.g Mysql or Oracle), or use HSQL / H2. We would be happy to use it if there's still a community around it, but if there's not enough community (devs) to keep the project going, we couldn't find anyone at ActiveMQ willing to maintain it. We will just watch this space and decide based on the outcome here. On Wed, Sep 24, 2025 at 3:05 PM Clebert Suconic wrote: I just opened a discussion on ActiveMQ dev list. I would -1 on retiring it. I'm not active on this co0debase, and I wonder what would be required to keep it alive? I hope some other members from the ActiveMQ community could jump on this discussion as well. On Wed, Sep 24, 2025 at 3:01 PM Clebert Suconic wrote: I still use Derby as part of ActiveMQ Artemis, and also ActiveMQ class, for our tests. As part of our testsuite, I need to validate our basic SQL interfaces would work as required.. it has been a good tool for our testsuite. If you intend to retire Derby I wonder what I would use into our testsuite validation though? On Wed, Sep 24, 2025 at 2:55 PM Jerry Lampi wrote: We use Derby daily. Our customers use Derby daily. Our sentiments precisely match Roy Minet's: "Retiring Derby" sounds unnecessarily scary. What it means is ending further development and support, but Derby will continue to be alive, well, and available. Is that correct? I have used Derby for years and have yet to have any problems with it. I employ a good range of SQL capabilities, but try to avoid (what I would consider) excessive complexity. Derby is good and valuable software and I thank you profusely for it! I'm about five years behind (using 10.14.2.0), but have not so far been motivated to move to a latter version (if it ain't broke, don't fix it). Of course, there are alternatives to Derby as well, but I have not so far seen any reason to change. What I am most interested in is your advice for someone in my situation. Stick with 10.14.2.0. It's possible that some change in a latter version could cause a problem. Move to (the apparently final version) 10.17.1.0 and "standardize" on that. There are some enhancements and bug fixes in there that I may encounter the need for in the future. Move to one of the other embeddable RDBMS. (Which would you recommend?) We are eternally grateful to Rick, Bryan, and the Derby community. It's a wonderful piece of software. Jerry Lampi From: Rick Hillegas Sent: Monday, September 22, 2025 12:26 PM To: [email protected] ; Derby Discussion Subject: [DISCUSS] Retiring Derby It has been almost two years since the Derby sub-project published a new version. I myself have no interest in managing another Derby release. Bryan is the only other active Derby committer. Bugs are reported occasionally but they are never fixed. Mailing-list activity consists almost entirely of spam rejects. No-one has volunteered to refresh the Derby website with the new Apache logo. I think that the time has come to retire Derby. As I understand it, this means putting Derby into a read-only state: o The Derby repository would become read-only. o Distributions would be removed from the Download tab. o The developer and user lists would be closed down. Mailing list archives would still be browsable. o A prominent banner would be added to the Derby website landing page, stating that Derby was now retired and read-only. o The Derby website, JIRA, and wiki would be placed in read-only mode. Before calling a retirement vote, I would like to give the developer and user communities an opportunity to discuss this change. What are your thoughts? -Rick -- Clebert Suconic -- Clebert Suconic
Re: [DISCUSS] Retiring Derby
> Jerry Lampi : > I have used Derby for years and have yet to have any problems with it. I > employ a good range of SQL capabilities, but try to avoid (what I would > consider) excessive complexity. Derby is good and valuable software and I > thank you profusely for it! I have had one issue with derby and that has been when using liquibase to set up schemas in memory databases a pax exam OSGi integration test. The lifecycle of objects in pax exam tests is... kinda weird. But it used to work up to a certain point. Now it works in some apps and not in others and sometimes spottily, even though the java code is basically the same for all of the tests. Only the schemas differ. Since the version of derby I'm using is the one used by pax-jdbc (10.14.2.0) and there didn't seem to be much development going on in derby I switched to file based h2 on the integration test of my liquibase-karaf-feature https://github.com/steinarb/liquibase-karaf-feature/blob/master/liquibase-integration-test/karaf.liquibase.sample/src/main/feature/feature.xml#L19
Re: [DISCUSS] Retiring Derby
Hi Rick, I'm currently using version 10.15.2.0 with Java 11 in production. Can this version also be considered stable and reliable like the 10.14.2.0 you mentioned? Also, are Derby versions strictly tied to the JVM version for optimal performance? Could I theoretically use 10.14.2.0 (which targets Java 8) with Java 11, or is it better to stick with 10.15.x which is specific for Java 9+? Thanks On Thu, 25 Sept 2025 at 01:04, Rick Hillegas wrote: > Some comments inline... > > On 9/24/25 11:53 AM, Jerry Lampi wrote: > > We use Derby daily. Our customers use Derby daily. > > Our sentiments precisely match Roy Minet's: > > "Retiring Derby" sounds unnecessarily scary. What it means is ending > further development and support, but Derby will continue to be alive, well, > and available. Is that correct? > > The source code will still be available via subversion. The website will > still be available, containing a wealth of information, including full > documentation on all release families. > > The following resources, however, will disappear: > > o Apache-hosted Derby distributions will no longer be available. > Nevertheless, I expect that distros will still be available from the > maven artifactories. > > o Apache-hosted Derby mailing lists will no longer function, although > their twenty-years of archives will still be browsable. Questions about > Derby should be directed to general-purpose support forums. > > o There will no longer be an Apache-hosted mechanism for logging new > bugs or bug fixes. However, old bug reports will still be browsable via > read-only JIRA. > > > > > I have used Derby for years and have yet to have any problems with it. I > employ a good range of SQL capabilities, but try to avoid (what I would > consider) excessive complexity. Derby is good and valuable software and I > thank you profusely for it! > > > > I'm about five years behind (using 10.14.2.0), but have not so far been > motivated to move to a latter version (if it ain't broke, don't fix it). Of > course, there are alternatives to Derby as well, but I have not so far seen > any reason to change. What I am most interested in is your advice for > someone in my situation. > > > > > >1. Stick with 10.14.2.0. It's possible that some change in a latter > version could cause a problem. > I would stick with 10.14.2.0 as long as you can remain on Java 8. I > agree that there's no point in fixing something that already works well > for you. When the time comes to upgrade to a later Java version, you can > download the corresponding Derby version from the maven artifactories. > In a pinch, you can always download the Derby source code from the > appropriate subversion-managed release branch and build the jar files > yourself. Each release branch describes the exact steps for doing this. > >2. Move to (the apparently final version) 10.17.1.0 and > "standardize" on that. There are some enhancements and bug fixes in there > that I may encounter the need for in the future. > The final version is the unreleased development mainline (10.18.0.0). I > have successfully tested the development mainline against the latest LTS > Java version (JDK 25, see > https://issues.apache.org/jira/browse/DERBY-7175). Oracle has committed > to maintaining Java 25 until 2033, according to > https://www.oracle.com/java/technologies/java-se-support-roadmap.html > >3. Move to one of the other embeddable RDBMS. (Which would you > recommend?) > I have no recommendation. > > > > We are eternally grateful to Rick, Bryan, and the Derby community. It's > a wonderful piece of software. > Thanks, much appreciated. > > > > Jerry Lampi > > > > > > From: Rick Hillegas > > Sent: Monday, September 22, 2025 12:26 PM > > To: [email protected] ; Derby Discussion > > > Subject: [DISCUSS] Retiring Derby > > > > It has been almost two years since the Derby sub-project published a new > > version. I myself have no interest in managing another Derby release. > > Bryan is the only other active Derby committer. Bugs are reported > > occasionally but they are never fixed. Mailing-list activity consists > > almost entirely of spam rejects. No-one has volunteered to refresh the > > Derby website with the new Apache logo. > > > > I think that the time has come to retire Derby. As I understand it, this > > means putting Derby into a read-only state: > > > > o The Derby repository would become read-only. > > > > o Distributions would be removed from the Download tab. > > > > o The developer and user lists would be closed down. Mailing list > > archives would still be browsable. > > > > o A prominent banner would be added to the Derby website landing page, > > stating that Derby was now retired and read-only. > > > > o The Derby website, JIRA, and wiki would be placed in read-only mode. > > > > Before calling a retirement vote, I would like to give the developer and > > user communities an opportunity to discuss this change. > > > >
Re: [DISCUSS] Retiring Derby
I've been using Derby for several years as the main database for one of my production projects, and I must say it has always proven to be reliable. I fully understand the situation described by Rick. Without active developers and with bugs remaining open, it's difficult to maintain the project. I hope retirement can be avoided, but I'm realistic: without a community ready to contribute concretely, it doesn't make much sense to continue. I hope the downloads will remain available at least on Maven Central. I will continue to use Derby - what's there works perfectly for my needs. In any case, I would like to thank Rick, Bryan, and all the contributors for the excellent work done over these years. - fed On Mon, 22 Sept 2025 at 19:26, Rick Hillegas wrote: > It has been almost two years since the Derby sub-project published a new > version. I myself have no interest in managing another Derby release. > Bryan is the only other active Derby committer. Bugs are reported > occasionally but they are never fixed. Mailing-list activity consists > almost entirely of spam rejects. No-one has volunteered to refresh the > Derby website with the new Apache logo. > > I think that the time has come to retire Derby. As I understand it, this > means putting Derby into a read-only state: > > o The Derby repository would become read-only. > > o Distributions would be removed from the Download tab. > > o The developer and user lists would be closed down. Mailing list > archives would still be browsable. > > o A prominent banner would be added to the Derby website landing page, > stating that Derby was now retired and read-only. > > o The Derby website, JIRA, and wiki would be placed in read-only mode. > > Before calling a retirement vote, I would like to give the developer and > user communities an opportunity to discuss this change. > > What are your thoughts? > > -Rick > > > >
Re: [DISCUSS] Retiring Derby
as to what ActiveMQ wants, I tried to get a consensus from people yesterday... and everybody I talked would be okay with moving to something else. from what I saw, keeping Derby alive would require some work done... the website is old, it sill using SVN (would be nice to use github, so people can send pull requests and maintain it). If you (Rich) and Bryan, or anyone else invovled don't have time to devote to that, and nobody to cover for it, we should probably look into replacing it. On Wed, Sep 24, 2025 at 7:46 PM Rick Hillegas wrote: > > Bryan and I are the last of the Derby developers. However, we no longer > fix bugs. Would ActiveMQ be comfortable if the Derby user list continued > to function and users could still log bugs via JIRA even though the > developer list shut down, distributions disappeared from the Derby > download tab, and it was understood that bugs would not be fixed? I > would be happy to continue to answer the occasional question on the user > list. > > On 9/24/25 4:13 PM, Rick Hillegas wrote: > > Those are all fine alternatives. > > > > I suspect that if Derby worked well as a testbed for the last decade, > > it will continue to work well for the next decade, even without an > > active community behind it. > > > > On 9/24/25 2:44 PM, Clebert Suconic wrote: > >> so, I spoke to folks on our slack channel for ActiveMQ. > >> > >> We use it for our testsute, and never in production... We can easily > >> replace it by either dockerized databases (e.g Mysql or Oracle), or > >> use HSQL / H2. > >> > >> We would be happy to use it if there's still a community around it, > >> but if there's not enough community (devs) to keep the project going, > >> we couldn't find anyone at ActiveMQ willing to maintain it. > >> > >> > >> We will just watch this space and decide based on the outcome here. > >> > >> On Wed, Sep 24, 2025 at 3:05 PM Clebert Suconic > >> wrote: > >>> I just opened a discussion on ActiveMQ dev list. I would -1 on > >>> retiring it. I'm not active on this co0debase, and I wonder what would > >>> be required to keep it alive? > >>> > >>> I hope some other members from the ActiveMQ community could jump on > >>> this discussion as well. > >>> > >>> On Wed, Sep 24, 2025 at 3:01 PM Clebert Suconic > >>> wrote: > I still use Derby as part of ActiveMQ Artemis, and also ActiveMQ > class, for our tests. > > As part of our testsuite, I need to validate our basic SQL interfaces > would work as required.. it has been a good tool for our testsuite. > > If you intend to retire Derby I wonder what I would use into our > testsuite validation though? > > > > On Wed, Sep 24, 2025 at 2:55 PM Jerry Lampi wrote: > > We use Derby daily. Our customers use Derby daily. > > Our sentiments precisely match Roy Minet's: > > > > "Retiring Derby" sounds unnecessarily scary. What it means is > > ending further development and support, but Derby will continue to > > be alive, well, and available. Is that correct? > > > > I have used Derby for years and have yet to have any problems with > > it. I employ a good range of SQL capabilities, but try to avoid > > (what I would consider) excessive complexity. Derby is good and > > valuable software and I thank you profusely for it! > > > > I'm about five years behind (using 10.14.2.0), but have not so far > > been motivated to move to a latter version (if it ain't broke, > > don't fix it). Of course, there are alternatives to Derby as well, > > but I have not so far seen any reason to change. What I am most > > interested in is your advice for someone in my situation. > > > > > > Stick with 10.14.2.0. It's possible that some change in a latter > > version could cause a problem. > > Move to (the apparently final version) 10.17.1.0 and "standardize" > > on that. There are some enhancements and bug fixes in there that I > > may encounter the need for in the future. > > Move to one of the other embeddable RDBMS. (Which would you > > recommend?) > > > > We are eternally grateful to Rick, Bryan, and the Derby community. > > It's a wonderful piece of software. > > > > Jerry Lampi > > > > > > From: Rick Hillegas > > Sent: Monday, September 22, 2025 12:26 PM > > To: [email protected] ; Derby > > Discussion > > Subject: [DISCUSS] Retiring Derby > > > > It has been almost two years since the Derby sub-project published > > a new > > version. I myself have no interest in managing another Derby release. > > Bryan is the only other active Derby committer. Bugs are reported > > occasionally but they are never fixed. Mailing-list activity consists > > almost entirely of spam rejects. No-one has volunteered to refresh > > the > > Derby website with the new Apache logo. > > > > I think th
Re: [DISCUSS] Retiring Derby
so, I spoke to folks on our slack channel for ActiveMQ. We use it for our testsute, and never in production... We can easily replace it by either dockerized databases (e.g Mysql or Oracle), or use HSQL / H2. We would be happy to use it if there's still a community around it, but if there's not enough community (devs) to keep the project going, we couldn't find anyone at ActiveMQ willing to maintain it. We will just watch this space and decide based on the outcome here. On Wed, Sep 24, 2025 at 3:05 PM Clebert Suconic wrote: > > I just opened a discussion on ActiveMQ dev list. I would -1 on > retiring it. I'm not active on this co0debase, and I wonder what would > be required to keep it alive? > > I hope some other members from the ActiveMQ community could jump on > this discussion as well. > > On Wed, Sep 24, 2025 at 3:01 PM Clebert Suconic > wrote: > > > > I still use Derby as part of ActiveMQ Artemis, and also ActiveMQ > > class, for our tests. > > > > As part of our testsuite, I need to validate our basic SQL interfaces > > would work as required.. it has been a good tool for our testsuite. > > > > If you intend to retire Derby I wonder what I would use into our > > testsuite validation though? > > > > > > > > On Wed, Sep 24, 2025 at 2:55 PM Jerry Lampi wrote: > > > > > > We use Derby daily. Our customers use Derby daily. > > > Our sentiments precisely match Roy Minet's: > > > > > > "Retiring Derby" sounds unnecessarily scary. What it means is ending > > > further development and support, but Derby will continue to be alive, > > > well, and available. Is that correct? > > > > > > I have used Derby for years and have yet to have any problems with it. I > > > employ a good range of SQL capabilities, but try to avoid (what I would > > > consider) excessive complexity. Derby is good and valuable software and I > > > thank you profusely for it! > > > > > > I'm about five years behind (using 10.14.2.0), but have not so far been > > > motivated to move to a latter version (if it ain't broke, don't fix it). > > > Of course, there are alternatives to Derby as well, but I have not so far > > > seen any reason to change. What I am most interested in is your advice > > > for someone in my situation. > > > > > > > > > Stick with 10.14.2.0. It's possible that some change in a latter version > > > could cause a problem. > > > Move to (the apparently final version) 10.17.1.0 and "standardize" on > > > that. There are some enhancements and bug fixes in there that I may > > > encounter the need for in the future. > > > Move to one of the other embeddable RDBMS. (Which would you recommend?) > > > > > > We are eternally grateful to Rick, Bryan, and the Derby community. It's a > > > wonderful piece of software. > > > > > > Jerry Lampi > > > > > > > > > From: Rick Hillegas > > > Sent: Monday, September 22, 2025 12:26 PM > > > To: [email protected] ; Derby Discussion > > > > > > Subject: [DISCUSS] Retiring Derby > > > > > > It has been almost two years since the Derby sub-project published a new > > > version. I myself have no interest in managing another Derby release. > > > Bryan is the only other active Derby committer. Bugs are reported > > > occasionally but they are never fixed. Mailing-list activity consists > > > almost entirely of spam rejects. No-one has volunteered to refresh the > > > Derby website with the new Apache logo. > > > > > > I think that the time has come to retire Derby. As I understand it, this > > > means putting Derby into a read-only state: > > > > > > o The Derby repository would become read-only. > > > > > > o Distributions would be removed from the Download tab. > > > > > > o The developer and user lists would be closed down. Mailing list > > > archives would still be browsable. > > > > > > o A prominent banner would be added to the Derby website landing page, > > > stating that Derby was now retired and read-only. > > > > > > o The Derby website, JIRA, and wiki would be placed in read-only mode. > > > > > > Before calling a retirement vote, I would like to give the developer and > > > user communities an opportunity to discuss this change. > > > > > > What are your thoughts? > > > > > > -Rick > > > > > > > > > > > > > > > -- > > Clebert Suconic > > > > -- > Clebert Suconic -- Clebert Suconic
Re: [DISCUSS] Retiring Derby
Uh, scary news. I have not had the need to change the Derby I use and it has worked flawlessly since the one bug/show-stopper I found years ago with some triggers (and suggested a fix and got it committed) Any statistics around who might be using it or if there are active downloads ? I remember I was checking H2 back years ago and decided rather to use Derby. Hmm ... are there any mandatory requirements in the Apache world to have frequent releases causing the "need" to put it into retirement mode? Rick & Bryan you have had an enormous impact on that I could use this tool (even today) - Thank you ! Bernd On Mon, Sep 22, 2025 at 12:26 PM Rick Hillegas wrote: > It has been almost two years since the Derby sub-project published a new > version. I myself have no interest in managing another Derby release. > Bryan is the only other active Derby committer. Bugs are reported > occasionally but they are never fixed. Mailing-list activity consists > almost entirely of spam rejects. No-one has volunteered to refresh the > Derby website with the new Apache logo. > > I think that the time has come to retire Derby. As I understand it, this > means putting Derby into a read-only state: > > o The Derby repository would become read-only. > > o Distributions would be removed from the Download tab. > > o The developer and user lists would be closed down. Mailing list > archives would still be browsable. > > o A prominent banner would be added to the Derby website landing page, > stating that Derby was now retired and read-only. > > o The Derby website, JIRA, and wiki would be placed in read-only mode. > > Before calling a retirement vote, I would like to give the developer and > user communities an opportunity to discuss this change. > > What are your thoughts? > > -Rick > > > >
Re: [DISCUSS] Retiring Derby
We've used Derby for years as a part of an open source project. It's been great and we've been able to work around the few issues that have arisen. We will likely continue to use it for the immediate future, even once it is retired. Thanks to everyone who has worked on this project over the years! Emily On 2025-09-22 10:26 a.m., Rick Hillegas wrote: It has been almost two years since the Derby sub-project published a new version. I myself have no interest in managing another Derby release. Bryan is the only other active Derby committer. Bugs are reported occasionally but they are never fixed. Mailing-list activity consists almost entirely of spam rejects. No-one has volunteered to refresh the Derby website with the new Apache logo. I think that the time has come to retire Derby. As I understand it, this means putting Derby into a read-only state: o The Derby repository would become read-only. o Distributions would be removed from the Download tab. o The developer and user lists would be closed down. Mailing list archives would still be browsable. o A prominent banner would be added to the Derby website landing page, stating that Derby was now retired and read-only. o The Derby website, JIRA, and wiki would be placed in read-only mode. Before calling a retirement vote, I would like to give the developer and user communities an opportunity to discuss this change. What are your thoughts? -Rick
Re: [DISCUSS] Retiring Derby
Whether or not the lights are turned out, I just want to crow about the great software that I was able to use back when I was using it and the super support this channel provided me at the time. Rest in peace, Derby, or live on: you are great stuff and a great idea! On 9/25/25 08:40, bruehlicke wrote: At a mature stage in which Derby is, the best and cheapest option would be to update the website (whatever that really means) and make sure the build works and hence drop a new release once every N years - even if only 1 thing is changed - might just be documentation. Not sure what steps there are involved to create a release. For sure keep it in SVN at this late stage. As Rick states the current repository is "10.18.0.0" which could be good for a long time to come. I only had the need to build Derby once when I needed to check my bug fix for the TriggerDescriptor lazy initialization and lucky Bryan was so nice to check the diff file and run the test suite that all works. (10.12.1.1). Maybe I am just getting sentimental, I will for sure keep using it and hope I never run into a showstopper which I cannot fix myself. On Thu, Sep 25, 2025 at 8:24 AM Clebert Suconic wrote: as to what ActiveMQ wants, I tried to get a consensus from people yesterday... and everybody I talked would be okay with moving to something else. from what I saw, keeping Derby alive would require some work done... the website is old, it sill using SVN (would be nice to use github, so people can send pull requests and maintain it). If you (Rich) and Bryan, or anyone else invovled don't have time to devote to that, and nobody to cover for it, we should probably look into replacing it. On Wed, Sep 24, 2025 at 7:46 PM Rick Hillegas wrote: > > Bryan and I are the last of the Derby developers. However, we no longer > fix bugs. Would ActiveMQ be comfortable if the Derby user list continued > to function and users could still log bugs via JIRA even though the > developer list shut down, distributions disappeared from the Derby > download tab, and it was understood that bugs would not be fixed? I > would be happy to continue to answer the occasional question on the user > list. > > On 9/24/25 4:13 PM, Rick Hillegas wrote: > > Those are all fine alternatives. > > > > I suspect that if Derby worked well as a testbed for the last decade, > > it will continue to work well for the next decade, even without an > > active community behind it. > > > > On 9/24/25 2:44 PM, Clebert Suconic wrote: > >> so, I spoke to folks on our slack channel for ActiveMQ. > >> > >> We use it for our testsute, and never in production... We can easily > >> replace it by either dockerized databases (e.g Mysql or Oracle), or > >> use HSQL / H2. > >> > >> We would be happy to use it if there's still a community around it, > >> but if there's not enough community (devs) to keep the project going, > >> we couldn't find anyone at ActiveMQ willing to maintain it. > >> > >> > >> We will just watch this space and decide based on the outcome here. > >> > >> On Wed, Sep 24, 2025 at 3:05 PM Clebert Suconic > >> wrote: > >>> I just opened a discussion on ActiveMQ dev list. I would -1 on > >>> retiring it. I'm not active on this co0debase, and I wonder what would > >>> be required to keep it alive? > >>> > >>> I hope some other members from the ActiveMQ community could jump on > >>> this discussion as well. > >>> > >>> On Wed, Sep 24, 2025 at 3:01 PM Clebert Suconic > >>> wrote: > I still use Derby as part of ActiveMQ Artemis, and also ActiveMQ > class, for our tests. > > As part of our testsuite, I need to validate our basic SQL interfaces > would work as required.. it has been a good tool for our testsuite. > > If you intend to retire Derby I wonder what I would use into our > testsuite validation though? > > > > On Wed, Sep 24, 2025 at 2:55 PM Jerry Lampi wrote: > > We use Derby daily. Our customers use Derby daily. > > Our sentiments precisely match Roy Minet's: > > > > "Retiring Derby" sounds unnecessarily scary. What it means is > > ending further development and support, but Derby will continue to > > be alive, well, and available. Is that correct? > > > > I have used Derby for years and have yet to have any problems with > > it. I employ a good range of SQL capabilities, but try to avoid > > (what I would consider) excessive complexity. Derby is good and > > valuable software and I thank you profusely for it! > > > > I'm about five years behind (using 10.14.2.0)
Re: [DISCUSS] Retiring Derby
Thanks for that feedback. On 9/25/25 6:24 AM, Clebert Suconic wrote: as to what ActiveMQ wants, I tried to get a consensus from people yesterday... and everybody I talked would be okay with moving to something else. from what I saw, keeping Derby alive would require some work done... the website is old, it sill using SVN (would be nice to use github, so people can send pull requests and maintain it). If you (Rich) and Bryan, or anyone else invovled don't have time to devote to that, and nobody to cover for it, we should probably look into replacing it. On Wed, Sep 24, 2025 at 7:46 PM Rick Hillegas wrote: Bryan and I are the last of the Derby developers. However, we no longer fix bugs. Would ActiveMQ be comfortable if the Derby user list continued to function and users could still log bugs via JIRA even though the developer list shut down, distributions disappeared from the Derby download tab, and it was understood that bugs would not be fixed? I would be happy to continue to answer the occasional question on the user list. On 9/24/25 4:13 PM, Rick Hillegas wrote: Those are all fine alternatives. I suspect that if Derby worked well as a testbed for the last decade, it will continue to work well for the next decade, even without an active community behind it. On 9/24/25 2:44 PM, Clebert Suconic wrote: so, I spoke to folks on our slack channel for ActiveMQ. We use it for our testsute, and never in production... We can easily replace it by either dockerized databases (e.g Mysql or Oracle), or use HSQL / H2. We would be happy to use it if there's still a community around it, but if there's not enough community (devs) to keep the project going, we couldn't find anyone at ActiveMQ willing to maintain it. We will just watch this space and decide based on the outcome here. On Wed, Sep 24, 2025 at 3:05 PM Clebert Suconic wrote: I just opened a discussion on ActiveMQ dev list. I would -1 on retiring it. I'm not active on this co0debase, and I wonder what would be required to keep it alive? I hope some other members from the ActiveMQ community could jump on this discussion as well. On Wed, Sep 24, 2025 at 3:01 PM Clebert Suconic wrote: I still use Derby as part of ActiveMQ Artemis, and also ActiveMQ class, for our tests. As part of our testsuite, I need to validate our basic SQL interfaces would work as required.. it has been a good tool for our testsuite. If you intend to retire Derby I wonder what I would use into our testsuite validation though? On Wed, Sep 24, 2025 at 2:55 PM Jerry Lampi wrote: We use Derby daily. Our customers use Derby daily. Our sentiments precisely match Roy Minet's: "Retiring Derby" sounds unnecessarily scary. What it means is ending further development and support, but Derby will continue to be alive, well, and available. Is that correct? I have used Derby for years and have yet to have any problems with it. I employ a good range of SQL capabilities, but try to avoid (what I would consider) excessive complexity. Derby is good and valuable software and I thank you profusely for it! I'm about five years behind (using 10.14.2.0), but have not so far been motivated to move to a latter version (if it ain't broke, don't fix it). Of course, there are alternatives to Derby as well, but I have not so far seen any reason to change. What I am most interested in is your advice for someone in my situation. Stick with 10.14.2.0. It's possible that some change in a latter version could cause a problem. Move to (the apparently final version) 10.17.1.0 and "standardize" on that. There are some enhancements and bug fixes in there that I may encounter the need for in the future. Move to one of the other embeddable RDBMS. (Which would you recommend?) We are eternally grateful to Rick, Bryan, and the Derby community. It's a wonderful piece of software. Jerry Lampi From: Rick Hillegas Sent: Monday, September 22, 2025 12:26 PM To: [email protected] ; Derby Discussion Subject: [DISCUSS] Retiring Derby It has been almost two years since the Derby sub-project published a new version. I myself have no interest in managing another Derby release. Bryan is the only other active Derby committer. Bugs are reported occasionally but they are never fixed. Mailing-list activity consists almost entirely of spam rejects. No-one has volunteered to refresh the Derby website with the new Apache logo. I think that the time has come to retire Derby. As I understand it, this means putting Derby into a read-only state: o The Derby repository would become read-only. o Distributions would be removed from the Download tab. o The developer and user lists would be closed down. Mailing list archives would still be browsable. o A prominent banner would be added to the Derby website landing page, stating that Derby was now retired and read-only. o The Derby website, JIRA, and wiki would be placed in read-only mode. Before calling a retirement vote, I would
Re: [DISCUSS] Retiring Derby
At a mature stage in which Derby is, the best and cheapest option would be to update the website (whatever that really means) and make sure the build works and hence drop a new release once every N years - even if only 1 thing is changed - might just be documentation. Not sure what steps there are involved to create a release. For sure keep it in SVN at this late stage. As Rick states the current repository is "10.18.0.0" which could be good for a long time to come. I only had the need to build Derby once when I needed to check my bug fix for the TriggerDescriptor lazy initialization and lucky Bryan was so nice to check the diff file and run the test suite that all works. (10.12.1.1). Maybe I am just getting sentimental, I will for sure keep using it and hope I never run into a showstopper which I cannot fix myself. On Thu, Sep 25, 2025 at 8:24 AM Clebert Suconic wrote: > as to what ActiveMQ wants, I tried to get a consensus from people > yesterday... and everybody I talked would be okay with moving to > something else. > > from what I saw, keeping Derby alive would require some work done... > the website is old, it sill using SVN (would be nice to use github, so > people can send pull requests and maintain it). > > If you (Rich) and Bryan, or anyone else invovled don't have time to > devote to that, and nobody to cover for it, we should probably look > into replacing it. > > On Wed, Sep 24, 2025 at 7:46 PM Rick Hillegas > wrote: > > > > Bryan and I are the last of the Derby developers. However, we no longer > > fix bugs. Would ActiveMQ be comfortable if the Derby user list continued > > to function and users could still log bugs via JIRA even though the > > developer list shut down, distributions disappeared from the Derby > > download tab, and it was understood that bugs would not be fixed? I > > would be happy to continue to answer the occasional question on the user > > list. > > > > On 9/24/25 4:13 PM, Rick Hillegas wrote: > > > Those are all fine alternatives. > > > > > > I suspect that if Derby worked well as a testbed for the last decade, > > > it will continue to work well for the next decade, even without an > > > active community behind it. > > > > > > On 9/24/25 2:44 PM, Clebert Suconic wrote: > > >> so, I spoke to folks on our slack channel for ActiveMQ. > > >> > > >> We use it for our testsute, and never in production... We can easily > > >> replace it by either dockerized databases (e.g Mysql or Oracle), or > > >> use HSQL / H2. > > >> > > >> We would be happy to use it if there's still a community around it, > > >> but if there's not enough community (devs) to keep the project going, > > >> we couldn't find anyone at ActiveMQ willing to maintain it. > > >> > > >> > > >> We will just watch this space and decide based on the outcome here. > > >> > > >> On Wed, Sep 24, 2025 at 3:05 PM Clebert Suconic > > >> wrote: > > >>> I just opened a discussion on ActiveMQ dev list. I would -1 on > > >>> retiring it. I'm not active on this co0debase, and I wonder what > would > > >>> be required to keep it alive? > > >>> > > >>> I hope some other members from the ActiveMQ community could jump on > > >>> this discussion as well. > > >>> > > >>> On Wed, Sep 24, 2025 at 3:01 PM Clebert Suconic > > >>> wrote: > > I still use Derby as part of ActiveMQ Artemis, and also ActiveMQ > > class, for our tests. > > > > As part of our testsuite, I need to validate our basic SQL > interfaces > > would work as required.. it has been a good tool for our testsuite. > > > > If you intend to retire Derby I wonder what I would use into our > > testsuite validation though? > > > > > > > > On Wed, Sep 24, 2025 at 2:55 PM Jerry Lampi wrote: > > > We use Derby daily. Our customers use Derby daily. > > > Our sentiments precisely match Roy Minet's: > > > > > > "Retiring Derby" sounds unnecessarily scary. What it means is > > > ending further development and support, but Derby will continue to > > > be alive, well, and available. Is that correct? > > > > > > I have used Derby for years and have yet to have any problems with > > > it. I employ a good range of SQL capabilities, but try to avoid > > > (what I would consider) excessive complexity. Derby is good and > > > valuable software and I thank you profusely for it! > > > > > > I'm about five years behind (using 10.14.2.0), but have not so far > > > been motivated to move to a latter version (if it ain't broke, > > > don't fix it). Of course, there are alternatives to Derby as well, > > > but I have not so far seen any reason to change. What I am most > > > interested in is your advice for someone in my situation. > > > > > > > > > Stick with 10.14.2.0. It's possible that some change in a latter > > > version could cause a problem. > > > Move to (the apparently final version) 10.17.1.0 and "standardize" > > > on that. There
Re: [DISCUSS] Retiring Derby
Bryan and I are the last of the Derby developers. However, we no longer fix bugs. Would ActiveMQ be comfortable if the Derby user list continued to function and users could still log bugs via JIRA even though the developer list shut down, distributions disappeared from the Derby download tab, and it was understood that bugs would not be fixed? I would be happy to continue to answer the occasional question on the user list. On 9/24/25 4:13 PM, Rick Hillegas wrote: Those are all fine alternatives. I suspect that if Derby worked well as a testbed for the last decade, it will continue to work well for the next decade, even without an active community behind it. On 9/24/25 2:44 PM, Clebert Suconic wrote: so, I spoke to folks on our slack channel for ActiveMQ. We use it for our testsute, and never in production... We can easily replace it by either dockerized databases (e.g Mysql or Oracle), or use HSQL / H2. We would be happy to use it if there's still a community around it, but if there's not enough community (devs) to keep the project going, we couldn't find anyone at ActiveMQ willing to maintain it. We will just watch this space and decide based on the outcome here. On Wed, Sep 24, 2025 at 3:05 PM Clebert Suconic wrote: I just opened a discussion on ActiveMQ dev list. I would -1 on retiring it. I'm not active on this co0debase, and I wonder what would be required to keep it alive? I hope some other members from the ActiveMQ community could jump on this discussion as well. On Wed, Sep 24, 2025 at 3:01 PM Clebert Suconic wrote: I still use Derby as part of ActiveMQ Artemis, and also ActiveMQ class, for our tests. As part of our testsuite, I need to validate our basic SQL interfaces would work as required.. it has been a good tool for our testsuite. If you intend to retire Derby I wonder what I would use into our testsuite validation though? On Wed, Sep 24, 2025 at 2:55 PM Jerry Lampi wrote: We use Derby daily. Our customers use Derby daily. Our sentiments precisely match Roy Minet's: "Retiring Derby" sounds unnecessarily scary. What it means is ending further development and support, but Derby will continue to be alive, well, and available. Is that correct? I have used Derby for years and have yet to have any problems with it. I employ a good range of SQL capabilities, but try to avoid (what I would consider) excessive complexity. Derby is good and valuable software and I thank you profusely for it! I'm about five years behind (using 10.14.2.0), but have not so far been motivated to move to a latter version (if it ain't broke, don't fix it). Of course, there are alternatives to Derby as well, but I have not so far seen any reason to change. What I am most interested in is your advice for someone in my situation. Stick with 10.14.2.0. It's possible that some change in a latter version could cause a problem. Move to (the apparently final version) 10.17.1.0 and "standardize" on that. There are some enhancements and bug fixes in there that I may encounter the need for in the future. Move to one of the other embeddable RDBMS. (Which would you recommend?) We are eternally grateful to Rick, Bryan, and the Derby community. It's a wonderful piece of software. Jerry Lampi From: Rick Hillegas Sent: Monday, September 22, 2025 12:26 PM To: [email protected] ; Derby Discussion Subject: [DISCUSS] Retiring Derby It has been almost two years since the Derby sub-project published a new version. I myself have no interest in managing another Derby release. Bryan is the only other active Derby committer. Bugs are reported occasionally but they are never fixed. Mailing-list activity consists almost entirely of spam rejects. No-one has volunteered to refresh the Derby website with the new Apache logo. I think that the time has come to retire Derby. As I understand it, this means putting Derby into a read-only state: o The Derby repository would become read-only. o Distributions would be removed from the Download tab. o The developer and user lists would be closed down. Mailing list archives would still be browsable. o A prominent banner would be added to the Derby website landing page, stating that Derby was now retired and read-only. o The Derby website, JIRA, and wiki would be placed in read-only mode. Before calling a retirement vote, I would like to give the developer and user communities an opportunity to discuss this change. What are your thoughts? -Rick -- Clebert Suconic -- Clebert Suconic
Re: [DISCUSS] Retiring Derby
Some comments inline... On 9/24/25 11:53 AM, Jerry Lampi wrote: We use Derby daily. Our customers use Derby daily. Our sentiments precisely match Roy Minet's: "Retiring Derby" sounds unnecessarily scary. What it means is ending further development and support, but Derby will continue to be alive, well, and available. Is that correct? The source code will still be available via subversion. The website will still be available, containing a wealth of information, including full documentation on all release families. The following resources, however, will disappear: o Apache-hosted Derby distributions will no longer be available. Nevertheless, I expect that distros will still be available from the maven artifactories. o Apache-hosted Derby mailing lists will no longer function, although their twenty-years of archives will still be browsable. Questions about Derby should be directed to general-purpose support forums. o There will no longer be an Apache-hosted mechanism for logging new bugs or bug fixes. However, old bug reports will still be browsable via read-only JIRA. I have used Derby for years and have yet to have any problems with it. I employ a good range of SQL capabilities, but try to avoid (what I would consider) excessive complexity. Derby is good and valuable software and I thank you profusely for it! I'm about five years behind (using 10.14.2.0), but have not so far been motivated to move to a latter version (if it ain't broke, don't fix it). Of course, there are alternatives to Derby as well, but I have not so far seen any reason to change. What I am most interested in is your advice for someone in my situation. 1. Stick with 10.14.2.0. It's possible that some change in a latter version could cause a problem. I would stick with 10.14.2.0 as long as you can remain on Java 8. I agree that there's no point in fixing something that already works well for you. When the time comes to upgrade to a later Java version, you can download the corresponding Derby version from the maven artifactories. In a pinch, you can always download the Derby source code from the appropriate subversion-managed release branch and build the jar files yourself. Each release branch describes the exact steps for doing this. 2. Move to (the apparently final version) 10.17.1.0 and "standardize" on that. There are some enhancements and bug fixes in there that I may encounter the need for in the future. The final version is the unreleased development mainline (10.18.0.0). I have successfully tested the development mainline against the latest LTS Java version (JDK 25, see https://issues.apache.org/jira/browse/DERBY-7175). Oracle has committed to maintaining Java 25 until 2033, according to https://www.oracle.com/java/technologies/java-se-support-roadmap.html 3. Move to one of the other embeddable RDBMS. (Which would you recommend?) I have no recommendation. We are eternally grateful to Rick, Bryan, and the Derby community. It's a wonderful piece of software. Thanks, much appreciated. Jerry Lampi From: Rick Hillegas Sent: Monday, September 22, 2025 12:26 PM To: [email protected] ; Derby Discussion Subject: [DISCUSS] Retiring Derby It has been almost two years since the Derby sub-project published a new version. I myself have no interest in managing another Derby release. Bryan is the only other active Derby committer. Bugs are reported occasionally but they are never fixed. Mailing-list activity consists almost entirely of spam rejects. No-one has volunteered to refresh the Derby website with the new Apache logo. I think that the time has come to retire Derby. As I understand it, this means putting Derby into a read-only state: o The Derby repository would become read-only. o Distributions would be removed from the Download tab. o The developer and user lists would be closed down. Mailing list archives would still be browsable. o A prominent banner would be added to the Derby website landing page, stating that Derby was now retired and read-only. o The Derby website, JIRA, and wiki would be placed in read-only mode. Before calling a retirement vote, I would like to give the developer and user communities an opportunity to discuss this change. What are your thoughts? -Rick
Re: [DISCUSS] Retiring Derby
I still use Derby as part of ActiveMQ Artemis, and also ActiveMQ class, for our tests. As part of our testsuite, I need to validate our basic SQL interfaces would work as required.. it has been a good tool for our testsuite. If you intend to retire Derby I wonder what I would use into our testsuite validation though? On Wed, Sep 24, 2025 at 2:55 PM Jerry Lampi wrote: > > We use Derby daily. Our customers use Derby daily. > Our sentiments precisely match Roy Minet's: > > "Retiring Derby" sounds unnecessarily scary. What it means is ending further > development and support, but Derby will continue to be alive, well, and > available. Is that correct? > > I have used Derby for years and have yet to have any problems with it. I > employ a good range of SQL capabilities, but try to avoid (what I would > consider) excessive complexity. Derby is good and valuable software and I > thank you profusely for it! > > I'm about five years behind (using 10.14.2.0), but have not so far been > motivated to move to a latter version (if it ain't broke, don't fix it). Of > course, there are alternatives to Derby as well, but I have not so far seen > any reason to change. What I am most interested in is your advice for someone > in my situation. > > > Stick with 10.14.2.0. It's possible that some change in a latter version > could cause a problem. > Move to (the apparently final version) 10.17.1.0 and "standardize" on that. > There are some enhancements and bug fixes in there that I may encounter the > need for in the future. > Move to one of the other embeddable RDBMS. (Which would you recommend?) > > We are eternally grateful to Rick, Bryan, and the Derby community. It's a > wonderful piece of software. > > Jerry Lampi > > > From: Rick Hillegas > Sent: Monday, September 22, 2025 12:26 PM > To: [email protected] ; Derby Discussion > > Subject: [DISCUSS] Retiring Derby > > It has been almost two years since the Derby sub-project published a new > version. I myself have no interest in managing another Derby release. > Bryan is the only other active Derby committer. Bugs are reported > occasionally but they are never fixed. Mailing-list activity consists > almost entirely of spam rejects. No-one has volunteered to refresh the > Derby website with the new Apache logo. > > I think that the time has come to retire Derby. As I understand it, this > means putting Derby into a read-only state: > > o The Derby repository would become read-only. > > o Distributions would be removed from the Download tab. > > o The developer and user lists would be closed down. Mailing list > archives would still be browsable. > > o A prominent banner would be added to the Derby website landing page, > stating that Derby was now retired and read-only. > > o The Derby website, JIRA, and wiki would be placed in read-only mode. > > Before calling a retirement vote, I would like to give the developer and > user communities an opportunity to discuss this change. > > What are your thoughts? > > -Rick > > > -- Clebert Suconic
Re: [DISCUSS] Retiring Derby
We use Derby daily. Our customers use Derby daily. Our sentiments precisely match Roy Minet's: "Retiring Derby" sounds unnecessarily scary. What it means is ending further development and support, but Derby will continue to be alive, well, and available. Is that correct? I have used Derby for years and have yet to have any problems with it. I employ a good range of SQL capabilities, but try to avoid (what I would consider) excessive complexity. Derby is good and valuable software and I thank you profusely for it! I'm about five years behind (using 10.14.2.0), but have not so far been motivated to move to a latter version (if it ain't broke, don't fix it). Of course, there are alternatives to Derby as well, but I have not so far seen any reason to change. What I am most interested in is your advice for someone in my situation. 1. Stick with 10.14.2.0. It's possible that some change in a latter version could cause a problem. 2. Move to (the apparently final version) 10.17.1.0 and "standardize" on that. There are some enhancements and bug fixes in there that I may encounter the need for in the future. 3. Move to one of the other embeddable RDBMS. (Which would you recommend?) We are eternally grateful to Rick, Bryan, and the Derby community. It's a wonderful piece of software. Jerry Lampi From: Rick Hillegas Sent: Monday, September 22, 2025 12:26 PM To: [email protected] ; Derby Discussion Subject: [DISCUSS] Retiring Derby It has been almost two years since the Derby sub-project published a new version. I myself have no interest in managing another Derby release. Bryan is the only other active Derby committer. Bugs are reported occasionally but they are never fixed. Mailing-list activity consists almost entirely of spam rejects. No-one has volunteered to refresh the Derby website with the new Apache logo. I think that the time has come to retire Derby. As I understand it, this means putting Derby into a read-only state: o The Derby repository would become read-only. o Distributions would be removed from the Download tab. o The developer and user lists would be closed down. Mailing list archives would still be browsable. o A prominent banner would be added to the Derby website landing page, stating that Derby was now retired and read-only. o The Derby website, JIRA, and wiki would be placed in read-only mode. Before calling a retirement vote, I would like to give the developer and user communities an opportunity to discuss this change. What are your thoughts? -Rick
RE: [DISCUSS] Retiring Derby
Goodbye, Derby. I will miss you. We used to be such close friends, but we kind of lost touch the last couple of years since I semi-retired. Thanks to Rick and the gang for such a great product. _ John I. Moore, Jr. -Original Message- From: John English Sent: Wednesday, September 24, 2025 9:13 AM To: Rick Hillegas ; Derby Discussion Subject: Re: [DISCUSS] Retiring Derby On 24/09/2025 01:59, Rick Hillegas wrote: > Java 8 was the last Oracle LTS release which bundled Derby as JavaDB. > Later on, JavaDB was removed from Oracle Java 8 and Java 7 according > to this page: https://www.oracle.com/java/technologies/javadb.html > MySQL became Oracle's preferred open source database. Amazing, considering what a pile of crap MySQL is: complicated to configure, lacking in features... I use Derby on several long-running projects and will continue to do so, whatever happens. It's simple, reliable, has a full set of SQL features, and supports Java functions for useful extensions (e.g. string matching uses regexes, special-purpose formatting, ...). Perfect, from my pov. Oh well. Sic transit gloria Derby. So long, and thanks for all the fish... -- John English -- This email has been checked for viruses by AVG antivirus software. www.avg.com
Re: [DISCUSS] Retiring Derby
On 24/09/2025 01:59, Rick Hillegas wrote: Java 8 was the last Oracle LTS release which bundled Derby as JavaDB. Later on, JavaDB was removed from Oracle Java 8 and Java 7 according to this page: https://www.oracle.com/java/technologies/javadb.html MySQL became Oracle's preferred open source database. Amazing, considering what a pile of crap MySQL is: complicated to configure, lacking in features... I use Derby on several long-running projects and will continue to do so, whatever happens. It's simple, reliable, has a full set of SQL features, and supports Java functions for useful extensions (e.g. string matching uses regexes, special-purpose formatting, ...). Perfect, from my pov. Oh well. Sic transit gloria Derby. So long, and thanks for all the fish... -- John English -- This email has been checked for viruses by AVG antivirus software. www.avg.com
Re: [DISCUSS] Retiring Derby
Java 8 was the last Oracle LTS release which bundled Derby as JavaDB. Later on, JavaDB was removed from Oracle Java 8 and Java 7 according to this page: https://www.oracle.com/java/technologies/javadb.html MySQL became Oracle's preferred open source database. Oracle is now winding down its support for MySQL, according to https://www.theregister.com/2025/09/11/oracle_slammed_for_mysql_job/ On 9/23/25 10:03 AM, John English wrote: On 23/09/2025 16:14, Zerro wrote: Maybe as one of the last users of Derby I can understand you stop with it. Setting the project into a read-only state sounds as a logical step. The sources will remain available I suppose. So what are others now using instead of Derby? And whatever happened to Derby being JavaDB, bundled with the JDK?
Re: [DISCUSS] Retiring Derby
I used Derby quite a bit during development stage. Probably it can now be repurposed for some AI use case. Thanks, Sandeep > On Sep 23, 2025, at 1:06 PM, John English wrote: > > On 22/09/2025 20:26, Rick Hillegas wrote: >> It has been almost two years since the Derby sub-project published a new >> version. I myself have no interest in managing another Derby release. Bryan >> is the only other active Derby committer. Bugs are reported occasionally but >> they are never fixed. Mailing-list activity consists almost entirely of spam >> rejects. No-one has volunteered to refresh the Derby website with the new >> Apache logo. > > Maybe Derby is just so wonderful that no one has any problems with it > anymore... ;) > > -- > John English > > -- > This email has been checked for viruses by AVG antivirus software. > www.avg.com
Re: [DISCUSS] Retiring Derby
On 22/09/2025 20:26, Rick Hillegas wrote: It has been almost two years since the Derby sub-project published a new version. I myself have no interest in managing another Derby release. Bryan is the only other active Derby committer. Bugs are reported occasionally but they are never fixed. Mailing-list activity consists almost entirely of spam rejects. No-one has volunteered to refresh the Derby website with the new Apache logo. Maybe Derby is just so wonderful that no one has any problems with it anymore... ;) -- John English -- This email has been checked for viruses by AVG antivirus software. www.avg.com
