Java v. 1.6 support

[Opalo]

Hi, Is there any way You'll support java v. 1.6? In need the lib with 1.6 compatibility. Meanwhile I'll fork the repo and make necessary changes. Just let me know.

[javaboon]

It is possible. The only ties to 1.7 should be in IO.java. Should be... :)

The project was originally written targeting JDK 1.8, and then I had to use it in production so I had to port it to JDK 1.7 begrudgingly.

RE: Meanwhile I'll fork the repo and make necessary changes. Just let me know.

Cool that will give me an idea of the real scope.

Let me know. It probably makes sense for adoption to drop back to JDK 1.6. I don't use any JDK specific things except *.nio.Files. I think.

[javaboon]

I am looking at...

http://en.wikipedia.org/wiki/Java_version_history#Java_SE_7_.28July_28.2C_2011.29

JVM support for dynamic languages, with the new invokedynamic bytecode under JSR-292,[91] following the prototyping work currently done on the Multi Language Virtual Machine

\ I use that but it is isolated. So... hmmm...

Compressed 64-bit pointers[92](available in Java 6 with -XX:+UseCompressedOops)[93]

These small language changes (grouped under a project named Coin):[94]

\ I use those but they are nice to have not required...

Strings in switch[95]

\ I do use that and it is a performance critical part of the code. I could switch it with a hash map and is should perform about the same.

Automatic resource management in try-statement[96]

\ I use it but easy to replace.

Improved type inference for generic instance creation, aka the diamond operator <>[97]

\ I use it, but...

Simplified varargs method declaration[98]

\ Not sure if I use it but I do use varargs.

Binary integer literals[99]

\ Don't use.

Allowing underscores in numeric literals[100]

\ Use

Catching multiple exception types and rethrowing exceptions with improved type checking[101]

\ Don't use.

Concurrency utilities under JSR 166[102]

\ Wrote some stuff I plan on including that uses but it is not included yet.

New file I/O library to enhance platform independence and add support for metadata and symbolic links. The new packages are java.nio.file and java.nio.file.attribute[103][104]

\ I use this a lot.

Timsort is used to sort arrays instead of merge sort

\ don't directly use...

Library-level support for elliptic curve cryptography algorithms

\ Not that smart.

An XRender pipeline for Java 2D, which improves handling of features specific to modern GPUs

\ Don't use.

New platform APIs for the graphics features originally implemented in version 6u10 as unsupported APIs[105]

\ Don't use

Enhanced library-level support for new network protocols, including SCTP and Sockets Direct Protocol

• Don't use

Upstream updates to XML and Unicode

\ Hell no.

[Opalo]

Ok. You can find the version that compiles (in the case of syntax - diamonds, try with resources, etc.) with java 1.6 version: https://github.com/Opalo/boon/tree/java_1.6. It's compiled with JDK 1.7 thus why no errors are present while compilation, but 1.7 classes (NIO) are still present in the code. I won't dare to implement other changes when it comes to IO. You need access to the repo?

[RichardHightower]

I would just pull out all of the IO. It will break JsonParser but then we can just pull out just what JsonParser needs.

On Thu, Mar 13, 2014 at 5:11 AM, Opalo notifications@github.com wrote:

Ok. You can find the version that compiles (in the case of syntax - diamonds, try with resources, etc.) with java 1.6 version: https://github.com/Opalo/boon/tree/java_1.6. It's compiled with JDK 1.7 thus why no errors are present while compilation, but 1.7 classes (NIO) are still present in the code. I won't dare to implement other changes when it comes to IO. You need access to the repo?

Reply to this email directly or view it on GitHubhttps://github.com/RichardHightower/boon/issues/99#issuecomment-37525710 .

Rick Hightower (415) 968-9037 Profile http://www.google.com/profiles/RichardHightower

[Opalo]

I just tried to copy all the necessary java.nio classes into parser's source hierarchy but it seems to lead nowhere. The dependency tree never finishes.

I'll try later to eliminate all java.nio dependencies that are not present in JDK 1.6.

[RichardHightower]

yep.. I could see that. I was never intending on making it backwards compatible with 1.6

We did fork the Boon JSON parser and added it to the next version of Groovy which is 1.6 only so it is possible.

Which pieces of Boon were you the most interested in?

I don't think I get that much value out of JDK 1.7 nio... but sort of don't want to spend time pulling it out..

What do you want to do with Boon?

On Wed, Mar 26, 2014 at 1:47 PM, Opalo notifications@github.com wrote:

I just tried to copy all the necessary java.nio classes into parser's source hierarchy but it seems to lead nowhere. The dependency tree never finishes.

I'll try later to eliminate all java.nio dependencies that are not present in JDK 1.6.

Reply to this email directly or view it on GitHubhttps://github.com/RichardHightower/boon/issues/99#issuecomment-38737376 .

Rick Hightower (415) 968-9037 Profile http://www.google.com/profiles/RichardHightower

[Opalo]

I'm looking for fast JSON parser that can be used in exactly same manner as groovy's native JsonSlurper. I'm using HTTPBuilder for making connections and a JSON parser used there for response parsing (AFAIK JsonSluper) seems to be slow and performance is crucial for me.

What I need exactly is:

• make a connection with HTTPBuilder
• receive parsed JSON response (here I see place for boon)
• trim the obtained data (remove some fields with groovy's collect method)
• send the data to client This is really basic usage.

Will boon parser become a part of groovy? From which version?

[RichardHightower]

Groovy 2.3

The accepted the pull request already.

You can pull it from there.

It is a forked version of the boon parser.

Just build 2.3 and you have it already.

It is faster than jackson and gson.

https://github.com/groovy/groovy-core/tree/master/subprojects/groovy-json

On Thu, Mar 27, 2014 at 1:11 AM, Opalo notifications@github.com wrote:

I'm looking for fast JSON parser that can be used in exactly same manner as groovy's native JsonSlurper. I'm using HTTPBuilder for making connections and a JSON parser used there for response parsing (AFAIK JsonSluper) seems to be slow and performance is crucial for me.

What I need exactly is:

• make a connection with HTTPBuilder
• receive parsed JSON response (here I see place for boon)
• trim the obtained data (remove some fields with groovy's collect method)
• send the data to client This is really basic usage.

Will boon parser become a part of groovy? From which version?

Reply to this email directly or view it on GitHubhttps://github.com/RichardHightower/boon/issues/99#issuecomment-38777561 .

Rick Hightower (415) 968-9037 Profile http://www.google.com/profiles/RichardHightower

[Opalo]

Thanks! Will investigate it.

[kimptoc]

Hi @Opalo , any chance of getting access to your repo? I would like to use the DataRepo class, but our production is still stuck at 1.6 :(

Cheers, Chris

[Opalo]

Unfortunately no chance @kimptoc. I've already deleted the whole work :/

[kimptoc]

Oh well, such is life :) might give it a go and see how far I get. Thanks anyway

[kimptoc]

I have a first cut at a jdk16 fork of DataRepo and supporting classes https://github.com/kimptoc/boon

Still needs lots of testing :)

[RichardHightower]

That is awesome!

On Fri, Sep 12, 2014 at 5:03 PM, Chris Kimpton notifications@github.com wrote:

I have a first cut at a jdk16 fork of DataRepo and supporting classes https://github.com/kimptoc/boon

Still needs lots of testing :)

— Reply to this email directly or view it on GitHub https://github.com/RichardHightower/boon/issues/99#issuecomment-55474702 .

Rick Hightower (415) 968-9037 Profile http://www.google.com/profiles/RichardHightower

[RichardHightower]

Don't forget to join.

https://groups.google.com/forum/#!forum/boonjava