I'd also like to add that I'm not sure comparing what's included in java.lang and other old Java packages isn't the best indicator of modularisation. Sure, you could say that about newer Java releases where there was quite a bit more discipline toward breaking functionality up into appropriate packages, but when you compare that with what was available since Java 1.0 or 1.1 or so, you may notice that original versions of Java weren't so disciplined about it (which seems to be a pretty typical way that Java libraries are developed where the original version doesn't have to break everything up so fine grained just yet).
On 13 May 2017 at 13:50, Matt Sicker <boa...@gmail.com> wrote: > On 13 May 2017 at 06:29, Raymond DeCampo <r...@decampo.org> wrote: >> >> > As for the module, do we mind a few more bytes? >> > It leaves room for expansion (not that I intend to do it personally), >> > and it avoids that "core" becomes the place where we put every little >> > thing that does not belong elsewhere. [If it turns out that "core" >> > contains only two classes, a question might be whether those should >> > not also belong to their own module with a name that better reflects >> > its content.] >> > >> >> It's not the "bytes" it's the overhead. Having a module containing only >> one class is extreme. >> > > What I find amusing here is that if there were a standard an easy way to > share artefacts containing only a single class file, we'd end up with an > npm-style ecosystem where a basic project would require downloading and > maintaining dozens or hundreds of dependencies without doing anything > particularly special. When it comes down to it, finding a proper point of > modularisation is difficult as there are trade offs in maintenance versus > purity. Since Java still doesn't have any good way to enforce automatic > semantic versioning and simple code isolation (JPMS in Java 9 refuses to > address this still which was one of Red Hat's criticisms), we're stuck > bundling a bunch of somewhat related code together just for usability > purposes. Contract this with the C development world where libraries pride > themselves on being distributable as a single source file for simplicity > (even though said file is usually thousands of lines long). > > -- > Matt Sicker <boa...@gmail.com> > -- Matt Sicker <boa...@gmail.com>
