On 09/02/17 04:02, Peter Ansell wrote:
Not all fluent configuration APIs are "builder patterns". By that I
mean that you can have a "return this" convention for the builder with
mutable fields without it building or cloning new objects.
A builder pattern is characterised by a terminal method r
On 9 February 2017 at 13:38, Stian Soiland-Reyes wrote:
> Peter Ansell raised a valid question about why in Commons RDF I made the
> RDFParser interface as an immutable factory-like builder pattern.
>
> https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/experimental/RDFPa
Come to think of it, clone() is going to make a shallow copy anyways, so
any RDFParser fields here wouldn't get copied between clones, just
references.
On 9 February 2017 at 03:44, sebb wrote:
> I've not looked at the code itself yet, but AFAIK clone() is not
> sufficient to ensure thread-safety
I've not looked at the code itself yet, but AFAIK clone() is not
sufficient to ensure thread-safety of a mutable object.
This is a consequence of the Java memory model, which allows items to
be cached locally.
Simply put, safe publication of values requires that the reader of a
field synchronise o
Looking more closely, why not use CompleteableFuture instead of Future
since this is Java 8?
Also, the gist of the configuration API you're looking for sounds like a
way to emulate closures in Java. :)
You could also add a freeze method to switch between mutable and immutable
views of the factory
I'm not familiar with the code, but it sounds like you're in the early
stages of a plugin system. The good old BeanFactory.
Another possible way to go about untying thread safe and not thread safe
parser factory builders would be using naming conventions like setters for
mutable and withers for im
On Wed, Feb 8, 2017 at 7:27 PM, Matt Sicker wrote:
> I've always considered builders to be mutable, thread unsafe objects used
> to create immutable, thread safe objects.
+1
Gary
> If these builders cause GC
> pressure to go too high, then I'd turn to object pooling or per-thread
> reusable
Not all fluent configuration APIs are "builder patterns". By that I
mean that you can have a "return this" convention for the builder with
mutable fields without it building or cloning new objects.
A builder pattern is characterised by a terminal method returning a
new instance of an object, avoid
I've always considered builders to be mutable, thread unsafe objects used
to create immutable, thread safe objects. If these builders cause GC
pressure to go too high, then I'd turn to object pooling or per-thread
reusable objects depending on how the code is used.
On 8 February 2017 at 20:38, Sti
Peter Ansell raised a valid question about why in Commons RDF I made the
RDFParser interface as an immutable factory-like builder pattern.
https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/experimental/RDFParser.html
Here is how it can be used today:
RDF rdf = new J
10 matches
Mail list logo
