Java switch case constaraint
Does anyone know as to why java does not allow to switch on primitives larger than int?
[94 byte] By [abhiJavaa] at [2007-11-27 10:51:36] 
Probably because there shouldn't be any need to. I don't think it's anything to do with the size, more the type. One can switch on enums, and they're not any size at all
georgemca at 2007-7-29 11:32:04 >
umm .. possibly because there is no need .. I can just imagine it nowlong foo = ...
switch(foo) {
case 0: ...
case 1: ...
...
case 9223372036854775806: ...
case 9223372036854775807: ...
}
dwga at 2007-7-29 11:32:04 >
> umm .. possibly because there is no need .. I can
> just imagine it now[code]long foo = ...
> switch(foo) {
>case 0: ...
> case 1: ...
>...
> case 9223372036854775806: ...
>case 9223372036854775807: ...
> ode]
<shiver>
I hate switch statements. And if statements, come to think of it
georgemca at 2007-7-29 11:32:04 >
> <shiver>
>
> I hate switch statements. And if statements, come to
> think of it
I agree, whenever I find myself writing switch statements I take a step back and think about whether I can solve it with polymorphism.
dwga at 2007-7-29 11:32:04 >
> Probably because there shouldn't be any need to. I
> don't think it's anything to do with the size, more
> the type. One can switch on enums, and they're not
> any size at all
I believe they are implemented as integers.
jschella at 2007-7-29 11:32:04 >
> Does anyone know as to why java does not allow to
> switch on primitives larger than int?
Probably no real reason.
Everything in computers have limits however.
And most people do not use larger sizes for that particularily back when java was actually invented.
jschella at 2007-7-29 11:32:04 >
> > Probably because there shouldn't be any need to. I
> > don't think it's anything to do with the size,
> more
> > the type. One can switch on enums, and they're not
> > any size at all
>
> I believe they are implemented as integers.
But they themselves have no implied size. I'm getting at the fact that switching isn't really performed based on sizes
Java's typesafe enums are instances of a class, aren't they?
georgemca at 2007-7-29 11:32:04 >
> Probably because there shouldn't be any need to. I
> don't think it's anything to do with the size, more
> the type. One can switch on enums, and they're not
> any size at all
So I can get infinite compression? Cool!
jverda at 2007-7-29 11:32:04 >
> > Probably because there shouldn't be any need to. I
> > don't think it's anything to do with the size,
> more
> > the type. One can switch on enums, and they're not
> > any size at all
>
> So I can get infinite compression? Cool!
Well, no, because it was impossible to implement them with no size at all :-)
georgemca at 2007-7-29 11:32:04 >
> > > Probably because there shouldn't be any need to.
> I
> > > don't think it's anything to do with the size,
> > more
> > > the type. One can switch on enums, and they're
> not
> > > any size at all
> >
> > So I can get infinite compression? Cool!
>
> Well, no, because it was impossible to
> implement them with no size at all :-)
So, you're saying that, while int, for example, has a defined size of 4 bytes, the number of bytes required to store an enum is not defined by the JLS?
jverda at 2007-7-29 11:32:04 >
> > > > Probably because there shouldn't be any need
> to.
> > I
> > > > don't think it's anything to do with the size,
> > > more
> > > > the type. One can switch on enums, and they're
> > not
> > > > any size at all
> > >
> > > So I can get infinite compression? Cool!
> >
> > Well, no, because it was impossible to
> > implement them with no size at all :-)
>
>
> So, you're saying that, while int, for example, has a
> defined size of 4 bytes, the number of bytes required
> to store an enum is not defined by the JLS?
No. You may put away the extract from that part of the JLS I know you have waiting ;-)
Upon reflection, the phrase "[enums] are not any size at all" was a bit clumsy. I would like to change it to "the size of enums is not germane to this context"
georgemca at 2007-7-29 11:32:04 >
> I would like to change it
> to "the size of enums is not germane to this context"
Except I am rather certain that the 'int' type is implicit within the overall design of java. Certainly initially it was.
This is evident in that the basic word size is the int, and not for example, the long. ("basic word size" in that the byte codes use that explicitly.)
jschella at 2007-7-29 11:32:04 >
> > I would like to change it
> > to "the size of enums is not germane to this
> context"
>
> Except I am rather certain that the 'int' type is
> implicit within the overall design of java.
> Certainly initially it was.
Implicit? Not quite sure what you're getting at here, Joe
georgemca at 2007-7-29 11:32:04 >
> > > > > Probably because there shouldn't be any need
> > to.
> > > I
> > > > > don't think it's anything to do with the
> size,
> > > > more
> > > > > the type. One can switch on enums, and
> they're
> > > not
> > > > > any size at all
> > > >
> > > > So I can get infinite compression? Cool!
> > >
> > > Well, no, because it was impossible to
> > > implement them with no size at all :-)
> >
> >
> > So, you're saying that, while int, for example, has
> a
> > defined size of 4 bytes, the number of bytes
> required
> > to store an enum is not defined by the JLS?
>
> No. You may put away the extract from that part of
> the JLS I know you have waiting ;-)
>
> Upon reflection, the phrase "[enums] are not any size
> at all" was a bit clumsy. I would like to change it
> to "the size of enums is not germane to this context"
I get what you are saying but it really should then be the quantity of switch cases and not the size of int. So we can have up to Integer.MAXVALUE int switch cases and greater if using enums, yes?
Message was edited by:
snic.snac
snic.snaca at 2007-7-29 11:32:04 >
> I get what you are saying but it really should then
> be the quantity of switch cases and not the
> size. So we can have up to Integer.MAXVALUE
> int switch cases and greater if using enums, yes?
I think you've slid into this conversations at a funny angle!
But I don't know if your last assertion is true or not. I only know that I'll never find out, and don't want to ever see a switch statement that size! I doubt it's true, though. Doesn't make sense that the number of instances of something allowed would be dictated by the size of that something
georgemca at 2007-7-29 11:32:09 >
> > I get what you are saying but it really should
> then
> > be the quantity of switch cases and not the
> > size. So we can have up to
> Integer.MAXVALUE
> > int switch cases and greater if using enums, yes?
>
> I think you've slid into this conversations at a
> funny angle!
>
> But I don't know if your last assertion is true or
> not. I only know that I'll never find out, and don't
> want to ever see a switch statement that size! I
> doubt it's true, though. Doesn't make sense that the
> number of instances of something allowed would be
> dictated by the size of that something
I think the OP simply wanted to switch on an integer that is larger than the primitive int allowed in select. One way to overcome this is with enums which you can have as many of (as far as I know, memory permitting):
public enum LargeEnumSize {
LARGECASE1 ("123414341244546541434124454656566"),
LARGECASE2 ("123414341244546541434124454656567"),
LARGECASE3 ("123414341244546541434124454656568");
private final BigInteger bi;
LargeEnumSize(String lg) {
this.bi = new BigInteger(lg);
}
public BigInteger getInteger() {
return bi;
}
}
oops... I meant allowed in switch... been doing a bunch of sql lately
Message was edited by:
snic.snac
snic.snaca at 2007-7-29 11:32:09 >
> > > I get what you are saying but it really should
> > then
> > > be the quantity of switch cases and not
> the
> > > size. So we can have up to
> > Integer.MAXVALUE
> > > int switch cases and greater if using enums,
> yes?
> >
> > I think you've slid into this conversations at a
> > funny angle!
> >
> > But I don't know if your last assertion is true or
> > not. I only know that I'll never find out, and
> don't
> > want to ever see a switch statement that size! I
> > doubt it's true, though. Doesn't make sense that
> the
> > number of instances of something allowed would be
> > dictated by the size of that something
>
> I think the OP simply wanted to switch on an integer
> that is larger than the primitive int allowed in
> select. One way to overcome this is with enums which
> you can have as many of (as far as I know, memory
> permitting):
>
<snip>
Yep, that's exactly what he wanted. A nasty idea. I can't think of a situation where that would be necessary. The switched element shoud be more abstract than actual static data. Your enum solution isn't a workaround, it's the more logical solution. Switching on such large values shouldn't even be considered, not least for being Magic Numbers
But as far as implementation goes, why not just construct the instances of the enum with BigDecimals, if you want to be clearer to other developers what that data is
georgemca at 2007-7-29 11:32:09 >
> > So, you're saying that, while int, for example, has
> a
> > defined size of 4 bytes, the number of bytes
> required
> > to store an enum is not defined by the JLS?
>
> No. You may put away the extract from that part of
> the JLS I know you have waiting ;-)
I haven't looked. I have no idea what the JLS says here. I was just trying to clarify what you were saying.
> Upon reflection, the phrase "[enums] are not any size
> at all" was a bit clumsy.
Hence my attempt to clarify. :-)
> I would like to change it
> to "the size of enums is not germane to this context"
Fair enough. And I agree.
I do wonder, though, if the language allows and enum to have more than 2^32 values.
jverda at 2007-7-29 11:32:09 >
> I get what you are saying but it really should then
> be the quantity of switch cases and not the
> size of int. So we can have up to
> Integer.MAXVALUE int switch cases and greater if
> using enums, yes?
Actually, if they're realized by ints, it'd be double that. Nothing prevents you from using negative values as well.
jverda at 2007-7-29 11:32:09 >
> > > So, you're saying that, while int, for example,
> has
> > a
> > > defined size of 4 bytes, the number of bytes
> > required
> > > to store an enum is not defined by the JLS?
> >
> > No. You may put away the extract from that part of
> > the JLS I know you have waiting ;-)
>
> I haven't looked. I have no idea what the JLS says
> here. I was just trying to clarify what you were
> saying.
>
>
>
> > Upon reflection, the phrase "[enums] are not any
> size
> > at all" was a bit clumsy.
>
> Hence my attempt to clarify. :-)
>
True to style :-)
> > I would like to change it
> > to "the size of enums is not germane to this
> context"
>
> Fair enough. And I agree.
>
> I do wonder, though, if the language allows and enum
> to have more than Integer.MAX_VALUE values.
I suspect the instances are kept in an array, and hence that would indeed stand. No real way of knowing, though, without more effort than I can be bothered with right now</lazy>
georgemca at 2007-7-29 11:32:09 >
> Doesn't make sense that the
> number of instances of something allowed would be
> dictated by the size of that something
It does if there's a direct association between each instance and a unique int.
jverda at 2007-7-29 11:32:09 >
> > I get what you are saying but it really should
> then
> > be the quantity of switch cases and not the
> > size of int. So we can have up to
> > Integer.MAXVALUE int switch cases and greater if
> > using enums, yes?
>
>
> Actually, if they're realized by ints, it'd be double
> that. Nothing prevents you from using negative values
> as well.
Unless, as George suggests, they're stored in an array, for instance.
jverda at 2007-7-29 11:32:09 >
> > I get what you are saying but it really should
> then
> > be the quantity of switch cases and not the
> > size of int. So we can have up to
> > Integer.MAXVALUE int switch cases and greater if
> > using enums, yes?
>
>
> Actually, if they're realized by ints, it'd be double
> that. Nothing prevents you from using negative values
> as well.
true, as long as the particular integer tested for in the switch statement is within this range. I think the OP wants to test for integers outside this range though even if there is only one case.
snic.snaca at 2007-7-29 11:32:09 >
Enums are defined (by the API docs) to have an integer value: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Enum.html#Enum(java.lang.String,%20int)
As for the limitation in switch, it's simply one of the tradeoffs that the JVM designers had to make, given that they were limited to 256 opcodes. This is one of the reasons that the 32-bit integer is the basic numeric value -- they already have to assign opcodes for the basic operations in integer, long, float, and double variants. Adding variants for byte and short, although it doesn't seem like much, would require at least an additional 12 opcodes (+, -, *, /, %, negation), more to cover shifts and bitwise logical operators.
Interestingly, they chose 16 bits as the offset for the compare-and-jump operators. Interesting because many of the machine architectures I'm familiar with only use 8 bits. I suspect that the 64kbyte method size limit is a result of this decision (rather than being a driver) -- although that leaves the question of "why goto_w?"
The switch statement is implemented by one of two bytecodes: lookupswitch or tableswitch. The former is used when the table contains arbitrary values, the latter when the table contains sequential values. Again, there's a tradeoff: if they were to allow 64-bit values in a switch, they'd need another two opcodes, or expand the tables used by the existing operations -- for a situation that's not likely to occur. Incidentally, the documentation gives some evidence that the designers were optimizing for a particular architecture, one that gives a high premium to 32-bit memory accesses.
http://java.sun.com/docs/books/jvms/second_edition/html/Instructions.doc.html
kdgregorya at 2007-7-29 11:32:09 >
> > Doesn't make sense that the
> > number of instances of something allowed would be
> > dictated by the size of that something
>
> It does if there's a direct association between each
> instance and a unique int.
Yep, that's very true. Unlikely requirement, though, in enterprise apps, at least
georgemca at 2007-7-29 11:32:09 >
Even if each case statement averaged only 50 bytes of source, trying to have from 0 thru Integer.MAX_VALUE cases would get you ~107 GB of source code file (I think that math is right)... I'm not sure that would compile.
bsampieria at 2007-7-29 11:32:09 >
> > > Doesn't make sense that the
> > > number of instances of something allowed would
> be
> > > dictated by the size of that something
> >
> > It does if there's a direct association between
> each
> > instance and a unique int.
>
> Yep, that's very true. Unlikely requirement, though,
Reply 24 says the language defines it to be so.
jverda at 2007-7-29 11:32:09 >
> > > > Doesn't make sense that the
> > > > number of instances of something allowed would
> > be
> > > > dictated by the size of that something
> > >
> > > It does if there's a direct association between
> > each
> > > instance and a unique int.
> >
> > Yep, that's very true. Unlikely requirement,
> though,
>
> Reply 24 says the language defines it to be so.
Requirement as in a business requirement, rather than a requirement of the language
Reply 24 sheds a fair amount of light, doesn't it
georgemca at 2007-7-29 11:32:09 >
> > > > > Doesn't make sense that the
> > > > > number of instances of something allowed
> would
> > > be
> > > > > dictated by the size of that something
> > > >
> > > > It does if there's a direct association
> between
> > > each
> > > > instance and a unique int.
> > >
> > > Yep, that's very true. Unlikely requirement,
> > though,
> >
> > Reply 24 says the language defines it to be so.
>
> Requirement as in a business requirement, rather than
> a requirement of the language
I was never talking about a business requirement. I didn't realize you were. I was talking about whether the language defines that association, which it apparently does.
jverda at 2007-7-29 11:32:09 >
> Even if each case statement averaged only 50 bytes of
> source, trying to have from 0 thru Integer.MAX_VALUE
> cases would get you ~107 GB of source code file (I
> think that math is right)... I'm not sure that would
> compile.
but the problem is not the quantity of case statements possible but switching on an integer that is outside the range of primitive int
snic.snaca at 2007-7-29 11:32:13 >
> > > > > > Doesn't make sense that the
> > > > > > number of instances of something allowed
> > would
> > > > be
> > > > > > dictated by the size of that something
> > > > >
> > > > > It does if there's a direct association
> > between
> > > > each
> > > > > instance and a unique int.
> > > >
> > > > Yep, that's very true. Unlikely requirement,
> > > though,
> > >
> > > Reply 24 says the language defines it to be so.
> >
> > Requirement as in a business requirement, rather
> than
> > a requirement of the language
>
> I was never talking about a business requirement. I
> didn't realize you were. I was talking about whether
> the language defines that association, which it
> apparently does.
Aha! I went to "would you want to?" while you were scampering off over to "can you do it?"
georgemca at 2007-7-29 11:32:14 >
> > Even if each case statement averaged only 50 bytes of
> > source, trying to have from 0 thru Integer.MAX_VALUE
> > cases would get you ~107 GB of source code file (I
> > think that math is right)... I'm not sure that would
> > compile.
>
> but the problem is not the quantity of case
> statements possible but switching on an integer that
> is outside the range of primitive int
That was in response to reply #2. I'm understand what you're saying there.
bsampieria at 2007-7-29 11:32:14 >
> > Even if each case statement averaged only 50 bytes
> of
> > source, trying to have from 0 thru
> Integer.MAX_VALUE
> > cases would get you ~107 GB of source code file (I
> > think that math is right)... I'm not sure that
> would
> > compile.
>
> but the problem is not the quantity of case
> statements possible but switching on an integer that
> is outside the range of primitive int
Well, what for? I mean, these numbers don't have to be used in the switch, they can be represented by, say, a bunch of constants which are within the int range. If there are so many of these numbers that there aren't enough ints to go round, that's a much different problem that switch statements aren't really good for, unless, I suppose, they were generated. It would be a haven for bugs and false assumptions
georgemca at 2007-7-29 11:32:14 >
> > > Even if each case statement averaged only 50
> bytes
> > of
> > > source, trying to have from 0 thru
> > Integer.MAX_VALUE
> > > cases would get you ~107 GB of source code file
> (I
> > > think that math is right)... I'm not sure that
> > would
> > > compile.
> >
> > but the problem is not the quantity of case
> > statements possible but switching on an integer
> that
> > is outside the range of primitive int
>
> Well, what for? I mean, these numbers don't have to
> be used in the switch, they can be represented
> by, say, a bunch of constants which are within
> the int range. If there are so many of these numbers
> that there aren't enough ints to go round, that's a
> much different problem that switch statements aren't
> really good for, unless, I suppose, they were
> generated. It would be a haven for bugs and false
> assumptions
I don't know what for man! I'm with you on this.
But if an especially large integer is special to the program and its flow why do something confusing like transforming it into a primitive int which is what I think you are suggesting. Those are bugs waiting to happen as well.
snic.snaca at 2007-7-29 11:32:14 >
>
> I get what you are saying but it really should then
> be the quantity of switch cases and not the
> size of int. So we can have up to
> Integer.MAXVALUE int switch cases and greater if
> using enums, yes?
No.
It isn't possible to create a switch statement that is even close to that in size.
You would probably run into the method byte code limit some where around 6000-65000 entries.
jschella at 2007-7-29 11:32:14 >
> > > I would like to change it
> > > to "the size of enums is not germane to this
> > context"
> >
> > Except I am rather certain that the 'int' type is
> > implicit within the overall design of java.
> > Certainly initially it was.
>
> Implicit? Not quite sure what you're getting at here,
> Joe
The byte codes are are 'int' size based.
Char, short, bytes all are handled as ints. Longs are not atomic. The switch op codes are int sized. The string constant pool within a class is int sized, etc, etc, etc.
jschella at 2007-7-29 11:32:14 >
> I haven't looked. I have no idea what the JLS says
> here. I was just trying to clarify what you were
> saying.
>
I did. I couldn't find anything specific to ints.
But there is no way to implement a switch (byte code) without ints.
So it has to be there.
jschella at 2007-7-29 11:32:14 >
> > > > Even if each case statement averaged only 50
> > bytes
> > > of
> > > > source, trying to have from 0 thru
> > > Integer.MAX_VALUE
> > > > cases would get you ~107 GB of source code
> file
> > (I
> > > > think that math is right)... I'm not sure
> that
> > > would
> > > > compile.
> > >
> > > but the problem is not the quantity of case
> > > statements possible but switching on an integer
> > that
> > > is outside the range of primitive int
> >
> > Well, what for? I mean, these numbers don't have
> to
> > be used in the switch, they can be
> represented
> > by, say, a bunch of constants which are
> within
> > the int range. If there are so many of these
> numbers
> > that there aren't enough ints to go round, that's
> a
> > much different problem that switch statements
> aren't
> > really good for, unless, I suppose, they were
> > generated. It would be a haven for bugs and false
> > assumptions
>
> I don't know what for man! I'm with you on this.
LOL I'm not arguing with you, I'm expressing mild distress at the thought of this design!
> But if an especially large integer is special to the
> program and its flow why do something confusing like
> transforming it into a primitive int which is what I
> think you are suggesting. Those are bugs waiting to
> happen as well.
Not at all. Who cares if it's special to the program? Code is written by human beings (at the moment heh heh) and large integers are largely meaningless to us. I'm not talking about transforming it an int per se, just representing it as one. Map a Long to an enum, perhaps? The enum class itself could do it, with a resolve(Long) method
georgemca at 2007-7-29 11:32:14 >
> >
> > I get what you are saying but it really should
> then
> > be the quantity of switch cases and not the
> > size of int. So we can have up to
> > Integer.MAXVALUE int switch cases and greater if
> > using enums, yes?
>
> No.
>
> It isn't possible to create a switch statement that
> is even close to that in size.
>
> You would probably run into the method byte code
> limit some where around 6000-65000 entries.
Yes, this was all clarified in reply #24 onward I think it was
snic.snaca at 2007-7-29 11:32:14 >
> > > > I would like to change it
> > > > to "the size of enums is not germane to this
> > > context"
> > >
> > > Except I am rather certain that the 'int' type
> is
> > > implicit within the overall design of java.
> > > Certainly initially it was.
> >
> > Implicit? Not quite sure what you're getting at
> here,
> > Joe
>
> The byte codes are are 'int' size based.
>
> Char, short, bytes all are handled as ints. Longs
> are not atomic. The switch op codes are int sized.
> The string constant pool within a class is int
> sized, etc, etc, etc.
Got you. Thanks. Makes perfect sense
georgemca at 2007-7-29 11:32:14 >
> >
> > Actually, if they're realized by ints, it'd be double
> > that. Nothing prevents you from using negative values
> > as well.
>
>
> Unless, as George suggests, they're stored in an
> array, for instance.
"Storing" it in an array doesn't help.
Doing that means that there has to be some byte codes represented as a hidden method which populates the array.
And that means that you will reach the method byte code limit.
Which is going to limit it to about 6000 to 10000.
jschella at 2007-7-29 11:32:14 >
>
> Reply 24 says the language defines it to be so.
That is the Java API not the JLS.
jschella at 2007-7-29 11:32:14 >
> > >
> > > Actually, if they're realized by ints, it'd be
> double
> > > that. Nothing prevents you from using negative
> values
> > > as well.
> >
> >
> > Unless, as George suggests, they're stored in an
> > array, for instance.
>
> "Storing" it in an array doesn't help.
>
> Doing that means that there has to be some byte codes
> represented as a hidden method which populates the
> array
> And that means that you will reach the method byte
> code limit.
>
> Which is going to limit it to about 6000 to 10000.
They're already in an array, come to think of it. There's a class object for an enum. instances of Class hold a soft reference to an array of Fields, and each enum value is a field of said class. I'm not sure if the enum mechanism leverages this at all, but it would make sense since it's basically a by-product of synthesizing an actual class object for the source-code enum construct
georgemca at 2007-7-29 11:32:14 >
> > >
> > > I get what you are saying but it really should
> > then
> > > be the quantity of switch cases and not the
> > > size of int. So we can have up to
> > > Integer.MAXVALUE int switch cases and greater if
> > > using enums, yes?
> >
> > No.
> >
> > It isn't possible to create a switch statement that
> > is even close to that in size.
> >
> > You would probably run into the method byte code
> > limit some where around 6000-65000 entries.
>
> Yes, this was all clarified in reply #24 onward I
> think it was
I wasn't claiming that that the switch was limited to ints.
I was claiming that a method, any method, as a byte code maximum limit.
And a switch in there takes up space.
Even if you just use a short you are not going to be able to span the entire range in a single method.
jschella at 2007-7-29 11:32:18 >
> >
> > Reply 24 says the language defines it to be so.
>
> That is the Java API not the JLS.
Oops. You're right. I missed that prevously.
jverda at 2007-7-29 11:32:18 >
> > > >
> > > > I get what you are saying but it really should
> > > then
> > > > be the quantity of switch cases and not
> the
> > > > size of int. So we can have up to
> > > > Integer.MAXVALUE int switch cases and greater
> if
> > > > using enums, yes?
> > >
> > > No.
> > >
> > > It isn't possible to create a switch statement
> that
> > > is even close to that in size.
> > >
> > > You would probably run into the method byte code
> > > limit some where around 6000-65000 entries.
> >
> > Yes, this was all clarified in reply #24 onward I
> > think it was
>
> I wasn't claiming that that the switch was limited to
> ints.
>
> I was claiming that a method, any method, as a byte
> code maximum limit.
>
> And a switch in there takes up space.
>
> Even if you just use a short you are not going to be
> able to span the entire range in a single method.
Quite right, yes
snic.snaca at 2007-7-29 11:32:18 >
> > > Well, what for? I mean, these numbers don't have
> > to
> > > be used in the switch, they can be
> > represented
> > > by, say, a bunch of constants which are
> > within
> > > the int range. If there are so many of these
> > numbers
> > > that there aren't enough ints to go round,
> that's
> > a
> > > much different problem that switch statements
> > aren't
> > > really good for, unless, I suppose, they were
> > > generated. It would be a haven for bugs and
> false
> > > assumptions
> >
> > I don't know what for man! I'm with you on this.
>
> LOL I'm not arguing with you, I'm expressing
> mild distress at the thought of this design!
>
> > But if an especially large integer is special to
> the
> > program and its flow why do something confusing
> like
> > transforming it into a primitive int which is what
> I
> > think you are suggesting. Those are bugs waiting
> to
> > happen as well.
>
> Not at all. Who cares if it's special to the program?
> Code is written by human beings (at the moment heh
> heh) and large integers are largely meaningless to
> us.
You've blown my mind with that
> I'm not talking about transforming it an int per
> se, just representing it as one. Map a Long to an
> enum, perhaps? The enum class itself could do it,
> with a resolve(Long) method
so resolve(Long)
returns the small-as-a-primitive-int representation of Long and the program can alter its flow based on that?
snic.snaca at 2007-7-29 11:32:18 >
> > > > Well, what for? I mean, these numbers don't
> have
> > > to
> > > > be used in the switch, they can be
> > > represented
> > > > by, say, a bunch of constants which are
> > > within
> > > > the int range. If there are so many of these
> > > numbers
> > > > that there aren't enough ints to go round,
> > that's
> > > a
> > > > much different problem that switch statements
> > > aren't
> > > > really good for, unless, I suppose, they were
> > > > generated. It would be a haven for bugs and
> > false
> > > > assumptions
> > >
> > > I don't know what for man! I'm with you on
> this.
> >
> > LOL I'm not arguing with you, I'm
> expressing
> > mild distress at the thought of this design!
> >
> > > But if an especially large integer is special to
> > the
> > > program and its flow why do something confusing
> > like
> > > transforming it into a primitive int which is
> what
> > I
> > > think you are suggesting. Those are bugs
> waiting
> > to
> > > happen as well.
> >
> > Not at all. Who cares if it's special to the
> program?
> > Code is written by human beings (at the moment heh
> > heh) and large integers are largely meaningless to
> > us.
>
> You've blown my mind with that
>
"Any idiot can write code a machine can read, it takes real skill to write code a human can read" - can't remember who said that. Probably one of the Pragmatic Programmers team
> > I'm not talking about transforming it an int per
> > se, just representing it as one. Map a Long to an
> > enum, perhaps? The enum class itself could do it,
> > with a resolve(Long) method
>
> so resolve(Long)
returns the
> small-as-a-primitive-int representation of Long and
> the program can alter its flow based on that?
Almost. I'd put resolve() on the enum, and have it return instances of that enum
georgemca at 2007-7-29 11:32:18 >
> > > I'm not talking about transforming it an int per
> > > se, just representing it as one. Map a Long to
> an
> > > enum, perhaps? The enum class itself could do
> it,
> > > with a resolve(Long) method
> >
> > so resolve(Long)
returns the
> > small-as-a-primitive-int representation of Long
> and
> > the program can alter its flow based on that?
>
> Almost. I'd put resolve() on the enum, and have it
> return instances of that enum
Like this maybe:
public enum LargeEnumSize {
LARGECASE1 ("12341434124454656566"),
LARGECASE2 ("12341434124454656567"),
LARGECASE3 ("12341434124454656568");
private final BigInteger bi;
LargeEnumSize(String lg) {
this.bi = new BigInteger(lg);
}
public BigInteger getInteger() {
return bi;
}
public static LargeEnumSize resolve(Long l) {
if (l > Integer.MAX_VALUE && l <= Integer.MAX_VALUE * 2) {
return LargeEnumSize.LARGECASE1;
} else if (l > Integer.MAX_VALUE * 2 && l <= Integer.MAX_VALUE * 3) {
return LargeEnumSize.LARGECASE2;
} else return LargeEnumSize.LARGECASE3;
}
}
But no new enum elements can be created dynamically that I know of so I'm not sure how resolve(Long) can be helpful in dealing with special integers that happen to be very large.
snic.snaca at 2007-7-29 11:32:18 >
> >
> > Reply 24 says the language defines it to be so.
>
> That is the Java API not the JLS.
True, but Java is not defined strictly by the JLS ... hmm, I think we debated that in the past.
However, the JLS does in fact get specific with regards to enums: "The direct superclass of an enum type named E is Enum<E>." That still leaves you some weasel room, as later in the same section we see an example of an enum constructor that isn't required to call the Enum constructor ...
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.9
And, there's always the implied int-ness of enums, since they can participate in the case clause of a switch statement.
kdgregorya at 2007-7-29 11:32:18 >
> > >
> > > Reply 24 says the language defines it to be so.
> >
> > That is the Java API not the JLS.
>
> True, but Java is not defined strictly by the JLS ...
The language is. The APIs are not.
> And, there's always the implied int-ness of enums,
> since they can participate in the case clause
> of a switch statement.
That suggests that they may be implemented as ints. But if the JLS says, "You can switch on ints and enums," then it might just as well be that enums are simply another thing you can switch on, and that there's no int-ness in their implementation.
jverda at 2007-7-29 11:32:18 >
> > > That is the Java API not the JLS.
> >
> > True, but Java is not defined strictly by the JLS
>
> The language is. The APIs are not.
Time to step into the realm of pendantic ballsniffing here...
The JLS, although it has "specification" in its title, is not a normative specification. Instead, it (quoting from the preface, emphasis added) "attempts a complete specification of the syntax and semantics of the language." In fact, it has a lot of internal inconsistencies (and if you Google, you'll find web sites devoted to listing these inconsistencies).
Java is actually specified by the TCK, a suite of compatibility tests. If your implementation doesn't pass that suite of tests, you can't legally call it Java. And the TCK does not simply specify the grammar of the language, but also the core APIs that go along with it (as I pointed out to jschell a while back, when Sun attempted to put Java on the standards track, they submitted both grammar and APIs).
> > And, there's always the implied int-ness of enums,
> > since they can participate in the case clause
> > of a switch statement.
>
> That suggests that they may be implemented as ints.
> But if the JLS says, "You can switch on ints and
> enums," then it might just as well be that enums are
> simply another thing you can switch on, and that
> there's no int-ness in their implementation.
My point was based on the JVM but you are correct: as far as the JLS is concerned, enums do not need to have ordinal values.
kdgregorya at 2007-7-29 11:32:18 >
> The JLS, although it has "specification" in its
> title, is not a normative specification.
> Java is actually specified by the TCK, a suite of
> compatibility tests.
Thanks. I wasn't aware of that.
jverda at 2007-7-29 11:32:18 >
> My point was based on the JVM
Actually, if enums were required to be implemented as ints, I would expect that to be in the VM spec, rather than the JLS, but I thought we were talking about the JLS at that point, so I kept my comments around that.
jverda at 2007-7-29 11:32:18 >
> > My point was based on the JVM
>
> Actually, if enums were required to be implemented as
> ints, I would expect that to be in the VM spec,
> rather than the JLS, but I thought we were talking
> about the JLS at that point, so I kept my comments
> around that.
The 2 seem to overlap in places. The signature for main() is defined in the JLS, for example. I'd have expected it in the VM spec
georgemca at 2007-7-29 11:32:18 >
> > >
> > > Reply 24 says the language defines it to be so.
> >
> > That is the Java API not the JLS.
>
> True, but Java is not defined strictly by the JLS ...
> hmm, I think we debated that in the past.
>
> However, the JLS does in fact get specific with
> regards to enums: "The direct superclass of an enum
> type named E is Enum<E>." That still leaves you some
> weasel room, as later in the same section we see an
> example of an enum constructor that isn't required to
> call the Enum constructor ...
The reality is that I doubt anyone is going to implement it in any way that doesn't use ints.
Implementation with byte would be odd, implementing with short/char wouldn't really matter (perhaps some realtime system might do this) but most compilers would implement it using int just because it is easier.
So it doesn't much matter to me if the JLS doesn't make it explicit. I was just noting that it doesn't.
> And, there's always the implied int-ness of enums,
> since they can participate in the case clause
> of a switch statement.
Yes, but that alone isn't sufficient. A compiler could implement the switch statement as a bunch of if/else statements. It could even do it conditionally if a long type was needed.
And it doesn't rule out short or even byte.
But again it would seem to favor that in my mind.
(I note the short case because I believe someone in the past stated that they had a VM/compiler that didn't allow int but only short. It was limited in other ways as well.)
jschella at 2007-7-29 11:32:18 >
>
> Java is actually specified by the TCK, a suite of
> compatibility tests. If your implementation doesn't
> pass that suite of tests, you can't legally call it
> Java. And the TCK does not simply specify the grammar
> of the language, but also the core APIs that go along
> with it (as I pointed out to jschell a while
> back, when Sun attempted to put Java on the standards
> track, they submitted both grammar and APIs).
>
Yep. I remember that.
> Time to step into the realm of pendantic ballsniffing here...
But then have they submitted this particular API?
Not to mention that in that particular link I didn't see anything that actually said it had to be implemented as ints. There was just a strong implication.
But then as far as I am concerned those points are pretty pointless since I doubt anyone is going to implement it using long. And for desktop/server systems it will always be implemented as int just because it is easier.
jschella at 2007-7-29 11:32:18 >
> > My point was based on the JVM
>
> Actually, if enums were required to be implemented as
> ints, I would expect that to be in the VM spec,
> rather than the JLS, but I thought we were talking
> about the JLS at that point, so I kept my comments
> around that.
Errr...no.
That would imply that the VM spec had to change to support this. It didn't.
jschella at 2007-7-29 11:32:18 >
> > > My point was based on the JVM
> >
> > Actually, if enums were required to be implemented as
> > ints, I would expect that to be in the VM spec,
> > rather than the JLS, but I thought we were talking
> > about the JLS at that point, so I kept my comments
> > around that.
>
> The 2 seem to overlap in places. The signature for
> main() is defined in the JLS, for example. I'd have
> expected it in the VM spec
Personally I think you would find it very difficult to argue that the authors of either spec were language lawyers.
Thus there are inconsistencies and just things that are wrong.
jschella at 2007-7-29 11:32:23 >
Java Essentials New Topic
Java Essentials Hot Topic
- what am i doing wrong here?
- advice regarding this book
- Repainting at a specific rectangle on an image
- New to Java EE , which app. server to choose?
- how to pass a file on local m/c to a web app
- about service method in JEE platform
- simultaneous graphics and music THREADS with SwingWorker but not working :(
- Unix - Java - Printing
Java Essentials
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding