27 ms·

The slides which inspired this listing include Guava -- omitted from this list -- an invaluable utility toolbelt that I think is a spiritual re-imagining of Apa

by niftich 10y ago

The slides which inspired this listing include Guava -- omitted from this list -- an invaluable utility toolbelt that I think is a spiritual re-imagining of Apache Commons (... don't read too much into my phrasing, a lot of Apache Commons also quite good, even if API tastes have changed since then). I'll also note that Dropwizard, the framework, came about as an quickstart around an opinionated bundling of quality libraries. Dropwizard's appearance has resulted [1] in the development of Spring Boot, which lowered the barrier to generating Spring applications, arguably finally delivering on the 'convention over configuration' promise that Spring has long suggested it could do, but never quite found the sweet spot. [1] https://news.ycombinator.com/item?id=12283230#12286948 https://news.ycombinator.com/item?id=12283230#12286948

CydeWeys 10y ago
Guava is a notable absence to me. We use it all day every day at work. Speaking of frameworks that Google uses, I'd have to recommend Dagger over Guice: https://google.github.io/dagger/ https://google.github.io/dagger/ People tend to like it more, and it's gaining traction for the kinds of things that people used to default to Guice for. Oh, and the JODA DateTime/Money libraries.
- koolba 10y ago
  There's no need for Joda for datetime with Java 8 as it has sane (immutable!) classes inspired by Joda. And as all prior versions of Java are EOL there's no reason not to be using Java 8.
  - CydeWeys 10y ago
    Java 8 isn't supported quite yet on App Engine :-( Support is in beta, and should hopefully be available "for real" within months, but until it is, we're stuck with the old stuff. I also wonder what kind of data migration we'll be facing, since all of our persisted data is from Joda DateTimes, not Java 8 ones. Hopefully none.
    - niftich 10y ago
      If your datetime is persisted ISO 8601 form, RFC 3339 form, some other unambiguously parseable string form, in epoch form, or as some database-native reliable datetime type, you'll be fine. But if by any chance it's Java-serialized Joda-Time objects, you're going to want to get them out of that form, as the Java-serialized forms are not compatible.
      - koolba 10y ago
        If you're data is persisted in Java-serialized form you should be fired. That's not just for just dates or timestamps either. That's for data period.
        Twirrim 10y ago
        I've horrible memories of WordPress and their obsession with storing PHP serialised objects in the database. It makes a whole lot of things that ought to be simple a lot harder.
        h1d 10y ago
        It was saving different blog data on different tables prefixed by index numbers. It's a mess.
      - CydeWeys 10y ago
        Looks like our native representation in Datastore is java.util.Date, so we should be in the clear. Relevant code here: https://github.com/google/nomulus/blob/master/java/google/registry/model/translators/ReadableInstantUtcTranslatorFactory.java https://github.com/google/nomulus/blob/master/java/google/re...
    - shabbyrobe 10y ago
      Check out the ThreeTen backport for a mostly API-compatible Java 6/7 version of the Java 8 date API: http://www.threeten.org/threetenbp/ http://www.threeten.org/threetenbp/
    - 10y ago
  - toyg 10y ago
    > there's no reason not to be using Java 8. I wish. When life (or rather a vendor) gives you java 6 libs which barely work on java 7, you make java7 lemonade.
    - koolba 10y ago
      What kind of crappy library doesn't work on a newer version of Java? The only thing I can see breaking would be reflection based invocations of new methods on existing interfaces (ex: Foo has a .bar() in Java 7 but not Java 6). You'd have to be doing something pretty unusual for that to bite you.
      - toyg 10y ago
        > What kind of crappy library doesn't work on a newer version of Java? Oracle middleware libraries (to be fair, mostly acquired)... I believe the problem was that in Java 8, something related to StringBuilder or string parsing was breaking hard. With Java7 it was ok, so we went with that.
        koolba 10y ago
        Ah that's not a compatibility issues so much as a change in performance. I think they changed the defaults for String interning. In the vast majority of cases it's be a performance improvement but if you were manually managing lots of small Strings (ex: custom file processor reading misc user input) then it could get out of control.
- meddlepal 10y ago
  So I noticed Guava missing and some other's have cited Joda and I think the real reason is that in 2017 between JSR310 and Java 8 the need for Joda doesn't exist in modern Java dev and a lot of the Guava functionality has been added into Java 8. Not all of it, but the biggest and most useful parts.
  - CydeWeys 10y ago
    Some, but not most, of Guava functionality has been added to the standard libraries in Java 8. We'll still be extensively using it even after switching over to Java 8 specific features for Optional, Function, Date, and all the other goodies.
pjmlp 10y ago
Guava is yet to be green listed in any of the Java projects I worked thus far.

by niftich 10y ago

CydeWeys 10y ago

Guava is a notable absence to me. We use it all day every day at work. Speaking of frameworks that Google uses, I'd have to recommend Dagger over Guice: https://google.github.io/dagger/ https://google.github.io/dagger/ People tend to like it more, and it's gaining traction for the kinds of things that people used to default to Guice for. Oh, and the JODA DateTime/Money libraries.

koolba 10y ago
There's no need for Joda for datetime with Java 8 as it has sane (immutable!) classes inspired by Joda. And as all prior versions of Java are EOL there's no reason not to be using Java 8.
- CydeWeys 10y ago
  Java 8 isn't supported quite yet on App Engine :-( Support is in beta, and should hopefully be available "for real" within months, but until it is, we're stuck with the old stuff. I also wonder what kind of data migration we'll be facing, since all of our persisted data is from Joda DateTimes, not Java 8 ones. Hopefully none.
  - niftich 10y ago
    If your datetime is persisted ISO 8601 form, RFC 3339 form, some other unambiguously parseable string form, in epoch form, or as some database-native reliable datetime type, you'll be fine. But if by any chance it's Java-serialized Joda-Time objects, you're going to want to get them out of that form, as the Java-serialized forms are not compatible.
    - koolba 10y ago
      If you're data is persisted in Java-serialized form you should be fired. That's not just for just dates or timestamps either. That's for data period.
      - Twirrim 10y ago
        I've horrible memories of WordPress and their obsession with storing PHP serialised objects in the database. It makes a whole lot of things that ought to be simple a lot harder.
        h1d 10y ago
        It was saving different blog data on different tables prefixed by index numbers. It's a mess.
    - CydeWeys 10y ago
      Looks like our native representation in Datastore is java.util.Date, so we should be in the clear. Relevant code here: https://github.com/google/nomulus/blob/master/java/google/registry/model/translators/ReadableInstantUtcTranslatorFactory.java https://github.com/google/nomulus/blob/master/java/google/re...
  - shabbyrobe 10y ago
    Check out the ThreeTen backport for a mostly API-compatible Java 6/7 version of the Java 8 date API: http://www.threeten.org/threetenbp/ http://www.threeten.org/threetenbp/
  - 10y ago
- toyg 10y ago
  > there's no reason not to be using Java 8. I wish. When life (or rather a vendor) gives you java 6 libs which barely work on java 7, you make java7 lemonade.
  - koolba 10y ago
    What kind of crappy library doesn't work on a newer version of Java? The only thing I can see breaking would be reflection based invocations of new methods on existing interfaces (ex: Foo has a .bar() in Java 7 but not Java 6). You'd have to be doing something pretty unusual for that to bite you.
    - toyg 10y ago
      > What kind of crappy library doesn't work on a newer version of Java? Oracle middleware libraries (to be fair, mostly acquired)... I believe the problem was that in Java 8, something related to StringBuilder or string parsing was breaking hard. With Java7 it was ok, so we went with that.
      - koolba 10y ago
        Ah that's not a compatibility issues so much as a change in performance. I think they changed the defaults for String interning. In the vast majority of cases it's be a performance improvement but if you were manually managing lots of small Strings (ex: custom file processor reading misc user input) then it could get out of control.
meddlepal 10y ago
So I noticed Guava missing and some other's have cited Joda and I think the real reason is that in 2017 between JSR310 and Java 8 the need for Joda doesn't exist in modern Java dev and a lot of the Guava functionality has been added into Java 8. Not all of it, but the biggest and most useful parts.
- CydeWeys 10y ago
  Some, but not most, of Guava functionality has been added to the standard libraries in Java 8. We'll still be extensively using it even after switching over to Java 8 specific features for Optional, Function, Date, and all the other goodies.

pjmlp 10y ago

Guava is yet to be green listed in any of the Java projects I worked thus far.