File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Features new in Java 8 and the fly likes Its about time Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Features new in Java 8
Bookmark "Its about time" Watch "Its about time" New topic
Author

Its about time

Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Wow, finally. Someone has noticed that Java's data and time classes and APIs are a royal pain to use. They are neither clean, consistent, nor orthogonal.

Bring on a new set!
Palak Mathur
Ranch Hand

Joined: Jan 29, 2007
Posts: 313

Pat Farrell wrote:Wow, finally. Someone has noticed that Java's data and time classes and APIs are a royal pain to use. They are neither clean, consistent, nor orthogonal.

Bring on a new set!


Check the project site:

http://sourceforge.net/apps/mediawiki/threeten/index.php?title=ThreeTen


Palak Mathur | My Blog | TechJaunt | What is JavaRanch? | List of All FAQs
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

Date i found difficult, but i found Calendar fairly easy to use. still i look forward to the improvement.


SCJP
Visit my download page
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61769
    
  67

Calendar is an abomination. Passing magic numbers? We might as well be writing C in 1972.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

in a way i wish i was writing C in 1972. or even assembly. at least my skills would be in demand.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19792
    
  20

Magic numbers in Calendar? Isn't every allowed option provided as a constant?
I have no problems with Calendar, except the fact that Calendar.JANUARY == 0 (not 1) while Calendar.SUNDAY == 1. If they could do it for one, why not for the more logical other?


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61769
    
  67

Constants or not, they're magic numbers. Awful, awful, awful.
Palak Mathur
Ranch Hand

Joined: Jan 29, 2007
Posts: 313

I just hope that with ThreeTen, the Calendar manipulations become easier. Currently, the API is so complex that you need to do research only on the API to know which one will do what you want it to do.
Christopher Perrault
Greenhorn

Joined: Aug 11, 2012
Posts: 1

I found the whole date/calendar concept to be a complete PITA to learn when I first stumbled upon it. It's been a while since I did anything with it, but as I can remember, the good thing was you could do almost anything you wanted with it. The class has just about anything you can ask for once you spend the time to learn it. I would agree that the upfront work seems a bit much.


Christopher Perrault
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18992
    
    8

Bear Bibeault wrote:Constants or not, they're magic numbers. Awful, awful, awful.


Just the fact that there's a Calendar.JANUARY constant is a design failure. So even if you replaced those constants by some kind of enum, it still wouldn't help.

Calendar is an abstraction which is supposed to support any calendar (or at least any calendar which repeats yearly and breaks the 365-ish days into a smallish group of months). So besides the Gregorian calendar it should also be able to represent the Hebrew calendar, the Islamic calendar, the Persian calendar, and so on -- and in none of those is the first month called "January". So that constant violates the rule that a class shouldn't know anything about its subclasses.
Palak Mathur
Ranch Hand

Joined: Jan 29, 2007
Posts: 313

Paul Clapham wrote:
Bear Bibeault wrote:Constants or not, they're magic numbers. Awful, awful, awful.


Just the fact that there's a Calendar.JANUARY constant is a design failure. So even if you replaced those constants by some kind of enum, it still wouldn't help.

Calendar is an abstraction which is supposed to support any calendar (or at least any calendar which repeats yearly and breaks the 365-ish days into a smallish group of months). So besides the Gregorian calendar it should also be able to represent the Hebrew calendar, the Islamic calendar, the Persian calendar, and so on -- and in none of those is the first month called "January". So that constant violates the rule that a class shouldn't know anything about its subclasses.


I think there was a discussion regarding this on ThreeTen Issue tracker on GitHub. Nice point I must say!
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18992
    
    8

Palak Mathur wrote:I think there was a discussion regarding this on ThreeTen Issue tracker on GitHub. Nice point I must say!


Yes, I wouldn't be surprised. I've found that if I have what I think is a good idea, then a lot of other people will already have had that good idea. And many of them will have expressed it better than I did, and a lot of them will already have done something based on it. That's just how it is with the web these days.
Palak Mathur
Ranch Hand

Joined: Jan 29, 2007
Posts: 313

Paul Clapham wrote:
Palak Mathur wrote:I think there was a discussion regarding this on ThreeTen Issue tracker on GitHub. Nice point I must say!


Yes, I wouldn't be surprised. I've found that if I have what I think is a good idea, then a lot of other people will already have had that good idea. And many of them will have expressed it better than I did, and a lot of them will already have done something based on it. That's just how it is with the web these days.


I think the way you explained the issue was much better than the way we discussed it on the issue tracker.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16308
    
  22

Paul Clapham wrote:
Bear Bibeault wrote:Constants or not, they're magic numbers. Awful, awful, awful.


Just the fact that there's a Calendar.JANUARY constant is a design failure. So even if you replaced those constants by some kind of enum, it still wouldn't help.

Calendar is an abstraction which is supposed to support any calendar (or at least any calendar which repeats yearly and breaks the 365-ish days into a smallish group of months). So besides the Gregorian calendar it should also be able to represent the Hebrew calendar, the Islamic calendar, the Persian calendar, and so on -- and in none of those is the first month called "January". So that constant violates the rule that a class shouldn't know anything about its subclasses.


I'm glad you said "365-ish", since the various lunar calendars are not 365.25 days long (approximately).

Calendary.JANUARY isn't a "magic number". It's a Manifest Constant. "1" is a magic number. As can be seen by the fact that the first month of the Gregorian Calendar class is 1, but the Calendar.SUNDAY is 0. A well-implemented Hijri (Islamic Year) subclass of Calendar should include a Hijri.RAMADAN manifest constant. The days of the week are worse, since they're basically the same as the day number, and the day starts officially at sunset, not at midnight. Which means that a truly well-functioning Hijri Calendar class needs to know the latitude and longitude it's working from (and technically speaking, the weather, as well).

The justification, I think, for putting Gregorian Manifests in the base Calendar class is simply that it's the common denominator that sooner or later everyone else has to deal with, so it makes translation easier. However, since the Manifest Constants aren't enums, they're not type-safe.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Its about time