[jira] [Updated] (JCLOUDS-1548) GSON Cleanup, GSON replacement through Jackson

["Andrew Gaul (Jira)" <ji...@apache.org>]

     [ 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)