Hi, Definitely a possibility. Or we could keep the official image on Java 11 to be conservative, and at the same time publish some variants of our own under the apache namespace:
apache/solr:9.0.0-jre17 apache/solr:9.0.0-jdk17 apache/solr:9.0.0-jre11 apache/solr:9.0.0-jdk11 I don' tknow if we need different Dockerfile.body templates for the variants or if they could be built with just different build-args for FROM? Actually, it would be nice if we could publish all our images under apache name-space, and then have docker folks symlink /_/solr to these like they do for elastic. It would give us more freedom with advanced multi step builds and smaller images. But I think that door is closed now. Jan > 6. jan. 2022 kl. 22:03 skrev David Smiley <[email protected]>: > > I'd like to propose that our Docker image for Solr 9 move from Java 11 to > Java 17. Admittedly I don't have any familiarity with running 17, so I would > really like to hear from those of you using it. I'm guessing (informed from > some quick google searches) there are some ~minor performance improvements > but nothing eye-popping there. Mostly, I propose this because a 9.0 release > is an ideal time to make such a change instead of some minor release in > between that could introduce a subtle surprise for some users. The new > Shenandoah GC looks exciting but may not be sufficiently ready for us to > recommend (if I recall from a recent user who reported a problem with it) -- > and that's okay. Having this as an option for users is great, especially as > time progresses and future Docker Solr releases include minor updates to the > JVM base image that will increase the viability. > > I'm aware our nifty image building enables people to do a custom build to > specify their own preferred FROM image, which is cool. Still, I think we > should move on to 17 as the default. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > <http://www.linkedin.com/in/davidwsmiley>
