Updated Boon FAQ

Boon FAQ

What are the goals of Boon?

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 do 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 for Java.

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  (like so):

     favoritesMap = sortedMap(
            2, "pineapple",
            1, "oranges",
            3, "apple"
     );


     map =    map (
        "pineapple",  2,
        "oranges",    1,
        "apple",      3
     );

     assert idx( veggiesSet, "b").equals("broccoli");

     assert idx( fruitList, 1 ).equals("oranges");

     assert idx( fruitArray, 1 ).equals("oranges");

     assert idx( letters, 1 ) == 'b';

     assert idx( bytes, 1 )      == 0x2;

     assert idx( favoritesMap, 2 ).equals("pineapple");

     assert idx( map, "pineapple" )  == 2;

Boon is a Java celebration. Boon is pro Java. That said if you love some other language and  your attitude is "I have to use Java at work", then Boon is for you.

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, web-socket, messaging, high speed file I/O, 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. 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. 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.

Also Boon works with Sets, Lists, etc. so it is compatible with Guava.
Example of searching through a list.

List<Employee> results = query(employees, eq("firstName", firstName));

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.

Another example (I could write a 100 page book on what Data repo has and it works with JSON, Java and List/Maps direct):

 List<Employee> employees = repo.query(
          and(eq("firstName", "Diana"), eq("lastName", "Smith"), eq("ssn", "21785999")));

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

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. It depends on junit for testing and nothing else but the JDK.

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.

Do you plan on competing with Spring?

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.

Boon is not a direct competitor to Spring. Boon does not seek to work with every popular OS framework on earth and make them pluggable and then later replace them with Boon alternatives.

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 and CDI (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. Boon DI does support JSON. Boon DI does not to carry around years of DI bloat. 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). 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.

Does Boon compete with Jackson/GSON?

Yes. Some. Boon provides JSON parsing and serialization with speeds comparable and often exceeding GSON and Jackson. 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 back, you can see that I have used Jackson and Spring REST to great effect.

But... Why did I need to write my own JSON parser, JSON serializer? Because I want to do things with JSON and Java that other people don't do like DI config files, direct JSON query, direct JSON indexing, direct JSON search, direct JSON filters, JSON config files, and I want JSON to be as seem-less as working with Java. I am not trying to compete against Jackson and GSON. I am trying to do something different. JSON is intrinsic to Boon if that bothers anyone, I don't care. 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. Let me know what those features are and I will add them. I support quite a few already.

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 be a JSON parser/serializer like Jackson and GSON. I don't want to compete anyway. I want to cooperate. I recently worked on the Groovy JSON parser and JSON serializer. I offered to help and my patch was accepted. It is a forked version of what comes with Boon, and the next version of Groovy will have a faster parser than Jackson and GSON. 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'd be happy to help the GSON guys tune GSON if they asked. Jackson would be harder for me to help on because the coding style is a lot different than I am comfortable with. I just wanted Boon to be comparable to Jackson and GSON. It is.

How do you feel about annotations?

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.

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. NEVER. (No plans to do a Hibernate or JPA clone. There are just a lot more interesting things to do.). If I were going to do an ORM mapper, I would do a JSON to SQL mapper. I would serialize to JSON (or java.util.List and java.util.Map) which gets serialized to SQL. Why? Hibernate and JPA already exist. So doe iBatis or uBatis or whatever it is called. They are good enough. But.. I might do something with SQL one day with Boon.

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

We do like them. Boon is not an integration lib. I am not anti-Spring or Guice/Dagger or Jackson or whatever. 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.

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 and works 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.

Boon ships with an IO library that makes it easy to read/write from URLs, and other file systems:

        User userFromURL = mapper.readValue( IO.read("http://fromsomewebsite/user.json"), User.class );
        puts ( "userFromURL", userFromURL );

Boon also makes making JSON calls to REST webservices easy as you can use Boon's HTTP utilities as follows:

         String results = HTTP.postJSON("http://foo.com/bar/add/user", mapper.writeValueAsString( user ) );
         AddUserResponse response = mapper.readValue( results, AddUserResponse.class );

Here is an example of getting a listing of users from a REST call:

         List <User> userList = mapper.readValue( HTTP.getJSON("http://foo.com/bar/user/listing"), 
                                            List.class, User.class );

Isn't Jackson faster?

No. Benchmarks show that Boon is comparable but slightly faster in many use cases and in some use cases 2x to 4x as fast as Jackson (GSON is usually slower than Jackson). Boon seems to have the fastest JVM 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).

Does boon have a web framework?

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. But it will never be tied to web... so... Hard to explain. No time now. I'll show when its done which looks like 2015 at the moment. :) On the list, but not high. REST will be first. 

Boon favors Vert.x/Netty over Java EE.

Why do you 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.

I might add lengthOf, indexOf, sliceOf, endSliceOf, etc. Java diehards love verbosity. Sometimes it is better not to fight. There will be both. Boon "operator" are suppose to look like Python operators. (I get inspiration from Ruby, Groovy, Perl and Python. I point out in the docs where I got the idea for a method name.)

I might add lengthOfAStringPassedToTheArgumentOfThisMethod? Just kidding.

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

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?

We do. It is based on validation framework from Crank (another framework that I wrote).

RequiredValidator required = Validators.required("phone number required");


        ValidatorMessage message = (ValidatorMessage) required.validate(null, "Phone Number");


        boolean ok = true;

        ok |= message.hasError() || die("Phone number is required");


        message = (ValidatorMessage) required.validate("", "Phone Number");


        //Empty strings don't count!
        ok |= message.hasError() || die("Phone number is required");

Boon is not just me, but it is quite a bit me (90% less as time goes on). I hope that will change, but I need to find some like-minded dudes who would like to work a lot of hours for free who are not already on another project. 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.

Does Boon have a Criteria API?

Yes, and it currently 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.

Does Boon have a REST framework?

No. But sort of Yes. But really no.

Boon will never have a REST framework. It will have 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. :) No magic. You will have to write code. 

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. So I am about 4 hours from creating a 1 line of code REST framework. :)

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 methods 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 for plain Java.

Does Boon have a templating system?

No. But it will. I view templating as vital for the mission of Boon. I have written a few. I will write one for Boon. It will be similar to Handlebars++.

Does Boon have an expression language?

Mostly no. It does have 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 true expression language. It has an expression DSL, and a sorting DSL. But... Anyway.. It really needs a first class expression language something like OGNL. I contacted the key OGNL guy and personal friend for help but so far... no response.

What are the priorities?

1. Get core done and up to 90% plus code coverage (core.. what is core? Not sure. It changes.)
2. 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(maybe out of scope now), etc.
3. Document and promote the core.
4. 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.
5. Performance tuning. When Boon does something. It should always strive to be the fastest and easier 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.

1. 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)
2. Lightweight easy-to-use, no-byte-code manipulation DI framework, no annotations required (March 2014 - DONE)
3. 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 - NOT DONE but on schedule)
4. 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
5. Get Criteria API to work against SQL (lists, maps only) (DROPPED FROM LIST).
6. Create SQL serialization/deserialization framework (DROPPED FROM LIST).

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. Compile time dependent 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 and I learned Python first so I have affinity towards Python and Groovy, but I have learned to like Ruby.

Why not write this in Scala?

I prefer Java. I am a Java guy. To each his own.

Why not write this in Groovy?

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. But go ahead use Groovy. 

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

Go ahead. More power to you.

Those are great tools.

I don't ever use them personally, but feel free.

Do you plan on competing with Java EE?

Not directly. You could use Boon with Java EE. I am not anti-Java EE, I personally prefer Vert.x and Netty.

Do you plan on competing against Hazelcast?

No. There is some overlap, but not intentional. Boon does not want to be an enterprise cache or a distributed data grid.

Do you plan on competing against MongoDB?

Yes. Boon plans on destroying MongoDB. Boon is mortal enemies with MongoDB. It may take years, but MongoDB is the ultimate target of destruction. (mostly kidding)

Do you plan on competing with Netty and Vert.x?

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.

Do you plan on competing against Groovy?

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

So What is Boon again?

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.

Do you plan on supporting AOP?

No. Lightweight interception is on the roadmap. But nothing beyond what the JDK supports directly.

Do you plan on supporting custom classlaoders?

No. Never. It is a utility lib not a container.

Do you plan on supporting byte code manipulation?

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. I don't exclude the possibility form other libs I write, but never in Boon.

Do you plan on supporting Android?

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.

Will Boon get bloated?

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

Did you work on it alone?

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

Thoughts? Write me at richard high tower AT g mail dot c-o-m (Rick Hightower).

Further Reading:

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.

Why Boon?

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 Philosophy

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.

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