Gson: [FEATURE-REQUEST] Make com.google.gson.Gson non-final

[llech]

The issue: class com.google.gson.Gson has 'final' classifier. I see no rationale behind it, but very strong rationale against: this makes Gson extremely unfriendly to use in service-oriented architecture.

For example, I've tried to export Gson instance as Service in OSGi container and failed to do that, because framework was not able to create proxy for class with 'final' modifier (It's what that modifier is meant for). Of course it's possible to create wrapping interfaces or factories, but it requires creating extra layers and dependencies, which could be easily avoided by removing that classifier.

[JakeWharton]

The class is not designed for inheritance is the rationale.

On Thu, Sep 7, 2017 at 4:18 AM llech [e-mail] wrote:

The issue: class com.google.gson.Gson has 'final' classifier. I see no
rationale behind it, but very strong rationale against: this makes Gson
extremely unfriendly to use in service-oriented architecture.

For example, I've tried to export Gson instance as Service in OSGi
container and failed to do that, because framework was not able to create
proxy for class with 'final' modifier (It's what that modifier is meant
for). Of course it's possible to create wrapping interfaces or factories,
but it requires creating extra layers and dependencies, which could be
easily avoided by removing that classifier.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/gson/issues/1150, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEESfc068Jl3TlqP6DhOas56BLS-Ewks5sf6btgaJpZM4PPdA0
.

[llech]

And what is the rationale behind designing class that way? I've heard claims that the code runs a few percent faster, but at the cost of being incompatibile with any modern Java framework.
If there were some tests prooving any significant performance impact, maybe they should be re-run under java 8?

[JakeWharton]

It has nothing to do with performance. It's a design decision. All classes
should be final by default unless they're explicitly designed for
inheritance.

Considering Gson's widespread adoption it would seem almost all modern Java
frameworks (a group in which I would not put OSGi) are doing just fine.

On Thu, Sep 7, 2017 at 10:01 AM llech [e-mail] wrote:

And what is the rationale behind designing class that way? I've heard
claims that the code runs a few percent faster, but at the cost of being
incompatibile with any modern Java framework.
If there were some tests prooving any significant performance impact,
maybe they should be re-run under java 8?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/google/gson/issues/1150#issuecomment-327808668, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEEeEvntLie-UVbuJ6rnjVJdcNdqYPks5sf_c6gaJpZM4PPdA0
.

[llech]

I understand your point of view, but it represents a paradigma, which is no longer valid. The whole development of java in at least last 10 years has gone in opposite direction.
Making classes final without really good reason is a big anti-pattern because practically any enterprise java framework uses proxies, so any final class that could otherwise be used as a service, for example, is a big pain that must be dealt with wrapper classes.
That design decisions were made in times before spring, blueprint or CDI have practically monopolized java world, so it's the high time to review them. It would not affect people who do not use such frameworks, all other would profit.

[JakeWharton]

Well except the opposite of everything you said is what's true. 10 years
ago people weren't making things final and now we know better. No one from
the libraries you list has come asking for non-final types in any of the
projects we manage. And you haven't addressed the fact that we're opening
up the class to inheritance despite it not being designed for it which
limits our options in the future.

On Thu, Sep 7, 2017 at 10:23 AM llech [e-mail] wrote:

I understand your point of view, but it represents a paradigma, which is
no longer valid. The whole development of java in at least last 10 years
has gone in opposite direction.
Making classes final without really good reason is a big anti-pattern
because practically any enterprise java framework uses proxies, so any
final class that could otherwise be used as a service, for example, is a
big pain that must be dealt with wrapper classes.
That design decisions were made in times before spring, blueprint or CDI
have practically monopolized java world, so it's the high time to review
them. It would not affect people who do not use such frameworks, all other
would profit.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/google/gson/issues/1150#issuecomment-327815305, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEEXIpSqQjNRgyfrgZlyi-TZ06fSGaks5sf_x1gaJpZM4PPdA0
.

[llech]

I'm very confused by your remark about not addressing the opening up the class to inheritance because it's exactly the starting point of the discussion... Or you're addressing only a first part of my request, because the second one is exactly the explanation.

Or should I understand, that you've made a design decision that should prevent directly using Gson as a service in service oriented architecture not possible? Or you consider that every moder framework should be able to remove final modifier runtime? (how would this work in OSGi? the service consumer would get a modified class from registry, but non-modified class from package import...)

I've created a wrapper class in separate bundle. I have one project extra. I fail to see any benefit of being forced to do that...

[JakeWharton]

The starting point was to enable proxies, not inheritance, and they're not
the same thing. One is very damaging to our control to compile-time usage
and the other is a side-effect of a runtime requirement.

Nothing about Gson prevents using it in service-oriented architecture
because it's an architecture. The final bit prevents its use directly in
your implementation of said architecture because of the choices of that
implementation. And now you're trying to leak that implementation's
restrictions to all your libraries. This is not adequate justification for
us to remove the final bit (ignoring the fact you haven't addressed the
inheritance problem).

You can investigate a javaagent to remove the final bit at classload time
to enable proxying. This allows every library to retain the final bit and
prevent inheritance at compile time but have it removed such that you can
proxy it at runtime. Libraries like Mockito 2 do this. Otherwise, wrapping
is a logic approach.

On Fri, Sep 8, 2017 at 4:58 AM llech [e-mail] wrote:

I'm very confused by your remark about not addressing the opening up the
class to inheritance because it's exactly the starting point of the
discussion... Or you're addressing only a first part of my request, because
the second one is exactly the explanation.

Or should I understand, that you've made a design decision that should
prevent directly using Gson as a service in service oriented architecture
not possible? Or you consider that every moder framework should be able to
remove final modifier runtime? (how would this work in OSGi? the service
consumer would get a modified class from registry, but non-modified class
from package import...)

I've created a wrapper class in separate bundle. I have one project extra.
I fail to see any benefit of being forced to do that...

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/google/gson/issues/1150#issuecomment-328045524, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEEVAx4SWzMM4MBMByyPYaD5QN_qPeks5sgQGugaJpZM4PPdA0
.