| Hi Andreas,
For Elasticsearch things I thought I would deprecate all public methods that accept code that is in the elasticsearch namespace. My goal there is to migrate to a new client.
Should probably do something similar to HttpClient.
I just published a milestone build of 5.3.0. Maybe it’s time to merge develop into main, and keep working on 5.3.0 on the main branch. That way we can move the develop branch to 6.0.0 and starts making breaking changes so we see what needs to be deprecated. Håvard On 22 Dec 2025, at 11:38, Andreas Schwarte via rdf4j-dev <rdf4j-dev@xxxxxxxxxxx> wrote:
Hi all, thanks Havard for planning ahead. Java 25 makes sense also from my side.
Looking ahead at the next major release, do we also need to formally deprecate some of the HTTP client related interfaces and methods (with the idea of using a new HTTP client facade allowing for different client implementations)?
For example: org.eclipse.rdf4j.http.client.HttpClientDependent, org.eclipse.rdf4j.http.client.HttpClientSessionManager and some aspects of org.eclipse.rdf4j.http.client.SPARQLProtocolSession?
How could a deprecation look like?
Thanks, Andreas Am Di., 16. Dez. 2025 um 11:33 Uhr schrieb Jerven Tjalling Bolleman via rdf4j-dev < rdf4j-dev@xxxxxxxxxxx>: Hi All,
I concur with the wish to move to Java25.
I also wish to pick up the vectorized binding sets etc. as well as
improving the placement regarding where the bindingsets are created
(moving from the QueryContext to the prior QueryEvaluationSteps).
Another subtle change is that I wish that we had a single UNDEF value to
avoid the difficulty between figuring out if a null means empty or
undef. Which can lead to subtle issues and makes the bindingsets bigger
than they need to be.
Also if we find that during the development of 6 we find we need to
deprecate more I would not there being a 5.4.0 with just more
deprecation notices.
Next to the SOLR store deprecation, I personally would not mind
deprecating the elasticsearch-store as well, and the original mapdb
implementation.
Regards,
Jerven
On 12/16/25 11:06, Piotr Sowiński via rdf4j-dev wrote:
> Hi,
>
> I'm very much in favor of moving on to RDF4J 6 right after 5.3.
>
> For RDF4J 6 my first wish is to upgrade to as new JDK version as
> possible (preferably 25), to allow us to use the many new Java features
> to further improve performance.
>
> I would also suggest to consider if any changes to public APIs in the
> query engine are needed (around BindingSets) to support processing
> queries with lower overhead (e.g., raw value IDs), or with batches of
> bindings (vectorized).
> We could also reconsider mutability of some classes in the engine (e.g.,
> values, statements, binding sets). Moving to immutable records today
> could already offer small performance improvements. But more
> importantly, this would be a first step to supporting Valhalla value
> classes, when they finally are released.
> I think some time ago there was some work in the engine to support
> iterations with a specific order, but this is still experimental – this
> could be taken further, perhaps?
>
> On Mon, 15 Dec 2025 at 22:22, Håvard Ottestad via rdf4j-dev <rdf4j-
> dev@xxxxxxxxxxx <mailto:rdf4j-dev@xxxxxxxxxxx>> wrote:
>
> Hi everyone!
>
> I’m wondering what people think about having 5.3.0 be the last minor
> release of RDF4J and move to 6.0.0 on the develop branch after that?
>
> Anything we want to remove in 6.0.0 needs to be deprecated in 5.3.0.
> I’m going to deprecate the entire Solr sail for removal because Solr
> is very far behind on updates and will hold us back from updating to
> the latest Lucene and Jakarta EE versions.
>
> I’ve release 5.2.2 today and plan to publish a milestone build of
> 5.3.0 as soon as I can.
>
> Cheers,
> Håvard
>
>
>
>
> _______________________________________________
> rdf4j-dev mailing list
> rdf4j-dev@xxxxxxxxxxx <mailto:rdf4j-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit https://www.eclipse.org/
> mailman/listinfo/rdf4j-dev <https://www.eclipse.org/mailman/
> listinfo/rdf4j-dev>
>
>
>
> --
> Piotr Sowiński
> CTO & Co-Founder @ NeverBlink
> https://neverblink.eu <https://neverblink.eu>
>
> _______________________________________________
> rdf4j-dev mailing list
> rdf4j-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/rdf4j-dev
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/rdf4j-dev
|
