Mark,
in comparison to the other JEPs proposed recently, this seems quite
vague. There is a brief list of candidate collections nestled in the
very middle of the JEP, but that's it. Given that the "alternative
collection libraries" have existed for many years, it seems to me the
author has enough
> You might be interested in a recent email to the Guava [1] mailing list
> introducing a new Google open source project called Caliper [2] that intends
> to serve as a micro-benchmarking framework for evaluating performance
> characteristics under various JVM configurations.
>
> [1]: http://groups
Hi Dima
I think a goal for such a Math subproject would be to engage in
active, constructive discussion with a wider community interested in
high-performance math libs on the JVM. The folks behind Apache Commons
Math and COLT are two obvious examples. I'm sure there has been
communication back and
Hi Mark
> > Let's look at this RFE a different way. Is there any reason not to
> > implement it?
>
> Beware: In general this is not a very persuasive line of reasoning.
>
> If all RFEs over the last ten years had been evaluated in this way then
> most of them would've been implemented by now, and
Hi,
Just adding some perspective after following these language-feature
discussions for several years now.
> In my opinion Project Coin was meant only to push some earlier chosen
> changes into language.
>
The initial Project Coin process actually invited proposals from the
community. There we
Hi
been watching this fascinating discussion - seeing Jeff's benchmark today,
was wondering if there isn't already at least one benchmark written with
JMH? Wouldn't it make sense to make that part of the submission, as a
standard practice in refactoring like this?
Regards,
Patrick
On Mon, Jul
Would it be appropriate to have a "format" exception extending
RuntimeException? That could then be documented in the API, but optional to
catch explicitly. "Format exceptions", as a name, are already used for
converting numbers and dates, for example. It could be "upgraded" to a
checked exception
On Tue, Apr 2, 2013 at 9:27 AM, Laurent Bourgès
wrote:
> > ---
> >
> > 604 Arrays.fill(elementData, newSize, size, null);
> >
> > In performance-critical code I would avoid Arrays.fill because it adds a
> > bit of overhead (unless it's intrinsified, which I don't think it is).
> >
>
> Las
On Thu, May 16, 2013 at 4:38 PM, Paul Sandoz wrote:
>
> How about doing a search for usages in all the jars on maven central?
>
> IMHO it really helps drive the discussions deprecation if we have some
> empirical data.
>
> Paul.
If memory serves, Joe Darcy and the Project Coin expert group per
