Update site for 4.30 release updates, as Java 21 support gets improved

[kriegaex]

Please refer to the thread starting with this message on the mailing list. @laeubi recommended to continue the discussion here. Here is a quote of the essential parts of the discussion so far:

@kriegaex wrote:
Lately, I refreshed AspectJ from commit 23b713c (date 2023-12-01), because I wanted to get the latest compiler changes, as string templates for J21 were merged in just before only briefly after the 2023-12 release. Then, I had to refactor a few classes using StringBuffer instead of the now new StringBuilder. I did that and was able to build AspectJ successfully. All tests are passing, version 1.9.21 was releasaed today.

BUT...

Now I was trying to update AJDT, and it is not working, because the 4.30 release https://download.eclipse.org/eclipse/updates/4.30/R-4.30-202312010110/plugins/ obviously contains an older version of org.eclipse.jdt.core.compiler.batch_3.36.0.v20231114-0937.jar from mid November, which still uses StringBuffer. Therefore, I cannot get this working. The Tycho build uses https://download.eclipse.org/releases/2023-12/ as a download source.

Can anyone tell me when on that download site there will be an up-to-date version of JDT Core plugins?

@iloveeclipse wrote:
See for example https://download.eclipse.org/eclipse/downloads/drops4/I20231207-1800/.

@kriegaex wrote:
As we speak, I am trying to build from https://download.eclipse.org/eclipse/updates/4.31-I-builds/I20231201-1800/, because probably that is the closest to 4.30 I can get. But even if that build works, I am afraid that AJDT is not going to work with the 4.30 release. Therefore, my question was about whether there is an update channel for 4.30 rather than a 4.31-I build. I.e., the question again is when 4.30 users will see a compatible JDT Core update by simply clicking
"update" or waiting for auto-update in Eclipse.

@kriegaex wrote:
I think that 4.30 users will be eager to get release updates related to Java 21, not just string templates but later also the still unmerged unnamed classes and unnamed patterns/variables. I.e., the question about 4.30 maintenance updates is still valid.

[kriegaex]

FYI, I added an extra note to the AspectJ IDE guide, urging AJDT users to also add update site 4.31-I-builds/I20231201-1800 to their IDE configuration, which is really unfortunate, but probably necessary, because the API changes in JDT Core so shortly after the 4.30 release are mixed with the Java 21 language feature improvements.

[trancexpress]

There are no maintenance branches anymore (there have been none for quite a while, with rare exceptions).

If you are asking for JDT updates that are guaranteed to work on Eclipse 4.30, its unlikely there will be any. JDT is developed to work against latest Eclipse. If users require latest JDT changes, its best that they download the latest Eclipse release. Trying to use newer JDT on an older Eclipse might work here and there, but this is by chance. There is no process that guarantees the updates will work. There were the maintenance branches before, where bug fixes were backported (but not features).

A while ago @iloveeclipse asked if there is any interest in his maintenance branches for Advantest, but there wasnt any: https://www.eclipse.org/lists/platform-releng-dev/msg36062.html

Sorry if I misunderstood your question.

[kriegaex]

@trancexpress, thanks, now I have a clear answer. Please correct me if I am wrong, but what this basically means is: If there is any known bug in Eclipse 4.n in general or maybe an unfinished Java feature in JDT Core, then users will inevitably have to wait for the 4.(n+1) release, hoping that there the bug will be fixed and no new ones will be introduced. Or of course, they can always go bleeding edge and use I-builds for the next release.

Good to know. 🤔

P.S.: I wonder how all the enterprise users handle this situation. From my customers I know, that most of them use one Eclipse version for a while and only try to add bug fixes or plugin updates, if any compatible ones exist. Looks like JDT Core is out of scope there, and they will have to upgrade to a new SimRel to get the missing Java 21 features still under development.

[laeubi]

From my customers I know, that most of them use one Eclipse version for a while and only try to add bug fixes or plugin updates, if any compatible ones exist. Looks like JDT Core is out of scope there, and they will have to upgrade to a new SimRel to get the missing Java 21 features still under development.

These customers can either:

1. Join the JDT development and help in maintaining backports / branches / build pipelines and release engineering work
2. Fork the repository and do it on their own

That's how open source works... you can't expect others to do the work for you for free just because it would be useful for them.

[kriegaex]

@laeubi, I am not expecting anything, I am asking questions and commenting on the replies. There is absolutely no need to lecture me about how OSS development works or what you are expecting customers to do. Actually, as a (currently) solo maintainer of a sibling Eclipse project, I might also explain the resource situation to my customers, but I would never lecture them like that, saying the same old "if you want a feature, feel free to develop it yourself, it is OSS" sentence. That does not make it happen. The rest is prioritisation.

But basically, this is exactly what I am doing: I do work for free for others, many of whom use it commercially, either in AspectJ directly or indirectly via Spring. Am I hoping to be rewarded for my volunteer work by someone either donating money or hiring me as an expert consultant for the product I am maintaining? Yes, sure. But I am also doing the work, if that does not happen. Call me stupid. My money comes from my feelance agile coaching work, but sometimes I like to relax my mind by writing a program or two. And then, I give it away for free. If I was more religious, maybe I would believe in collecting good karma or something similar. Actually, I do not. It just makes me feel good to create something or help other people.

[laeubi]

@kriegaex I don't want to lecture you or any of your customers, I just wanted to "correct" you (in a non offending way) as you asked here:

Please correct me if I am wrong, but what this basically means is: If there is any known bug in Eclipse 4.n in general or maybe an unfinished Java feature in JDT Core, then users will inevitably have to wait for the 4.(n+1) release, hoping that there the bug will be fixed and no new ones will be introduced. Or of course, they can always go bleeding edge and use I-builds for the next release.

So to summarize I think these "abstract customers" has not only the options you mentioned they have at least the option:

1. wait for the 4.(n+1) release (I'll leave out the "hoping" part as it effectively boils down to the same that is participating in OSS, e.g as in 2. , 3. , 4.)
2. use I-builds (for the compiler there are sometimes snapshot releases as well) helping iron out bugs before they get released
3. help in performing the steps in JDT project itself (maybe by paying you to do the work)
4. do it on an own fork (maybe by paying you to do the work)
5. hope you want earn additional karma (maybe by 3. or 4.)

[kriegaex]

We are not just talking about bugs here. The context was and still is JDK 21 support in the JDT Core, which two releases (2023-09, 2023-12) after JDK 21 GA is still feature-incomplete. I think, that would justify maintenance releases. Fixed bugs could also be backported along the way.

BTW, just because you do not know your own or my customers, it does not mean they are abstract and need to be double-quoted. And just because software is free, it does not mean that customers ought not be taken seriously. I sued enterprise customers as an example here, if you have carefully read my messages. The main reason is that as a sibling Eclipse project maintainer depending on JDT Core, I asked a question about product maintenance, the answer of which heavily influences my work. I just pointed out, that me being the one asking the question here, does not mean that I am the only one affected.

[trancexpress]

For platform and JDT there are no maintenance releases or update sites, so yes. Only moving to the next release, or using integration builds.

Its of course also possible to do all that work personally, backport changes in a fork and build from the aggregator repository. I.e. what Andrey is doing. Though realistically no user will do this.

Its also unlikely this will change in the future. The release cadence was upped to deal with upped Java release cadence, from then onward I believe maintenance branches became too much effort.

[jarthana]

Actually, in the past we have done this - i.e. update the update site when we fixed some critical bug. So, it's not really a big deal. But just not sure if the beta branch is in good shape to be able to back-port only the relevant fixes.

[kriegaex]

@jarthana, in my case, I even used commits from the main branch, not from a beta branch. They were committed (or maybe merged from somewhere) shortly after release 4.30, immediately breaking backward compatibility with same release, forcing me to tell users to upgrade their IDEs to a specific I-build. See above. You can see, how probbably only adventurous single users will agree to do that, probably no enterprise users, because they would have to convince their admins to add an I-build update site.

If new features or fixes for JDK 21 are added to a Java 22 beta branch - did I understand correctly? - I can see why back-porting might be a bit more expensive than putting those changes on a maintenance branch in the first place and merging that one forward into the new beta branch regularly instead. Merging forward is ususally easier that doing two types of work in a single, new branch and then (cherry-) picking the work apart after the fact, back-porting part of it.