Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reasons to use Guava

insightfullogic.com

Post reply on HN
Print view View original

1–10 of 50 posts

Re: Reasons to use Guava

#2

Post by haasted »

Adding to #1 :

Using static imports to import the newHashMap() method can make the statement even shorter :

  final Map> lookup = newHashMap();
This serves to make the code far more readable.

Re: Reasons to use Guava

#3

Post by ooohhhddeeaarrr »

haasted wrote: post #2

Adding to #1 : Using static imports to import the newHashMap() method can make the statement even shorter : final Map > lookup = newHashMap(); This serves to make the code far more readable.

If I were writing the code to use, I would do exactly that. Since it was a explanatory tutorial, I wanted people to see what was happening. Later on I've used static imports after explaining what classes they need to look at for the code. I totally understand your point of view though.

Re: Reasons to use Guava

#4

Post by latch »

I don't follow Java development, but I have worked in it occasionally, and every time I do something in it, I'm inevitably surprised by having to use one of this commons libraries for something basic.

Is there a reason some of this stuff isn't added to the base framework?

Re: Reasons to use Guava

#5

Post by netmau5 »

latch wrote: post #4

I don't follow Java development, but I have worked in it occasionally, and every time I do something in it, I'm inevitably surprised by having to use one of this commons libraries for something basic. Is there a reason some of this stuff isn't added to the base framework?

The important algorithms are in the core library. This is a more friendly API to use both collections and operations on them. And while I love what Guava brings to the table, I do not agree with bringing API candy into base Java. When it comes to heavily used things like collections, this is obviously a gray area. My preference is that they obsolete the need for several of these things at the grammar-level with list/map syntax and [real] closures.

Re: Reasons to use Guava

#6

Post by guard-of-terra »

haasted wrote: post #2

Adding to #1 : Using static imports to import the newHashMap() method can make the statement even shorter : final Map > lookup = newHashMap(); This serves to make the code far more readable.

In bolts, it's

  Map> lookup = Cf.hashMap();
Which is as short and also doesn't require static imports.

Bolts are the state of art FP library for java.

https://bitbucket.org/stepancheg/bolts/src/tip/src/main/java... some examples in tests

Re: Reasons to use Guava

#7

Post by Nitramp »

latch wrote: post #4

I don't follow Java development, but I have worked in it occasionally, and every time I do something in it, I'm inevitably surprised by having to use one of this commons libraries for something basic. Is there a reason some of this stuff isn't added to the base framework?

- Java has historically included things in its standard library that (presumably) everyone regrets nowadays, like CORBA support. The standard JRE is already overweight. Also keep in mind that size matters for Java - in theory, it's a client side environment that's downloaded and installed by consumers (of course, in practice nobody does that anymore).

- The standard library has to be implemented by all JVM vendors, so adding lots of stuff to it that can also easily be shipped as a library creates a lot of unnecessary effort.

- Changes to the Java standard library have to go through a committee process (JCP); again, it's probably just not worth the effort.

Re: Reasons to use Guava

#8

Post by power »

And one reason not to: http://code.google.com/p/guava-libraries/issues/detail?id=36...

Java 6 source was introduced without explicit intention and once detected was not addressed. Many companies would not use something whose vital dependencies change on a whim or oversight. A lot of shops are still using Java 5 compilers and have no immediate plan to upgrade. Some cannot upgrade conveniently.

Re: Reasons to use Guava

#9

Post by efsavage »

power wrote: post #8

And one reason not to: http://code.google.com/p/guava-libraries/issues/detail?id=36... Java 6 source was introduced without explicit intention and once detected was not addressed. Many companies would not use something whose vital dependencies change on a whim or oversight. A lot of shops are still using Java 5 compilers and have no immediate plan to upgrade. Some cannot upgrade conveniently.

While a silent unilateral change is bad form, as is requiring an upgrade for a minor feature like this, Java 6 is almost 5 years old now...
Post reply on HN