[jawn] Jawn AST users?

[Erik Osheim]

Hi folks,

I'm preparing a new release of Jawn [1], my JSON parsing library.

Jawn's main strengths are a fast parser which can be run synchronously
or asynchronously to produce any desired AST. Compared to most other
JSON libraries, Jawn's internal AST is quite lightweight (and anemic).

I wanted to find out if anyone out there is actually using Jawn's AST,
and if so, for what? Simple Object -> AST -> String rendering? Data
encapsulation and storage in memory? Something else?

I'm trying to get a sense of whether it is worth it for me to try to
make the AST nicer to work with, and also the degree to which a new
version must preserve compatibility.

Thanks,

-- Erik

[1] https://github.com/non/jawn

[Erik Osheim]

Also, apologies if I have overstepped in emailing the Typelevel list.

Jawn is not a Typelevel project, but it is published under
org.spire-math, and I figured it was possible that there were folks on
this list who are using it.

Please let me know if you'd prefer not to receive these kinds of
emails in the future.

-- Erik

> --
> You received this message because you are subscribed to the Google Groups "Typelevel Users & Development List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to typelevel+...@googlegroups.com.
> To post to this group, send email to type...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/typelevel/20150517214353.GP30710%40vein.plastic-idolatry.com.
> For more options, visit https://groups.google.com/d/optout.

[Ismael Juma]

Hi Erik,

On Sun, May 17, 2015 at 10:43 PM, Erik Osheim <er...@plastic-idolatry.com> wrote:

I wanted to find out if anyone out there is actually using Jawn's AST,
and if so, for what? Simple Object -> AST -> String rendering? Data
encapsulation and storage in memory? Something else?

I recently used the Jawn parser with the spray-json AST as a proposed improvement for Kafka:

https://github.com/ijuma/kafka/tree/kafka-1595-remove-deprecated-json-parser

This hasn't been integrated yet as there are questions from the Kafka committers about which JSON library to use. Having few dependencies that can cause conflict with user dependencies is very important to them as the client and server are in the same jar at the moment (although they are in the process of changing this). No dependencies would be even better, of course.

In a somewhat funny twist, spray-json suits that goal better as it has no additional dependencies, unlike spire-ast, which has spire as a dependency. This is a long way to ask if the spire dependency is really fundamental to jawn's AST or if it could be moved to a separate module.

I'm trying to get a sense of whether it is worth it for me to try to
make the AST nicer to work with, and also the degree to which a new
version must preserve compatibility.

I'd be interested in improvements to the AST and compatibility is not important for me as I am not using it yet. 

Best,

Ismael

[Erik Osheim]

Hi Ismael,

Thanks for your feedback. I was planning on removing the Spire
dependency, or moving it out to a separate module if anyone uses it
(which I don't expect).

Right now, I'm planning to change the AST a bit. I want to keep it
simple but also support fast/lazy parsing.

-- Erik

[Ismael Juma]

On Sun, May 17, 2015 at 11:31 PM, Erik Osheim <er...@plastic-idolatry.com> wrote:

Thanks for your feedback. I was planning on removing the Spire
dependency, or moving it out to a separate module if anyone uses it
(which I don't expect).

Great.

Right now, I'm planning to change the AST a bit. I want to keep it
simple but also support fast/lazy parsing.

Once you have something ready for testing, let me know and I'll try to replace spray-json with the jawn AST in the Kafka branch I mentioned.

Best,

Ismael 

[Erik Osheim]

On Sun, May 17, 2015 at 11:45:38PM +0100, Ismael Juma wrote:
> Once you have something ready for testing, let me know and I'll try to
> replace spray-json with the jawn AST in the Kafka branch I mentioned.

One quick question for you:

Right now Jawn's AST assumes you will want fast lookup/updating for
JSON objects, so JObject wraps a mutable.Map built during parsing.

Sometimes this feature isn't needed. In those case, deferring the map
creation (and saving something more like Array[(String, JValue)]
instead) is more efficient -- you can create a map later if you end up
needing it.

Jawn's AST construction is already quite fast, but in cases where you
don't need the map it could be even faster. I'm just curious whether
your usage in Kafka would benefit from this kind of optimization.

-- Erik

[Ismael Juma]

On Sun, May 17, 2015 at 11:52 PM, Erik Osheim <er...@plastic-idolatry.com> wrote:

One quick question for you:

Right now Jawn's AST assumes you will want fast lookup/updating for
JSON objects, so JObject wraps a mutable.Map built during parsing.

Sometimes this feature isn't needed. In those case, deferring the map
creation (and saving something more like Array[(String, JValue)]
instead) is more efficient -- you can create a map later if you end up
needing it.

Jawn's AST construction is already quite fast, but in cases where you
don't need the map it could be even faster. I'm just curious whether
your usage in Kafka would benefit from this kind of optimization.

Kafka currently uses scala.util.parsing.json (hard to believe, I know) and Map[String, Any] is used all over the codebase. As such, without making larger changes, get from json object by field name is indeed important.

Best,

Ismael

[Erik Osheim]

On Sun, May 17, 2015 at 11:59:51PM +0100, Ismael Juma wrote:
> Kafka currently uses scala.util.parsing.json (hard to believe, I know) and
> Map[String, Any] is used all over the codebase. As such, without making
> larger changes, get from json object by field name is indeed important.

Great to know.

I will focus on getting an improved but conservative new release out
so you can try it out. I would love to help speed things up.

-- Erik

[irfan ahmad]

Hi Erik,

Is there a gitter room or a mailing for jawn? If so, apologies that my quick google search didn't find any. If not, might be nice to help adoption of the library. I'll join :-)

[Jon Pretty]

Hi Irfan,

As of quite recently, there's a Gitter channel here:

   https://gitter.im/non/jawn

Cheers,

Jon

--

You received this message because you are subscribed to the Google Groups "Typelevel Users & Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to typelevel+...@googlegroups.com.
To post to this group, send email to type...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/typelevel/686b0926-d4df-4839-ac4c-7443b98cf008%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jon Pretty | @propensive