jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Gaul (Jira)" <j...@apache.org>
Subject [jira] [Updated] (JCLOUDS-1548) GSON Cleanup, GSON replacement through Jackson
Date Sat, 26 Sep 2020 02:38:00 GMT

     [ https://issues.apache.org/jira/browse/JCLOUDS-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrew Gaul updated JCLOUDS-1548:
---------------------------------
    Labels: dependency  (was: )

> GSON Cleanup, GSON replacement through Jackson
> ----------------------------------------------
>
>                 Key: JCLOUDS-1548
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1548
>             Project: jclouds
>          Issue Type: New Feature
>          Components: jclouds-core
>    Affects Versions: 2.2.1
>            Reporter: Markus Gritsch
>            Priority: Major
>              Labels: dependency
>             Fix For: 2.3.0
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> *The issues listed in the following proposal must be seen as an approach to a difficult
problem and should by no means be understood as criticism of the developer.*
> In the discussion leading up to the following merge request, GSON as a library in use
was classified as problematic. In the discussion GSON was considered in the context of OSGi-based
runtime environments and an incompatibility regarding GSON was found.
> In short, the vendor of the GSON library refuses to include further OSGI meta-information
to mark any packages of the library as public.
> In order to achieve compatibility between GSON and OSGi the way was taken to substitute
package names.
> At first sight a substitution of this kind (GSON is included in a separate module) is
relatively simple, which is then consumed by the actual JCLOUDS code base (estimated complexity
level 3 of 10).
> However, a closer look at the JCLOUDS code base reveals that there is more than just
a pure substitution of the package name.
> *Why is it necessary to access package names declared as private?*
> CLOUDS extends GSON with features not provided by the original GSON library. This leads
to the following critical problems with regard to maintainability over a long time frame.
>  - Corresponding GSON enhancing functions were long ago included in the source code of
JCLOUD.
>  - Even if you take a closer look at them, it is very difficult to understand their function.
Those responsible may have stopped further development of the project.
> Simple updates of dependencies are not possible because side effects have to be estimated
directly from the additional functions and fixed in case of incompatibility (estimated level
of complexity 8 out of 10).
>  The actual, to the question independent of the discussion OSGi or not, we should clarify
largely the effect of the introduced additional function really is or whether it can not be
removed.
> *Here are a few examples*
>  - JsonBall and NullHackJsonLiteralAdapter
>  - Structure and classification of type adaptors in general
> Further questions deal with the way GSON handles certain constellations of data, for
example the de-serialization in GSON from number to double type.
> In the long run, when using a library, the quality and community of the library used
must be taken into account. Google's projects in the areas of handling JSON-based data structures
(GSON) and dependency injection (Guice) have lost a lot of development speed and willingness
to take feedback from the community. This is my personal opinion from past projects.
> *Attempted solution approach*
>  After the first step, the introduction into the JCLOUDS library (status: completed)
I will now work on the replacement of GSON by Jackson (status: started). If this step should
be too advanced or unconsidered I would like to ask for feedback from other developers in
the community.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message