strange recursivion with enumerated types - how is this possible?

Discussion in 'Java' started by rfractal30, Feb 21, 2005.

  1. rfractal30

    rfractal30 Guest


    I was looking at 'enumerated types'in a tutorial and I came across some
    strange recursive situations with I couldn't understand.

    I can see the point of enumerated types as it limits the ways in which
    an object can be instanciated. Take the code below. It would not be
    possible to create an object like this:

    monthes mymonth = new monthes("fred");

    Obviously that does not work, because the constructor is private. Only
    if I were creating an instance of monthes from within that class can I
    do that. So I have enumerated types to create instances of monthes, for

    monthes mymonth = monthes.AUGUST;

    This is fine, but it occured to me that this could lead to a weird kind
    of recursion. I tested it and my suspicions turned out to be correct.
    It was therefor possible to create code such as this:


    Crazy!!! no? I really can't understand how this is possible (but I
    tested it and it really is) How does this work? Why does the program
    not crash due to infinite recursion. I'm confused.

    public class monthes {

    static final monthes JANUARY = new monthes ("January");
    static final monthes FEBUARY = new monthes ("Febuary");
    static final monthes MARCH = new monthes ("March");
    static final monthes APRIL = new monthes ("April");
    static final monthes MAY = new monthes ("May");
    static final monthes JUNE = new monthes ("June");
    static final monthes JULY = new monthes ("July");
    static final monthes AUGUST = new monthes ("August");
    static final monthes SEPTEMBER = new monthes ("September");
    static final monthes OCTOBER = new monthes ("October");
    static final monthes NOVEMBER = new monthes ("November");
    static final monthes DECEMBER = new monthes ("December");

    private String month;
    private int numDays;

    private monthes(String inmonth) {

    if (inmonth.equals("January") || inmonth.equals("March") ||
    inmonth.equals("May") || inmonth.equals("July") ||
    inmonth.equals("August") || inmonth.equals("October") ||
    inmonth.equals("December")) {
    numDays = 31;
    if (inmonth.equals("April") || inmonth.equals("June") ||
    inmonth.equals("September") || inmonth.equals("November")) {
    numDays = 30;

    if (inmonth.equals("Febuary")){
    numDays = 28;

    month = inmonth;

    public String getMonth() {
    public int getNumDays() {


    public class TestMonthes {

    public static void main(String[] args) {

    monthes mymonth = monthes.AUGUST;




    Thanks for any advice.

    rfractal30, Feb 21, 2005
    1. Advertisements

  2. rfractal30

    rfractal30 Guest

    Silly typo. Sorry :)
    rfractal30, Feb 21, 2005
    1. Advertisements

  3. This is an excellent example of how stupid Java's syntax is!
    whoever heard of a monthe being a member of another monthe?
    sanjay manohar, Feb 22, 2005
  4. It isn't. The example exhibits the ability in Java to refer to a class
    (static) variable or method by means of an expression of the
    corresponding type. It is widely regarded as poor style to make use of
    this capability, and some go so far as to consider it a misfeature of
    the language. The main reason for that is that it is deceptive and
    confusing: observe your own apparent misapprehension of the example,
    just for starters.

    If the months actually were members of each other, by the way, that
    wouldn't be a syntax issue. It would be a question of the design of the
    new Typesafe Enum feature.
    John C. Bollinger, Feb 22, 2005
  5. rfractal30

    Chris Uppal Guest

    I'm sure you (Anthony) know this, but I think your phrasing could be misleading
    to others. The new "official" enumerated types in Java are syntactic sugar for
    the old convention for implementing them. I.e. the costs, benefits[*], and
    underlying semantics are identical. The difference is that the language-level
    solution can be more thorough, and is known to the compiler, so that it can
    conveniently "do the right thing" when it sees a switch statement for

    ([*] mostly; there's the unwarranted -- foolish, in my book -- restriction of
    specifying behaviour for the enum objects.)

    -- chris
    Chris Uppal, Feb 23, 2005
  6. In truth I haven't had a chance to thoroughly explore the ins and outs of
    1.5 [haven't even looked at generics - I still have C++ template-related
    nightmares !], so I wasn't aware of the implementation issues you mentioned.
    I may have been assuming more than I should have.

    Thank you for pointing out those things, Chris. I'd much rather be corrected
    now than inadvertantly spread not-quite-correct information in future posts.


    Anthony Borla
    Anthony Borla, Feb 23, 2005
  7. rfractal30

    rfractal30 Guest

    Yes it helps greatly! Thankyou :)
    rfractal30, Feb 25, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.