Re: Using Groovy 4.0.1 and want to use Groovys JsonSlurper or whatever it might be called in version 4.

MG <mgbiz-yvYIh6MZAuFWk0Htik3J/[email protected]>
Newsgroups gmane.comp.lang.groovy.user
Message-ID <[email protected]>
Hi Paul,

thanks for clearing that up :-)

(I did not refer to this evident water-under-the-bridge problem (which I 
had never heard of before) in my post, but just wanted to confirm that 
Groovy plays very well with & can easily be used to enhance established 
Java frameworks, and people therefore should not feel the need to use 
functionality that comes bundled with Groovy, if they are familiar with 
or prefer another framework G-) )

Cheers,
mg


On 11/07/2022 05:15, Paul King wrote:
> On Mon, Jul 11, 2022 at 3:00 AM Guillaume Laforge <[email protected]> wrote:
>> Which bug ticket are we talking about?
>> (The ordering issue in lists)
> I am not sure there was ever any issue raised in the Groovy's Jira.
> Groovy's JsonSlurper is a port from project Boon. Here is the issue
> and fix from project Boon:
>
> https://github.com/boonproject/boon/issues/182
> https://github.com/boonproject/boon/commit/fa4c64991609
>
> Basically on JDK1.6 there is an inherent problem with LinkedHashMap
> where it can be the subject of a DoS hash collision attack. In the
> context of JsonSlurper, by using carefully crafted JSON payloads it is
> possible in rare circumstances to implement a DoS attack. It is fixed
> (wth a system property) on JDK1.7 and permanently fixed for JDK1.8 and
> above. The Boon project decided to forgo map ordering on vulnerable
> systems to eliminate the DoS problem. Groovy ported that change to
> JsonSlurper. A map is a name-to-value container. The "also preserves
> order" property can be thought of as a nice feature to have in
> particular circumstances. The thinking I presume when Boon changed the
> behavior was that security was more important than the "nice to have"
> feature. Users should move to a non-vulnerable JDK version if they
> want the nicer behavior.
>
> The summary is that unless folks are stuck on JDK1.6, this shouldn't
> affect them.
>
> Here is a nice explanation of the problem explained using cats:
>
> https://www.anchor.com.au/blog/2012/12/how-to-explain-hash-dos-to-your-parents-by-using-cats/
>
>
> Cheers, Paul.
>
>> Le dim. 10 juil. 2022, 18:49, MG <mgbiz-yvYIh6MZAuFWk0Htik3J/[email protected]> a écrit :
>>> Hi Tommy,
>>>
>>> I agree: We have often found that using well established Java libraries together with the power of the Groovy language works well & makes great sense (e.g. Ebean ORM & Vaadin web-GUI in our case).
>>> Groovy's integrated support (for e.g. XML/JSON) is often very dynamic in nature, something which we often neither need nor want, and the small overhead of writing a thin, type/schema-safe wrapper around e.g. a generic Java XML SAX/DOM lib for a specific application case has always turned out to be well invested & makes the code better readable and easier to refactor.
>>>
>>> In addition these Java libs have often been debugged and performance optimized over the years in a way that Groovy finds hard to match, since it would spread its development manpower very thin.
>>> The command-line parsing library coming with Groovy nowadays is a good example of an imho better suited hybrid approach: It supplies Groovy goodness over an excellent existing Java library (picocli) G-)
>>>
>>> Cheers,
>>> mg
>>>
>>>
>>>
>>> On 10/07/2022 18:03, Tommy Svensson wrote:
>>>
>>> Hi Paul,
>>>
>>> Thanks, but after the warning that JSONSlurper can loose order in lists, a known bug, I decided to go with Jackson Jr, which also allows me to parse JSON into a Map structure. But since I'm coding entirely in Groovy using Groovys JSON support would make sense, but the pointed out bug scared me away :-). I have used Jackson Jr before, it works well.
>>>
>>> /Tommy
>>>
>>>
>>> Från: Paul King <[email protected]>
>>> Svara: users-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected] <users-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]>, [email protected] <[email protected]>
>>> Datum: 10 juli 2022 at 16:20:43
>>> Till: users-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected] <users-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]>
>>> Ämne:  Re: Using Groovy 4.0.1 and want to use Groovys JsonSlurper or whatever it might be called in version 4.
>>>
>>> Hi Tommy,
>>>
>>> I wrote a little blog post that might have some of the information you
>>> were missing:
>>>
>>> https://blogs.apache.org/groovy/entry/parsing-json-with-groovy
>>>
>>> Perhaps some more of that info belongs in the official documentation.
>>>
>>> Cheers, Paul.
>>>
>>> On Fri, Jul 8, 2022 at 9:10 PM Tommy Svensson <[email protected]> wrote:
>>>> Hello Groovy people,
>>>>
>>>> I have code using org.apache.groovy:groovy:4.0.1 and it builds without any problems.
>>>>
>>>> But now I want to use the JSONSlurper and it looks like there is a new JSONParser also. That however requires groovy-all from googling. The problem is that there seem to be not groovy-all for version 4.0.1. Maven completely fails when I add "-all" to "groovy" in my poms. It will not download the groovy-all file. I deleted ~/.m2/repository and built again and it downloaded all but groovy-all.
>>>>
>>>> The JSON stuff is not available in the "groovy" artifact.
>>>>
>>>> So my question really is, I want to use Groovys JSON features, what do I need to do to accomplish that ?
>>>>
>>>> I've completely failed top find any Groovy 4.0 related page other than the release notes. Since there are big diffs between versions there must be some page for each version I assume ?
>>>>
>>>> I found this: https://groovy-lang.org/processing-json.html but it is not version specific and provides no information on how to get access to it.
>>>>
>>>> I'm frustrated. Something seemingly simple turned out to be the opposite!
>>>>
>>>> Any help is appreciated.
>>>>
>>>> Thanks,
>>>> Tommy Svensson
>>>>
>>>>
>>>>
>>>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.