[
https://issues.apache.org/jira/browse/JCLOUDS-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Gaul resolved JCLOUDS-1548.
----------------------------------
Resolution: Fixed
> 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)
