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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
