Total world domination.
Other goals:
The main goal of Boon is to reduce the productivity delta between Java and Python/Groovy/Ruby.
The idea is to just create a lower ceremony APIs. Less Java like APIs, and more getting things done quickly APIs. That is the goal really.
If reading a file takes one line of code in Ruby/Python/Groovy, then it will also in Java. You really have to check out the Boon I/O library it really takes things to the next level of ease of use.
If slice notation is part of those language, then Boon has to. The best Boon can have in Java syntax. Often times the differences between Boon and some other languages is just a few characters (instead of 20 lines differences). Boon makes easy things easy and tries to be a battery included lib. I am a really big fan of Dart, Go, Python and Groovy. But while I do see some real productivity enhancements, a lot of times the difference is the APIs and libraries. Java developers tend to be masochists. The original version of Boon was called EasyJava if that gives you an idea where my head is.
I used to really hate Ruby. Over the years after using several tools that were built with Ruby my feelings to Ruby have softened. In fact, if I don't know what to call an method or function or API or terminology, I often refer to the Ruby documents for guidance. I started off a big Python and Groovy fan. Then more Groovy and less Python and now I love all three.
Part of this is to make lists, maps, and sets feel like they are part of the core Java language instead of APIs. This includes mimicking map literals, list literals, and set literals.
Boon is a Java celebration. Boon is pro Java. That said if you love some other language and "I have to use Java at work", then Boon is for you. I do things very Java centric like class path resource loading, DI that uses the standard annotations, JSON parsing based on the APIs of Jackson and GSON. I don't shy away from Java roots.
Boon has Reflection, collections, invoke dynamic, unsafe access, slice notation, string manipulation, conversion, validation, universal methods, XPath like queries for objects, SQL like queries for objects, DI, sorting, searching, dependency injection, REST, websocket, messaging, high speed file I/O, etc.
These are areas where Boon will focus.
No. Boon plans on competing with Guava. I am not a very big fan of Guava. I don't hate it.
Boon will have its own collection libs. Boon is not a collection lib so you might find yourself using both Guava and Boon on a project. Boon has a collection query language already. It is still Alpha but it is already useable. Expects even more articles shortly. It is a merger of DataRepo. https://github.com/RichardHightower/datarepo
This is not to say that you can't use Boon and Guava on the same project because you can. Boon is trying to do a lot more than Guava but where it overlaps, I think you will prefer the Boon versions of what Guava provides. If not, then use Guava. Boon is really just a library, it is not a container.
Also Boon works with Sets, Lists, etc. so it is compatible with Guava.
It is to say, that Boon and Guava have different design goals. We would rather do Boon stuff than integration. If you want to create a spin off Boon / Guava remix, then please do.
No. No. No. No. No.
I love Spring and was an early adopter, but lately I have been wooed by CDI and Guice/Dagger. CDI is one of the few things that I love from Java EE. So while once a big fan of Spring, now I am less of a fan, but still have tons of Respect for Spring and the community around Spring.
Spring is a nice integration library that marries disparate frameworks into a cohesive set.
Boon is the polar opposite. Boon never wants to be a one stop super framework for integrating all other frameworks for Java. Boon is very opinionated and unkind. It does not care what is popular. It more cares about what it thinks should be popular.
Core Boon has a no dependencies except the JDK mantra.
Boon is a lib. You can use it with Guice, Struts, Spring, Jackson, CDI, etc., but it will never have dependencies to any of those. NEVER.
Also Boon has its own DI library. It is lightweight and quite refreshing to work with. It is easy to integrate with Spring, CDI, Guice, Dagger and more. It supports many standard annotations and many de facto standards. It works with @Inject, @Autowired, @Named, etc. without depending on any lib but what comes with the JDK.
If I create another framework that is an integration of Boon and Spring or an integration of Vert.x and Boon, it will NOT BE CALLED BOON. It will have another name. There will never be 50 Boon sub-projects Boon will be a Java productivity pack. It will not be a super framework.
I have heard some of the Guice guys complain that Boon is untyped and its semantic can't be guaranteed because it does not support type safety like CDI and Guice. What do you think about that?
Hey man! I think its great that the Guice guys said anything about Boon. I did not know they knew Boon existed. I am flattered. They should know that Silicon Valley is a small place and word gets around.
First and foremost let me say from the bottom of my heart to the Guice team: thanks for thinking of me.
Next, if you want type safety or strongly typed injection or whatever they call what CDI/Weld, Guice and Dagger, then use those. They are great tools. I like Guice. I like CDI. I even like Spring. Also strongly typed injection has been done so why redo it. I imagine most people who use Boon also use Spring and Hibernate. Guice is more of a flea on a dogs butt, but hey Boon is a flea on a fleas butt on a dog's butt.
Boon DI is about being a lightweight config-oriented (JSON based) dependency injection library. There is no class loader monkey business, no code generation, no proxies, etc. There is no complicated XML namespace gak that hides what is really going on. It does not drink the strongly typed CDI/Guice/Dagger/Weld business. I sometimes do drink the strongly typed injection Kool-Aid. Boon is more about config and justing having a lightweight DI then it is about type safe injection.
The difference between Guice/CDI/Weld/Dagger and Boon DI is Boon DI is three small Java classes. Boon DI is loosely typed (duck typing) and is more focused on config. Boon DI is focused on filling in some holes where Java does not quite do object configuration well so I can build things like Play, Rails, Django, etc. with Java.
I did not write Boon DI with the hopes of usurping Spring and Guice. I mostly wrote Boon DI to have a lightweight way to do Java configuration that uses JSON and the @Inject, @In, @Required, @Named, etc. semantics.
If you find that something I wrote in a few hours a few weeks ago is a threat to your DI empire then perhaps you built you castle on a sand pit.
Spring what? DI? AOP?
Spring is a 9,000 pound all consuming gorilla framework, and Boon cannot compete directly with it due to its sheer volume and girth. Yet Boon's goal was never to compete with Spring in the first place so I don't loose sleep.
Boon is not a direct competitor to Spring. Boon does not seek to work with every popular Open Source framework on earth and make the pluggable and then later replace them with Boon alternatives. Boon detests integration.
But where Boon and Spring overlap, I think you will like the Boon versions.
Boon provides alternatives to Spring DI, but it can also be used with Spring DI, CDI and even Guice (so both of the Square employees who use Guice will be happy) (Java EE version of the same). There are clear design goals and decisions that are different with Spring DI.
Boon DI works with standard annotations and is compatible with Spring, CDI, and Guice/Dagger. You can, and might need to switch out Boon DI for Guice/Dagger or CDI or Spring, and we make it easy on purpose. You can also combine Boon DI with Spring, Guice/Dagger and CDI easily.
Boon DI supports 0 XML by choice. (Every now and then I think that I might one day support XML and then I throw up and go into convulsions). Boon DI does support JSON. Boon DI does not to carry around years of DI bloat either. My goal is for all of the Boon DI API to fit in your head. Boon DI will never be a 600 page manual.
Boon DI allows configuration with JSON. Boon loves JSON. You can pretty much do anything with JSON and Boon. You can @Inject JSON. You can create objects with JSON arrays (lists) and JSON objects (maps). You can invoke objects with JSON. Boon tries hard to marry Java and JSON at a very deep level. Boon tries to make JSON feel more like Java Style Object Notation instead of JavaScript Object Notation. Deep integration at every level. Boon lets you index, and search JSON, and invoked Java objects with JSON. Boon wants you to forget where JSON starts and Java stops.
Yes. Some. Boon provides JSON parsing and serialization with speeds comparable and often exceeding GSON and Jackson. Jackson guys have been very supportive of Boon. GSON guys less so (word gets around guys).
If you are looking for a mature stable well tested JSON framework that works well with Android and Java then ** GSON makes a lot of sense to me**. If you are looking for a mature stable well tested JSON framework that works well with every Java REST framework known to man, then Jackson is an obvious choice. If you want to handle JSON like you would XML, then use Jackson.
If you want to use a binary format that is like JSON for Java, then use Jackson. I have used Jackson. I like Jackson. I have a lot of respect for Tatau and Jackson. If you read my blog far enough, you can see that I have used Jackson and Spring REST to great effect.
But... Boon needed its own JSON parser, JSON serializer because JSON is intrinsic to Boon. Boon does things with JSON and Java that other frameworks don't do like DI config files, direct JSON query, direct JSON indexing, direct JSON path expressions, direct JSON search, direct JSON filters, and I want JSON to be as seem-less as working with Java. Boon is not trying to compete against Jackson and GSON. Boon is trying to do something different. JSON is intrinsic to Boon. JSON is in the very DNA of Boon. Boon bleeds JSON so.... Boon JSON parsing is based on an interface and you could plug in Jackson or GSON if you wanted features that they provide that Boon does not have. That said Boon is as fast and often (most often) faster than Jackson and GSON. My goal was to match the speed of Jackson and I over shot a bit.
Boon mimics the GSON and Jackson API realizing that those are the ones people know (I may be dumb but I am not stupid). Boon is not a JSON parser project, but I might have a Boon fork that does nothing but JSON since Boon JSON support seems to get Boon a lot of press but Boon's life mission is not be a JSON parser like Jackson and GSON. I worked on the Groovy JSON parser and Groovy JSON serializer. I offered to help and my patch was accepted. It is a forked version of what comes with Boon, and will ship with the next version of Groovy. I offered to do the same for Vert.x. Why? I love Vert.x and Groovy. Boon is not us versus them. It is a collaboration and learning experience. I would gladly work on the GSON parser to make it faster if asked or invited.
Boon will be compatible with annotations, but never require compile time dependencies on annotations. We don't believe in runtime annotations where the annotations tie your code to a particular framework. It feels dirty and unclean. Boon does use annotations like @Inject, @Named, @JsonProperty, @JsonIgnore, @Exposes, @JsonView, etc.
No. We might have our own lightweight weight ORM (no session / stateless), but we will never integrate with Hibernate or JPA. NEVER. (No plans to do a Hibernate or JPA clone. There are just a lot more interesting things to do.) I am not against JPA or Hibernate but if it is not in the JDK we don't integrate with it. One jar!
We do like them. Boon is not an integration lib. I am not anti-Spring. Boon is a drop-a-jar-file-into-your-project-and-start-using-our-lib lib and it works. One jar. One jar. Just one jar.
No. Boon has its own JSON parser and we plan on doing JSON serialization as well as a new binary format that is similar to Hessian, Avro, ProtocolBufs, but simpler and easier to port and will work with Python, PHP, Ruby, and Go.
We have a custom configuration format that is not XML, and not JSON (it is lax JSON that allows comments). It is just for Java configuration, and DI.
No. Benchmarks show that Boon is comparable but slightly faster in many use cases and in some use cases 2x to 3x as fast as Jackson (GSON is usually slower than Jackson). Boon seems to have the fastest JSON parser and JSON serializer/deserializer based on benchmarks (quite a bit faster, but realize that others can optimize their libs so it can only be faster at a give point in time so it seems to be faster right now Feb 2014).
No. It is on the roadmap. Soon. Boon wants to have the lightest weight, all-Java, fastest, web framework. I need to implement the template framework.
Boon favors Vert.x over Java EE. The Boon web framework will not be called Boon. Boon core will always just be called Boon. Any other libs that build on top of Boon that have dependencies will have a different name.
We don't. Well we do but only for universal methods.
Universal methods are like operators. Think of the method idx as the universal getter/setter.
idx is an operator that means index of.
len is an operator that means length of.
slc is an operator that means slice of.
You can use len, idx, and slc with collections, maps, Java Beans, etc.
Boon added lengthOf, atIndex, sliceOf, endSliceOf, etc. Java diehards love verbosity. Sometimes it is better not to fight.
I might add lengthOfAStringPassedToTheArgumentOfThisMethod? Just kidding.
Yes. There is org.boon.Str (slice notion, universal methods, common String methods), org.boon.StringScanner, and org.boon.core.Conversions. The string manipulation is getting bigger and bigger. I need to write a document.
We have a lib that does byte searching, char searching and string searching. We try to do our searching as close to the metal as possible for speed, and to avoid copying large arrays around.
Our plan is to have the best, fastest search / string manipulation lib that really reduces copies of arrays.
I've done some benchmarks and Boon string manipulation is now 2x faster than what you could to with the JDK equivalent for String manipulation.
We have our own ByteScanner, CharScanner, and StringScanner.
ByteScanner:
byte[] letters =
bytes("This is a string ");
byte[][] splitted = ByteScanner.split(letters, ' ');
assertEquals (
4,
splitted.length
);
assertArrayEquals (
bytes("This"),
splitted[0]
);
...
CharScanner:
char[] letters =
chars("This is a string ");
char[][] splitted = CharScanner.split(letters, ' ');
assertEquals (
4,
splitted.length
);
assertArrayEquals (
chars("This"),
splitted[0]
);
There is a StringScanner too.
We also have our own CharBuf, and ByteBuf to reduce copies of arrays, and to make dealing with bytes and char arrays easier.
We do. No docs yet. It is based on validation framework from Crank (another framework that I worked on). Boon is not just me, but it is quite a bit me (90%). I hope that will change, but I need to find some like-minded who are smart dudes who would like to work a lot of hours for free who are not already on another project so Unicorns really. I need to find Unicorns. Until then, Rick=Boon. Without Stephane Landelle, Boon would not be near as good as it is now. Stephane also added Boon to the global maven repo. I really want to recruit others. I have been heavily recruiting Brian D., Paul H., Chris M., Geoff C., Tom C., but they all have lives. :)
Yes, but currently it just works against collections, JSON, Maps, Java Objects, and more.
See https://github.com/RichardHightower/datarepo
We plan (sometime way in the future) to support queries against SQL and JMX, but no time too soon.
Crank had something very close to Spring Data, but years before Spring Data (long story). I'd like to revisit that at some point, but if Boon has something like Spring Data it will be built to talk directly to JDBC not Hibernate or JPA.
No. But sort of Yes. But really no.
Boon might have a REST framework. It has a JSON invoker lib that will allow you to easily expose Java as JSON based REST endpoints with Vert.x, Netty and Servlet. Boon has to be Boon. Boon is just about core Java. There will not be Boon-REST, Boon-WebSocket, Boon-SQL, etc. There will just be Boon. With Boon and Servlets or Boon and Vert.x or Boon and Vert.x, Boon will enable easy REST endpoints but will not depend on Servlets, Netty or Vert.x. :)
It will make more sense soon. Boon is just a lib.
I thought of how I wanted to do it after I wrote the DI framework and the fromList. I was working out on Feb 2014 (day after Valentine's day), and I had an idea pop into my head. I already use JSON to Java constructors (with recursive type checking works with JSON array, List, Map and JSON object), it would be small potatoes to do this for a method call. Update: I implemented that already. So I am about 4 hours from creating a 1 line of code REST framework. Update I have it and have used it already. :)
I am not a big fan of JAX-RS. I like Spring REST and love Grails REST and Python REST support but do not like JAX-RS. Not even a little bit. NOT. EVEN. A. LITTLE. BIT. BLOAT! I hate when I get a JAX-RS project and I can't find the code for all of the annotations. If you need 30 annotations to annotate two lines of Java code then something is really, really wrong. If this is what annotations means to you, then I hate annotations. Boon will create something more inline with Grails REST/Python Django for plain Java REST.
Yes and no. Boon has one, but it will be rewritten soon. It is based on JSTL, Handlebars/Mustache, Velocity or Freemarker syntax. The expression parsing and path resolution is just plain old Boon Paths Expressions. A lot of work was done on Boon Path expressions. I realized that I made some mistakes in the core template parser so that will have to be rewriten for speed, but it works and is in Boon already, but I am not 100% proud of it yet, and won't talk about it much until I rewrite the parser.
I view templating as vital for the mission of Boon. I have written a few. I will wrote one for Boon. It will be better. It is like Handlebars++ and when it is done, I will not stop talking about it. Right now my focus is on documentation of core Boon features. When I wrote Crank it had a lot of features, but I never go the word out and then later those features were copied into other frameworks, and Crank sort of withered on the vine. I need to balance Boon development with Boon documentation. I prefer to code. :) I must document. Just like Boon has the fastest JSON parser, Boon will have the fastest Handlebars parser, and it will be faster than Freemarker and Velocity. :)
Mostly no. It has Path Expressions only, and it has a built-in Criteria API. Boon has a way to easily index into an object with the syntax "company.department[0].employee.firstName" which would get all of the employees first name in the first department of the company object and it has "company.departmentMap["engineering"].employee.firstName" which does the same thing but for a map.
So it has a GPATH like thing but no expression >, <, == expressions -- yet. It has an expression DSL, and a sorting DSL. But... Anyway.. It really needs a first class expression language something like OGNL. I reached out to Drew D. for help. But I am looking to get a real expression language as part of Boon. I might have to just write one from scratch.
- Get core done and up to 90% plus code coverage (core.. what is core? Not sure. It changes.)
- Core includes string manipulation, JSON parsing, JSON serialization, slice notation, universal methods, I/O utilities, Conversions utils, reflection, process management, configuration, benchmarking framework, JMX, templating, expressions in strings, scheduler, etc.
- Document and promote the core.
- Should be feature compatible with base Groovy/Python/Ruby string manipulation, slice notation and dynamic objects (as much as possible), process management, and I/O.
- Performance tuning. When Boon does something. It should always strive to be the fastest and easiest to use. (See JSON performance to see that we lived up to this promise and see that the date of the promise in git and you will see that we are living up to what we have promised.)
The first five items go on in parallel for some time.
- Write a logging framework that adds log4j features (formatting) to standard JDK w/o depending on any libs. Output to log4j, standard logging w/o compile time dependencies (using invoke dynamic) (Feb 2014-NOTE DONE)
- Lightweight easy-to-use, no-byte-code manipulation DI framework, no annotations required (March 2014 - DONE)
- REST framework, no annotations required, no dependencies, easy to configure, FAST! This one will integrate with Servlet API (Jetty), Vert.x, as well as its own. 100% JSON. No XML. JSON invocation. (DONE)
- Boon universal object serialization format similar to Avro, Hessian, Thrift, and Google protocol Bufs (May 2014). Port this to Ruby, Python, PHP, and create tons, and tons of documentation so it is really easy to use. (I may give up on this one as Java JSON seems good enough. And JSON lists instead of JSON maps which Boon supports so JSON Lists + GZIP is close enough for my current needs, but I really want do this). Find more details on what I am thinking on this subject at: http://rick-hightower.blogspot.com/2013/10/dreaming-about-boon-object.html
- Get Criteria API to work against SQL (lists, maps only) (DROPPED FROM LIST).
- Create SQL serialization/deserialization framework (DROPPED FROM LIST).
No. But we think they are a bit bloated, and complicated. I want Boon to allow Django/Rails/Grails style programming with plain old Java. So Java without the JavaFactoryFactory, Annotation hell, complicated config, etc. Java without the XML namespace configure wild stuff, mess with the classlaoder, stack traces longer than my arm, etc. Boon is a work in progress (still has some wicked long stack traces, but I am working on it).
Spring jumped the shark a long time ago. It started off as light a refreshing. Spring sprung along time ago. It should be renamed winter or perhaps fall.
Spring at least started out as light weight. Other went right for the shark tank, skis, and speed boats without passing go.
Boon is also looking at what is out there now, and deciding what is worth keeping, and if we can improve.
You can use Boon with them. Boon does not compete against them.
I want my programming life to be easier so I can focus on providing value instead of screwing around with 50 or so dependencies or a super complicated API, high ceremony API. Have you ever had a 30MB war file. I have. It sucks. I want to avoid that.
XML. Annotations. Java EE.
They all have there place but Boon will not have nothing to do with any of them.
I will use Spring and Guice from time to time. But Boon will not integrate with them.
I used to. I like strongly typed languages.
I prefer Java. I am a Java guy. To each his own.
I LOVE Groovy. Groovy already has this stuff in it. Groovy is its own language so it is not confined like Boon is. Groovy extends the Java language to make JVM development easier. Boon writes an easy-to-use set of Java APIs to make JVM development easier. Boon will try to do Groovy like things within the confines of Java syntax.
Go ahead. More power to you.
Those are great tools.
I don't ever use them personally, but feel free.
Not directly. You could use Boon with Java EE. I am not anti-Java EE, I personally prefer Vert.x and Netty. Tomcat gives me the heebie jeebies. Jetty is nice, but lately, I prefer Vert.x.
No. There is some overlap, but not intentional. Boon does not want to be an enterprise cache or a distributed data grid.
Yes. Boon plans on destroying MongoDB. Boon is mortal enemies with MongoDB. The Java API that ships with MongoDB is one of the reasons why I wrote Boon. Never have a seen an API that is in utter contempt of Java. It may take years, but MongoDB is the ultimate target of destruction. I am kidding.
No. Never. Boon has some HTTP libs but they are based on java.net.URL. I'd like to make it pluggable so you can use Vert.x or Netty as underpinnings but probably not. I never plan on rewriting or competing with Netty or Vert.x. I like them.
If you can use Groovy at work, please do. Nice language. Great platform. If you have a choice between Groovy/Grails or Boon, pick Groovy/Grails. Seriously. I am a fan. If Boon has some features that Groovy / Grails don't have, use Boon with them, but otherwise use Grails. You will get more stuff done if you use Grails versus Java EE. Seriously, if you can get away with it, use Groovy and Grails. I mostly use Java because that is what I get paid to use. I am pro Groovy. I am a big fan of Dart, Go, and Groovy. I focus on Java because it is popular and I figure it is better to be a master of one than a generalist in many. When I have used Dart, Go and Groovy... they have given me great joy (Python too).
Boon is a Java productivity lib. Its focus is on core Java and making it easier. You can use it with Java EE, or Spring or Grails, but it is limited to Java productivity.
Think JSON, Java collections (sort, search, filter,etc.), config files, lightweight DI, templating, small expression lang, etc.
No. Lightweight interception is on the roadmap. But nothing beyond what the JDK supports directly.
No. Never. It is a utility lib not a container.
No. Never. I don't want Boon to be hard to use with Vert.x, Tomcat, JBoss, Jetty or whatever. Just use it. It does not do runtime generation of classes.
No. Don't know how. Someone else can port to Android if they want to. I accept help. I have limits in knowledge and time, and Android is a blind-spot.
It is about 400K or so now and there is only one more major feature that I want to add (templating, and a better expression language). I think.... It can be shrunk down to something smaller. In fact there are some things that need a major overall and refactor (data repo and validation come to mind). I don't forsee a ton of new features just refinements on ones that exist, but the refinements are another 30 to 40%. So although the scope of Boon is large, it has a limit and that limit is has been reached. It needs refinement not additions.
We might break out the JSON support into a separate project. (Code that I port back and forth with a different root package but basically the same code base shrunk down to focus on JSON. I started this when I ported to JSON parser to Groovy).
Most of the work I do is on the server side. I think there are utilities that can shake the jar down to a smaller size for Android et al, but the basic vision is that it just is used as is.
Just not sure that 400K vs. 700K matters for most folks. It does not matter to me. I got forwarded an email from a GSON commiter where he commented on the code size. It has not been a design concern, but someone I know is looking to see if we can break Boon up into many smaller jars. So one project, but different jars produced for different profiles. If it works, then I will have my cake (one jar), and eat it too (small JSON lib).
The goal of Boon was never to be a small jar file that could get used on Android.
(I actually hate Android and am a big iOS/OSX guy so... if it happens it will not be because I need it personally. It will be because someone else wants it and makes it happen. I had 5 Android devices. NOT. A. FAN. AT. ALL. )
If not it will continue to get bloated. I have limits in knowledge and time, and Gradle is a blind-spot.
I see it being about 1MB for the all in one boon.jar. And unless I get help, there will just be an all in one jar (but maybe a JSON parser separate project).
This project would not be anywhere without help from a lot of people so while I wrote most of the code, many people have been involved including key adopters who provided feedback and without them Boon would be a list of fantasy on my blog. Also many ideas for code has come from other projects, stackoverflow, etc. I have accepted patches, and I'd love more help.
I am a big fan of Rod Johnson (and the other Spring guy with the German name), Gavin King, Tatau, Bob Lee, Scott Ferguson, Martin Thompson, Tim Fox, Guillaume Laforge, Guido van Rossum, Allen I. Holub, Stephane Landelle, Hiram Chirino and many more. They inspire me. Sometimes not just what to do, but what not to do. I have my own programming style and at my age I embrace it.
Thoughts? Write me at richard high tower AT g mail dot c-o-m (Rick Hightower).
If you are new to boon start here:
- Java Boon Byte Buffer Builder
- Java Boon Slice Notation
- Java Boon Slice's work with TreeSets
- Java Boon Description
- More...
- Boon Home
- Boon Source
- Introducing Boon October 2013
- Java Slice Notation
- What if Java collections were easy to search and sort?
- Boon HTTP utils
- Boon Java JSON parser Benchmarks or hell yeah JSON parsing is damn fast!
- Boon JSON parser is really damn fast! Part II
- Boon JSON parser Round III now just not fast as but much faster than other Java JSON parsers
- Boon World's fastest Java JSON parser Round IV from fast to blazing to rocket fuel aka Braggers going to brag
- Boon gets adopted by JSON Path as the default Java JSON parser
- Boon graphics showing just how fast Boon JSON parsing is - about 50% to 200% faster than the graphs shown here now so wicked fast became wickeder - just got sick of making graphics
- 10 minute guide to Boon JSON parsing after I added @JsonIgnore, @JsonProperty, @JsonView, @Exposes, etc.
- Hightower speaks to the master of Java JSON parsing, the king of speed The COW TOWN CODER!
- Boon provides easy Java objects from lists, from maps and from JSON.
Easily read in files into lines or a giant string with one method call. Works with files, URLs, class-path, etc. Boon IO support will surprise you how easy it is. Boon has Slice notation for dealing with Strings, Lists, primitive arrays, Tree Maps, etc. If you are from Groovy land, Ruby land, Python land, or whatever land, and you have to use Java then Boon might give you some relief from API bloat. If you are like me, and you like to use Java, then Boon is for you too. Boon lets Java be Java, but adds the missing productive APIs from Python, Ruby, and Groovy. Boon may not be Ruby or Groovy, but its a real Boon to Java development.
Core Boon will never have any dependencies. It will always be able to run as a single jar. This is not just NIH, but it is partly. My view of what Java needs is more inline with what Python, Ruby and Groovy provide. Boon is an addition on top of the JVM to make up the difference between the harder to use APIs that come with Java and the types of utilities that are built into Ruby, Python, PHP, Groovy etc. Boon is a Java centric view of those libs. The vision of Boon and the current implementation is really far apart.
=== Boon size
Boon is at 107,627 lines of code as of March 16, 2014.
===
Contact Info
blog|[twitter](https://twitter.com/RickHigh|[infoq]http://www.infoq.com/author/Rick-Hightower|[stackoverflow](http://stackoverflow.com/users/2876739/rickhigh)|[java lobby](http://java.dzone.com/users/rhightower)|Other | richard high tower AT g mail dot c-o-m (Rick Hightower)|work|cloud|nosql
YourKit supports Boon open source project with its full-featured Java Profiler. YourKit, LLC is the creator of innovative and intelligent tools for profiling Java and .NET applications. Take a look at YourKit's leading software products: YourKit Java Profiler and YourKit .Net profiler.
