groovy.json.JsonSulper
Hi Team,
When I was using the below groovy script, *groovy.json.JsonSulper *was
throwing this error, Can you please help me with this
Throws java.lang.RuntimeException: Unable to load FastStringService
import groovy.json.*
import java.net.http.*
def req = new URL("https://jsonplaceholder.typicode.com/todos/1
").openConnection();
def postRC = req.getResponseCode();
def streamText = req.getInputStream().getText()
def jsonSlurper = new JsonSlurper()
println streamText
def json = jsonSlurper.parseText(streamText)
println json
Thanks,
Teja
Re: groovy.json.JsonSulper
First off, user questions should be sent to us...@groovy.apache.org not
dev@groovy.apache.org, as the later is for the dev team to discuss the ins
and outs of Groovy, I have added us...@groovy.apache.org to continue the
conversation there
Second, I just tried your code in Groovy Console on Groovy 4.0.1/Java 8 and
it worked, so you need to provide more information about what version of
Groovy and Java you are using.
Bonus, this:
def req = new URL("https://jsonplaceholder.typicode.com/todos/1
").openConnection();
def postRC = req.getResponseCode();
def streamText = req.getInputStream().getText()
can be replaced with:
def streamText = 'https://jsonplaceholder.typicode.com/todos/1'.toURL().text
Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry
Mobile: +45 40 44 91 88
--- Press ESC once to quit - twice to save the changes.
Den tir. 5. jul. 2022 kl. 12.49 skrev Dharma Teja :
> Hi Team,
>
> When I was using the below groovy script, *groovy.json.JsonSulper *was
> throwing this error, Can you please help me with this
>
> Throws java.lang.RuntimeException: Unable to load FastStringService
>
>
> import groovy.json.*
> import java.net.http.*
> def req = new URL("https://jsonplaceholder.typicode.com/todos/1
> ").openConnection();
> def postRC = req.getResponseCode();
> def streamText = req.getInputStream().getText()
> def jsonSlurper = new JsonSlurper()
> println streamText
> def json = jsonSlurper.parseText(streamText)
> println json
>
>
> Thanks,
> Teja
>
RE: [EXT] Re: [DISCUSS] Groovy 5 planning
I was interested in native interface default/private/static methods (GROOVY-8299, GROOVY-9801, GROOVY-1) for Groovy 5. There was discussion on what was needed for this at one point. Does anyone remember if Java 8 was holding us back in this area? https://issues.apache.org/jira/browse/GROOVY-8299 https://issues.apache.org/jira/browse/GROOVY-9801 https://issues.apache.org/jira/browse/GROOVY-1 -Original Message- From: Daniel Sun Sent: Sunday, July 3, 2022 1:21 PM To: dev@groovy.apache.org Subject: [EXT] Re: [DISCUSS] Groovy 5 planning External Email: Use caution with links and attachments. Hi Jochen, I agree with you. The manpower is always a big problem... As for the Groovy 5 itself, I wonder what features we should add to the release. I think following Java's steps is right, but Groovy should have its own evolving plan. Also, I think polishing Groovy 4 is important too, e.g. fixing issues and improving performance. Cheers, Daniel Sun On 2022/06/26 21:55:33 Jochen Theodorou wrote: > On 26.06.22 19:39, Daniel Sun wrote: > > AFAIK, quite a lot of Groovy users are still using Java 8 because their > > company have no plan to upgrade systems to run on Java 9+. It is especially > > common for bank systems I have been working on for years, so it's better to > > continue supporting Java 8 in Groovy 5 releases. > > When is it likely for them to change? If we go by the Oracle extended > support it would mean to have Java8 in till 2030. > > if we had the manpower I would suggest making a java8 version of > Groovy 5. But I think that is not realistic. It will be difficult to > support deprecated/removed API. I mean it is a bit more than in the > past where it was about backporting features to older Java versions or > enabling language only features on older Java versions. The > alternative would then be to not to support that feature anymore... > like for example the SecurityManager. But would such a Groovy-Version > still be useful in its current usage? > > > bye Jochen >
Re: [EXT] Re: [DISCUSS] Groovy 5 planning
- Original Message - > From: "Milles, Eric (TR Technology)" > To: "dev" > Sent: Tuesday, July 5, 2022 4:59:52 PM > Subject: RE: [EXT] Re: [DISCUSS] Groovy 5 planning > I was interested in native interface default/private/static methods > (GROOVY-8299, GROOVY-9801, GROOVY-1) for Groovy 5. There was discussion > on > what was needed for this at one point. Does anyone remember if Java 8 was > holding us back in this area? It does not, Java the language only adds interface private methods in Java 9 but the VM already supports them since 8. As a trivia, the support in the VM was added in 8 to be able to desugar the body of a lambda as a private method (static or not) when a lambda is used inside a default method. > > https://issues.apache.org/jira/browse/GROOVY-8299 > https://issues.apache.org/jira/browse/GROOVY-9801 > https://issues.apache.org/jira/browse/GROOVY-1 regards, Rémi > > > -Original Message- > From: Daniel Sun > Sent: Sunday, July 3, 2022 1:21 PM > To: dev@groovy.apache.org > Subject: [EXT] Re: [DISCUSS] Groovy 5 planning > > External Email: Use caution with links and attachments. > > Hi Jochen, > > I agree with you. The manpower is always a big problem... > > As for the Groovy 5 itself, I wonder what features we should add to the > release. > I think following Java's steps is right, but Groovy should have its own > evolving plan. Also, I think polishing Groovy 4 is important too, e.g. > fixing > issues and improving performance. > > Cheers, > Daniel Sun > On 2022/06/26 21:55:33 Jochen Theodorou wrote: >> On 26.06.22 19:39, Daniel Sun wrote: >> > AFAIK, quite a lot of Groovy users are still using Java 8 because their >> > company >> > have no plan to upgrade systems to run on Java 9+. It is especially common >> > for >> > bank systems I have been working on for years, so it's better to continue >> > supporting Java 8 in Groovy 5 releases. >> >> When is it likely for them to change? If we go by the Oracle extended >> support it would mean to have Java8 in till 2030. >> >> if we had the manpower I would suggest making a java8 version of >> Groovy 5. But I think that is not realistic. It will be difficult to >> support deprecated/removed API. I mean it is a bit more than in the >> past where it was about backporting features to older Java versions or >> enabling language only features on older Java versions. The >> alternative would then be to not to support that feature anymore... >> like for example the SecurityManager. But would such a Groovy-Version >> still be useful in its current usage? >> >> >> bye Jochen
