Bump to jawn-parser 0.11.0

[suhasgaddam]

Patch is my original work, and I license the work to the sjon-new project under the project’s open source license.

https://github.com/non/jawn/compare/v0.10.4...v0.11.0

[suhasgaddam]

As a heads up, I am pretty sure there is a binary incompatibility between jawn-parser 0.10.4 and 0.11.0.

[eed3si9n]

As long as the incompatibility does not leak out to sjson-new API (or sbt), I think our policy is to allow/consider bump up of dependencies.

[dwijnand]

Here's the list of binary incompatibilities from 0.10.4 to 0.11.0:

* abstract method add(java.lang.CharSequence)Unit in interface jawn.FContext is present only in current version
* method add(java.lang.String)Unit in class jawn.NullFacade#NullContext in current version does not have a correspondent with same parameter signature among (java.lang.CharSequence)Unit, (java.lang.Object)Unit, (scala.runtime.BoxedUnit)Unit
* method add(java.lang.String)Unit in interface jawn.FContext in current version does not have a correspondent with same parameter signature among (java.lang.CharSequence)Unit, (java.lang.Object)Unit

* abstract method at(Int,Int)java.lang.CharSequence in class jawn.Parser is present only in current version
* method at(Int,Int)java.lang.String in class jawn.AsyncParser has a different result type in current version, where it is java.lang.CharSequence rather than java.lang.String
* method at(Int,Int)java.lang.String in class jawn.ByteBufferParser has a different result type in current version, where it is java.lang.CharSequence rather than java.lang.String
* method at(Int,Int)java.lang.String in class jawn.ChannelParser has a different result type in current version, where it is java.lang.CharSequence rather than java.lang.String
* method at(Int,Int)java.lang.String in class jawn.Parser has a different result type in current version, where it is java.lang.CharSequence rather than java.lang.String
* method at(Int,Int)java.lang.String in class jawn.StringParser has a different result type in current version, where it is java.lang.CharSequence rather than java.lang.String

* abstract method jint(java.lang.String)java.lang.Object in interface jawn.Facade does not have a correspondent in current version
* method jint(java.lang.String)Unit in object jawn.NullFacade does not have a correspondent in current version
* method jint(java.lang.String)jawn.ast.DeferLong in object jawn.ast.JawnFacade does not have a correspondent in current version

* abstract method jnum(java.lang.CharSequence,Int,Int)java.lang.Object in interface jawn.Facade is present only in current version
* abstract method jnum(java.lang.String)java.lang.Object in interface jawn.Facade does not have a correspondent in current version
* method jnum(java.lang.String)Unit in object jawn.NullFacade does not have a correspondent in current version
* method jnum(java.lang.String)jawn.ast.DeferNum in object jawn.ast.JawnFacade does not have a correspondent in current version

* abstract method jstring(java.lang.CharSequence)java.lang.Object in interface jawn.Facade is present only in current version
* method jstring(java.lang.String)java.lang.Object in interface jawn.Facade's type is different in current version, where it is (java.lang.CharSequence)java.lang.Object instead of (java.lang.String)java.lang.Object
* method jstring(java.lang.String)Unit in object jawn.NullFacade's type is different in current version, where it is (java.lang.CharSequence)Unit instead of (java.lang.String)Unit
* method jstring(java.lang.String)jawn.ast.JString in object jawn.ast.JawnFacade's type is different in current version, where it is (java.lang.CharSequence)jawn.ast.JValue instead of (java.lang.String)jawn.ast.JString

* abstract synthetic method jawn$CharBasedParser$$charBuilder()jawn.CharBuilder in interface jawn.CharBasedParser is present only in current version
* abstract synthetic method jawn$CharBasedParser$_setter_$jawn$CharBasedParser$$charBuilder_=(jawn.CharBuilder)Unit in interface jawn.CharBasedParser is present only in current version

* method charBuilder()jawn.CharBuilder in class jawn.Parser does not have a correspondent in current version
* method descape(java.lang.String)Char in class jawn.Parser's type is different in current version, where it is (java.lang.CharSequence)Char instead of (java.lang.String)Char
* method extend(java.lang.String)Unit in class jawn.CharBuilder's type is different in current version, where it is (java.lang.CharSequence)Unit instead of (java.lang.String)Unit
* method is(Int,Char)Boolean in class jawn.Parser does not have a correspondent in current version
* method is(Int,Int,java.lang.String)Boolean in class jawn.Parser does not have a correspondent in current version
* method limit()Int in class jawn.ByteBufferParser does not have a correspondent in current version
* method line_=(Int)Unit in class jawn.ByteBufferParser does not have a correspondent in current version
* method start()Int in class jawn.ByteBufferParser does not have a correspondent in current version

Maybe my brain is still slow from the jet lag, or maybe I'm overly paranoid, but I can't with confidence say that sbt won't break with this upgrade.

[dwijnand]

Here's some evidence of how things break with jawn's 0.10 to 0.11 upgrade: https://github.com/scala/community-builds/pull/623#issuecomment-340915450.

[eed3si9n]

I understand that Jawn API might have changed, but still that's completely abstracted from the point of view sjson-new users right? The breakage @SethTisue reported on lm seems to be direct use of Jawn, unrelated to sjson-new - https://github.com/sbt/librarymanagement/blob/91b56c50db93294003511fd40967c9296b07ef45/ivy/src/main/scala/sbt/internal/librarymanagement/IvyCache.scala#L136-L156

[eed3si9n]

It's a variant of https://twitter.com/dwijnand/status/880449986936418305

Given project foo follows SemVer, if release v1.0 depends on library bar, would you be surprised if release v1.1 doesn't depend on bar?

[dwijnand]

I think lm would break if it started using a new version of sjson-new that had upgraded to jawn 0.11.

Which means any user of lm that also uses jawn would also break if it started using a new version of lm.

So I think it would be safest to just leave the ecosystem of sbt 1 on jawn 0.10.

[eed3si9n]

Well it means when we bump up sjson-new directly or transitively, we need to update the internal "FixedParser," which I don't think is a big deal since it's internal.

The degree of "safeness" on bumping up transitive library (Jawn or otherwise) is somewhat subjective, but we can try to guess the intersection of lm user (sbt 1 plugins basically) and Jawn users. I am guessing it's near-zero, but like I said I admit we are in uncertain water :)

[dwijnand]

I think the json4s situation is precedent what happens to sbt plugins that rely on transitive json dependencies, and those dependencies changing binary api. Thus why json4s-ast, aka scala-json, was created.

It might be early days enough that this will hit no-one or only a number of enthusiastic upgraders - so we should do it. On the other hand it would be good if this upgrade had some actual advantages.

Does anyone know what jawn 0.11 brings? Looks like there are no release notes and I can't gauge any top hitters from the change log https://github.com/non/jawn/compare/v0.10.4...v0.11.0.

[eed3si9n]

Does anyone know what jawn 0.11 brings? Looks like there are no release notes and I can't gauge any top hitters from the change log non/jawn@v0.10.4...v0.11.0.

Following up on this. I am not really sure but the one of the big change seems like the support for CharSequences and some perf improvements.

[eed3si9n]

Bumped to Jawn 1.0.0 in https://github.com/eed3si9n/sjson-new/pull/113