On 29.12.2016 18:24, Rafael Winterhalter wrote:
Hei Jochen, thank you for your feedback. I must have missed your
posting, I regularly fail to follow up on the things discussed on the
mailing list and its not easy to seatch for topics, sorry for that.
don´t worry, my complaints have not been ignored, but did not change
anything either.
In Byte Buddy, I created an option to use subclassing by creating
dedicated class loaders for proxy classes. There is however a row of
disadvantages:
1. Class loaders are not cheap objects, they require some memory and the
performance cost of creating dedicated class loaders is significant. I
have benchmarked this, as well and it costs you about three times the
time to create such "wrapper class loaders" rather than injecting.
agreed
2. It is close to impossible to define a good life-cycle for classes
loaded by such wrapper class loaders. You need to keep a reference to
the proxy class to prohibit its collection which in turn keeps a
reference to the original class loader making it uncollectable. Using
soft or weak references is less then ideal, too and the only option
would be to use ephemerons which are not supported by Java. With
injection, it is as easy as looking up a previously created class from
the proxied class's class loader which dies and lives with this class
loader.
A ClassValue is no ephemeron, but letting it keep a SoftReference to the
proxy class may work. It means there will be situations in which the
class will be recreated, but thanks to the SoftReference both classes
and loaders should still be garbage collectable.
3. Java packages define their identity by name and class loader at
runtime. Many developers use anonymous classes or nested classes which
are package-private and cannot be subclassed by creating a new class
loader but which must live in the same class loader.
package-private is another story... I would be happy enough to have a
generic solution for protected.
and 4. if the loader is defined by a module you will have fun with
creating layers and export/read edges
Those are the main issues that lead us to strongly prefer injection,
especially in a testing library like Mockito and there are some more
complications that we would like to avoid.
the reply will most probably be about asking why these classes are not
made public. They can be exported to only the framework module and all
that.
I am however especially concerned about upgrading. Esepcially with
mature and wide-spread libraries like Mockito or Hibernate, even minor
changes can cause really big, hard-to-debug issues for our users.
been there and I agree. But it is unlikely that something like the
implementation of strong encapsulation will be done without trouble for
bigger projects. Will this lower adoption of Java9? Sure.
Switching from injection to subclassing would be much more than a minor
change. The JVM developers surely know this, otherwise they would not
keep classes like Stack around or fix quirks in classes like ByteBuffer.
Too much code was written on top of these classes and their expected
inner working. If we were however forced to change our APIs that
drastically, I think the real consequences would be much more drastic
than the mentioned changes. At the moment, as a library author, I do
however feel like there are few options to avoid this.
On the other hand... if you think it has to be done at some point, then
why delay it? Of course the question of if it has to be done is
questionable in itself, especially since the slim advantages of the
module system turn into the negative, if weighted against "other
solutions", the work you will have with it and the limitations it imposes.
