commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject Re: [VOTE] Release Imaging 1.0 from RC7
Date Tue, 26 Nov 2013 09:05:26 GMT
Hi Damjan,

Le 26/11/2013 06:31, Damjan Jovanovic a écrit :

> Firstly, we discussed several options before for the 1.0 release, and
> agreed that the contents of trunk would be quickly pushed out as 1.0
> with minimal changes (many/most users are using 1.0-SNAPSHOT), and
> then the big API redesign would be 2.0. I've also been thinking of
> doing a complete rewrite for 2.0 and only pulling in some of the good
> bits we have now. So it's extremely discouraging to be pushed for more
> and more changes, many of which will have no post-1.x value, and don't
> even fit in with what was originally agreed on.

Sorry for the late review. I'm not opposed to the release and I won't
mind if you prefer to ignore my feedback :)

> It looks like CachingInputStream is used by IccProfileParser, and
> appears to be used to store data that has been read from the
> underlying stream so it can be re-read later. You can copy it to
> commons-io, but I'd prefer not having a runtime dependency on it. And
> it's ByteSourceInputStream you really want in commons-io and/or
> commons-compress, a gem that allows seeking over an InputStream.

I would be possible to avoid a runtime dependency by shading the classes.

> Enum vs public static final, hmm.

I don't think that makes any difference performance wise, in both cases
it leads to a comparison of references.

> Thank you, but that probably broke compatibility for 1.0-SNAPSHOT
> users, so now we have to release RC7 as 1.0 :-).


> Hidden Javadocs don't hide packages from IDE code completion. There is
> only 2 choices w.r.t. packages: keeping everything in one package to
> hide internal classes by giving them package private access, and
> keeping classes in different packages to better structure code but
> then having to make them public as a result (and choice 3, a pipe
> dream, use OSGi and don't export the packages with internal classes).
> Maybe a public factory method in a public base class returning
> package-private subclasses would work?

I know hiding the javadoc doesn't solve the issue, but that makes the
documentation cleaner and less intimidating.

Emmanuel Bourg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message