Hi Andrew!
Thanks for your kind words, I'm glad you're finding the library useful.
> I've been working a lot with HPPC recently and have got a couple of ideas of
> my own that I've been prototyping, e.g. an arraylist backed by multiple
> arrays in a chain.
Funny -- I actually need something like this myself (the reasons being
not just memcpy on grow, but also the limits on the maximum size of
Java arrays).
> Putting these in a separate maven project is a little awkward -- it's
> possible to install the maven templating plugin from the original project
> and hook it into the new project's build, but there are other issues like
> useful testing utilities which are package-private and not included in the
> hppc jar.
I've been changing a *lot* in HPPC recently -- check out the master
branch. I am on vacation this week, but I'll be working on it once I
get back with the intention of releasing an API-breaking version as
soon as I am happy with the changes.
While it's not a good idea for a library to expose its internals in
general, in HPPC's case there are reasons for doing so (we sometimes
need to fiddle with the buffers directly). So if there's something
that is package-private (and hasn't been removed) we should probably
open it up. If somebody wants an implementation-behind-an-api then
Koloboke and fastutil are probably better choices anyway (because they
implement JUC interfaces).
> But I'm a bit reluctant to fork it and make major changes there, because my
> needs may not be mainstream enough (or sufficiently well written!) to go
> back into trunk, and then inevitably it'd end up diverging and being a pain
> to maintain.
Yeah, I understand. But it's the nature of a fork -- the more changes
you introduce, the more you'll have to maintain... eventually the
overhead will probably cause the fork to become a stand-alone
project. Vincent has implemented so many changes (and good for him!)
that it's effectively a different project now :)
Also, I admit we do have some selfish needs in HPPC and I would like
to have this freedom of deciding what we want to introduce, what to
maintain and what to drop.
> Dawid, how would you feel about setting up a separate hppc-contrib project,
> with access to the same build and test tools, but an "anything goes" policy
> and very lightweight review process? (i.e. don't break other people's
> tests.)
But how would it be different from a fork? For example when I make
some major refactorings in the codebase I'd need to go and fix all the
contribs as well? This wouldn't work for me. As much as I'd love to do
it, I just won't have the time :(
> Or there might be better ways to approach this -- splitting out the build
> and test tools into a separate package that other people could use more
> easily, or maybe something involving optional git subtrees/submodules that
> can pull other codebases in.
The template processor should be fairly functional, especially that on
master it's a fully fledged Maven mojo. We can make it part of an
official release (I don't think it's currently deployed to Maven
Central). It is a simple tool, but if you (or others) find it useful
then sure thing. Would this work?
Dawid