About thread safety, I was mostly interested in yes or no, though the details
are neat. We have annotations for that so that users know which classes are
applicable to different situations.
Guava seems to be more of a giant toolbox than an easily embedded library like
things at Commons, so I
Hi Matt and community,
About thread safety: I keep an int counting modifications (called
modCount). Now, spliterator/iterator/sublist check that modCount ==
expectedModCount, and if that is not the case, throws
ConcurrentModificationException. Basically, it resembles the fail-fast
behavior of
Hello,
I agree that this looks interesting. I personally would like to see
the following before weighing in on whether or not to include it in
commons:
1. A list of use cases where this data structure would be potentially
more performant or useful than existing data structures.
2. A set of
I'm glad I asked this question :-) Bruno actually submitted a PR with
support for both the old and new namespaces [1] but we decided not to
go with it since it felt like too much to support both versions of the
API. However, this discussion is making me rethink that choice. For
one, dropping
On Sat, Jun 11, 2022, 18:02 Gilles Sadowski wrote:
> I have a hard time figuring out whether these bits of code are
> intended to become the application developer API...
> What data-structure(s) will be visible (from the application)?
> What will be hidden ("implementation details")?
>
Hello,
Good discussion here! This is great!
I lost track of what the overall goal here is while reading through
the conversation. The goal of NUMBERS-186 is to "allow operations to
be performed on lists of complex numbers". My first thought when
looking at this is "how are we going to represent
No objections from me. I'm +1 to normally killing old code too, but I think
in this case it might be simple to keep both working in [configuration] as
users appear to be still transitioning JEE apps to the jakarta namespace.
We might just need to remember to remove the old package/namespace when
On Sat, 11 Jun 2022 at 07:09, Sumanth Rajkumar
wrote:
> Hi Alex and Gilles,
>
> For the complex functional interfaces, we have so far been working on
> different options but all operate on single complex numbers one at a
> time...
>
> Instead can we design around Functional Interfaces that work
On Sat, 11 Jun 2022 at 06:30, Sumanth Rajkumar
wrote:
> On Fri, Jun 10, 2022, 19:30 Gilles Sadowski wrote:
>
> > The current implementation of "Complex" encapsulates two "double" fields
> > (not
> > a "double[]").
> > Should we make two, at first separate, discussions: One for the
> >
On Sat, 11 Jun 2022 at 06:08, Sumanth Rajkumar
wrote:
>
> The type change would have been source compatible where existing
> applications would have to recompile (without any code changes) to run
> with the new version?
>
Yes.
>
> So yes, we cannot change Complex type to interface to
Hi Alex and Gilles,
For the complex functional interfaces, we have so far been working on
different options but all operate on single complex numbers one at a time...
Instead can we design around Functional Interfaces that work on List/Arrays
instead?
Interface ComplexDoubleArray{
/* Methods
I'd like to point out that rodde has also asked this project to be
included in OpenJDK:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-June/091412.html
On 2022/06/10 19:29:43 Rodion Efremov wrote:
Hi,
I have this List/Deque data structure:
Looks pretty interesting. I’ll be honest that my own data structure expertise
revolves around immutable persistent patterns rather than mutable ones, but
your class makes perfect sense as a mutable one.
Do you have any notes on thread safety?
While it’s neat that you’re submitting to the JDK
Hello.
> [...]
>
> interface ComplexDoubleArray {
> Stream stream(int start, int length);
> }
>
> ComplexDoubleArray a;
> // Will use the Java 8 ForkJoinPool.commonPool() for parallel execution
> a.stream(start, length).parallel().forEach(x -> ComplexFunctions.conj(x,
> x));
>
> class
14 matches
Mail list logo
