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

JDK 8 calendar builder

marxsoftware.blogspot.co.il

Post reply on HN
Print view View original

1–9 of 9 posts

Re: JDK 8 calendar builder

#2

Post by RyanZAG »

To be honest, this just seems like bloating the JRE even further with stuff that can be in a library (and is - JODA time?). I can't wait for Java 9 (I think?) that will finally work on modularising the JRE so I don't have to include most of this stuff if not needed...

Re: JDK 8 calendar builder

#3

Post by mythz »

A good example of bloatware encouraged by a non-expressive language. Instead of adding a language feature that makes constructing any instance easier, in 2013 they're adding support for a builder on a single Calendar class.

    final Calendar calendar =  
       new Calendar.Builder()  
         .set(YEAR, 2013)  
         .set(MONTH, APRIL)  
         .set(DATE, 6)  
         .build();
For a similar API in C# you could use named parameters:

   var calendar = new Calendar(year:2013, month:Month.April, date:6);
or just set public properties in an object initializer:

    var calendar = new Calendar { 
      Year = 2013,
      Month = Month.April,
      Date = 6,
    };
Likewise in Dart with named parameters:

   var calendar = new Calendar(year:2013, month:APRIL, date:6);
or using method cascades:

    var calendar = new Calendar()
      ..year = 2013
      ..month = APRIL
      ..date = 6;
For C#, Dart you get this for free when constructing any object. Java requires creating the boilerplate of a builder for every class?? and with all that effort it's still more verbose.

Re: JDK 8 calendar builder

#4

Post by Someone »

mythz wrote: post #3

A good example of bloatware encouraged by a non-expressive language. Instead of adding a language feature that makes constructing any instance easier, in 2013 they're adding support for a builder on a single Calendar class. final Calendar calendar = new Calendar.Builder() .set(YEAR, 2013) .set(MONTH, APRIL) .set(DATE, 6) .build(); For a similar API in C# you could use named parameters: var calendar = new Calendar(yea…

Method cascades do not guarantee that the object gets properly initialized. Let's say you do

    var calendar = new Calendar()
      ..year = 2013
      ..date = 6;
Neither the year setter nor the day setter can throw, as they cannot know that there is no month setter in your code.

So, what month is the date set to after that code? Builder.build(), on the other hand, can throw when called on a partly initialized builder. A builder also can (I don't know whether Java's builder do this) accept variants such as:

   Builder.setYear(2012).setDay(60); // February 29

   Builder.setYear(2000).setDay(MONDAY).setWeek(14);
   // Monday of week 14 of week 2000
So, builders have their advantages.

Re: JDK 8 calendar builder

#7

Post by mythz »

Someone wrote: post #4
mythz wrote: post #3

A good example of bloatware encouraged by a non-expressive language. Instead of adding a language feature that makes constructing any instance easier, in 2013 they're adding support for a builder on a single Calendar class. final Calendar calendar = new Calendar.Builder() .set(YEAR, 2013) .set(MONTH, APRIL) .set(DATE, 6) .build(); For a similar API in C# you could use named parameters: var calendar = new Calendar(yea…

Method cascades do not guarantee that the object gets properly initialized. Let's say you do var calendar = new Calendar() ..year = 2013 ..date = 6; Neither the year setter nor the day setter can throw, as they cannot know that there is no month setter in your code. So, what month is the date set to after that code? Builder.build(), on the other hand, can throw when called on a partly initialized builder. A builder a…

In that case, you're just describing about maintaing a fluent API, which is painfully verbose to maintain for every type.

Re: JDK 8 calendar builder

#8

Post by Someone »

mythz wrote: post #7
Someone wrote: post #4

Earlier quoted context omitted.

Method cascades do not guarantee that the object gets properly initialized. Let's say you do var calendar = new Calendar() ..year = 2013 ..date = 6; Neither the year setter nor the day setter can throw, as they cannot know that there is no month setter in your code. So, what month is the date set to after that code? Builder.build(), on the other hand, can throw when called on a partly initialized builder. A builder a…

In that case, you're just describing about maintaing a fluent API, which is painfully verbose to maintain for every type.

It also is joyful in the sense that it will throw exceptions at the place where you make errors and not at some later time (for example, you won't get a 'oops, there is no February 29 in 2013' exception when you print a date). I think the designers of Java value that higher than the extra work of language implementers.

Re: JDK 8 calendar builder

#9

Post by mythz »

Someone wrote: post #8
mythz wrote: post #7

Earlier quoted context omitted.

In that case, you're just describing about maintaing a fluent API, which is painfully verbose to maintain for every type.

It also is joyful in the sense that it will throw exceptions at the place where you make errors and not at some later time (for example, you won't get a 'oops, there is no February 29 in 2013' exception when you print a date). I think the designers of Java value that higher than the extra work of language implementers.

Whilst other language implementers prefer to come up with re-usable language features that scales to help everybody keep a clean and concise code-base.
Post reply on HN