FAQ

What are the goals of Boon?

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. If reading a file takes one line of code in Ruby/Python/Groovy, then it will also in Java. If slice notation is part of those language, then Boon will have it to.

Part of this is to make lists, maps, and sets feel like they are part of the core language instead of APIs. This includes mimicking map literals, list literals, and set literals.

Boon is a Java celebration. Boon is pro Java.

Reflection, collections, invoke dynamic, unsafe access, slice notation, string manipulation, conversion, validation, universal methods, XPath like queries for objects, SQL like queries for objects, etc.

These are areas where Boon will focus.

Do you plan on integrating with Guava?

No. Boon plans on competing with Guava. Boon will have its own collection libs. Boon has a collection query language already. It is still Alpha but it is already useable. Expects some 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.

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.

Do you plan on integrating with Spring / CDI / Guice / Struts / Wicket / etc.?

No. No. No. No. No. Spring is a nice integration library that marries disparate frameworks into a cohesive set. Boon is the polar opposite. Core Boon has a no dependencies except the JDK mantra.

Boon is a lib. You can use it with Guice, Struts, Spring, CDI, etc., but it will never have dependencies to any of those.

Also, a lightweight non-byte-code-manipulation injection framework is on the roadmap.

How do you feel about annotations?

Boon will be compatible with annotations, but never require them. We don't believe in runtime annotations where the annotations tie your code to a particular framework.

Will you integrate with Hibernate or JPA?

No. We might have our own lightweight weight ORM (no session / stateless), but we will never integrate with Hibernate or JPA.

Do you not like Hibernate, Spring, Guice, etc.?

We do like them. Boon is not an integration lib. Boon is a drop-a-jar-file-into-your-project-and-start-using-our-lib lib.

Do you plan on integrating with Jackson?

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.

We also plan on creating a custom configuration format that is not XML, and not JSON. It is just for Java configuration, and DI.

Isn't Jackson faster? It might be. It also might have more features. Our plan is to be faster than Jackson. But, we have bigger fish to fry at the moment.

Boon wants to have the fastest JSON parser and JSON serializer/deserializer.

Does boon have a web framework?

No. It is on the roadmap.

Boon wants to have the lightest weight, all-Java, fastest, web framework.

Boon favors Vert.x over Java EE.

Why does boon use such short method names?

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.

Does boon have a string manipulation lib?

Yes. There is org.boon.Str (slice notion, universal methods, common String methods), org.boon.StringScanner, andorg.boon.core.Conversions.

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.

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.

Does boon have a validation framework?

Not yet. But we plan on merging the validation / conversion framework from Crank.

Does Boon have a Criteria API?

Yes, but currently it just works against collections. See https://github.com/RichardHightower/datarepo

We plan (sometime way in the future) to support queries against SQL and JMX.

Does Boon have a REST framework?

No but it will. This will be a separate project.

What are the priorities?

Get core done and up to 90% plus code coverage.

Focus on 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.

Friendly error messages.

The first five items go on in parallel for some time.

Then later on....

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)

Lightweight easy-to-use, no-byte-code manipulation DI framework, no annotations required (March 2014)

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. (April 2014)

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. 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).

Create SQL serialization/deserialization framework.

Do you dislike Java EE and/or Spring?

No. But we think they are a bit bloated, and complicated.

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.

Why Boon?

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.

What things does Boon try to avoid?

XML. Annotations. Java EE.

They all have there place but Boon will not have nothing to do with any of them.

Do you dislike Ruby?

Sometimes. I like strongly typed languages.

Why not write this in Scala?

We prefer Java.

Why not write this in Groovy?

We like 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 with the confines of Java syntax.

Why not just use Apache Lang and Apache I/O?

Go ahead. More power to you.

Those are great tools.