Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #32971 > unrolled thread

Java primitive variable objects

Back to article view | Back to comp.lang.java.programmer

Contents

  Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-02 10:11 -0800
    Re: Java primitive variable objects Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-02 14:15 -0500
      Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-02 13:03 -0800
        Re: Java primitive variable objects Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-02 16:29 -0500
    Re: Java primitive variable objects Jan Burse <janburse@fastmail.fm> - 2015-11-02 22:46 +0100
      Re: Java primitive variable objects Jan Burse <janburse@fastmail.fm> - 2015-11-02 22:52 +0100
      Re: Java primitive variable objects Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-02 17:47 -0500
    Re: Java primitive variable objects Joerg Meier <joergmmeier@arcor.de> - 2015-11-05 22:19 +0100
      Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-05 13:31 -0800
        Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-07 22:21 -0500
          Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-09 04:52 -0800
            Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 08:54 -0500
              Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-09 07:27 -0800
                Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 10:51 -0500
                  Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-09 08:28 -0800
                    Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 11:57 -0500
                      Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-09 10:13 -0800
                      Re: Java primitive variable objects Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-09 13:28 -0500
                        Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 14:53 -0500
                        Re: Java primitive variable objects Nigel Wade <nmw@ion.le.ac.uk> - 2015-11-10 09:27 +0000
                      Re: Java primitive variable objects "Jeffrey H. Coffield" <jeffrey@digitalsynergyinc.com> - 2015-11-09 10:44 -0800
                      Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-09 18:59 +0000
                        Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 15:02 -0500
                          Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-09 22:57 +0000
                            Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 19:16 -0500
                      Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-09 20:55 -0500
                        Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 22:13 -0500
                  Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-09 20:40 -0500
                    Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 22:23 -0500
            Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-09 14:00 +0000
              Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-09 07:18 -0800
                Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-09 20:43 -0500
            Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-09 19:38 -0500
              Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 20:26 -0500
                Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-10 02:10 +0000
                  Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 22:12 -0500
                    Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-10 13:01 +0000
                      Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-10 12:23 -0500
                        Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-10 10:10 -0800
                          Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-10 22:08 -0500
                        Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-10 20:05 +0000
                          Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-10 13:21 -0800
                            Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-10 23:30 +0000
                            Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-10 20:58 -0500
                            Re: Java primitive variable objects Gene Wirchenko <genew@telus.net> - 2015-11-10 22:30 -0800
                    Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-10 21:58 -0500
                Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-10 21:56 -0500
                  Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-10 22:19 -0500
                    Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-10 22:42 -0500
                      Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-10 23:07 -0500
              Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-10 06:06 -0800
    Re: Java primitive variable objects Lew <lewbloch@gmail.com> - 2015-11-16 14:47 -0800

Page 1 of 3  [1] 2 3  Next page →

#32971 — Java primitive variable objects

I just discovered something which created a minor problem in my class.  What would be the best way to solve it?

I have some constant values defined such as this
public static final int AVALUE = 1;

some methods in the class have conditions defined such as this
if (myValue == MyClass.AVALUE) {

I'm passing in myValue as Integer with a possibility it could be null.
I hadn't tested these methods with the null value so I didn't realize it actually gets an error.

This code
          Integer x = 1;
          Integer o = 1;
          if (x == o) {
               System.out.println("equal");
          } else {
               System.out.println("not");
          }
prints "equal".
This code
          Integer x = new Integer(1);
          Integer o = 1;
          if (x == o) {
               System.out.println("equal");
          } else {
               System.out.println("not");
          }
prints "not".
This code
          Integer x = new Integer(1);
          int o = 1;
          if (x == o) {
               System.out.println("equal");
          } else {
               System.out.println("not");
          }
prints "equal".
This code
          Integer x = null;
          int o = 1;
          if (x == o) {
               System.out.println("equal");
          } else {
               System.out.println("not");
          }
gets a NullPointerException on the if.
Of course Eclipse at this point knows x is null and shows a warning on the if, but if you break it out as the real code would be, it compiles without error and just crashes when you run.

     public static void main(String[] args) {
          Integer x = null;
          checkThis(x);
     }
     public static void checkThis(final Integer checkMe) {
          int o = 1;
          if (checkMe == o) {
               System.out.println("equal");
          } else {
               System.out.println("not");
          }
     }

Solutions?
1) Change all the constants to objects
public static final Integer AVALUE = 1;

2) Add null checks to all conditions
if (checkMe != null && checkMe == o) {

Is there a third option?  Is there a difference in declaring static int constants versus Integers for memory use, performance?

[toc] | [next] | [standalone]

#32972

On 11/2/2015 1:11 PM, Eric Douglas wrote:
> I just discovered something which created a minor problem in my class.  What would be the best way to solve it?
>
> I have some constant values defined such as this
> public static final int AVALUE = 1;
>
> some methods in the class have conditions defined such as this
> if (myValue == MyClass.AVALUE) {
>
> I'm passing in myValue as Integer with a possibility it could be null.
> I hadn't tested these methods with the null value so I didn't realize it actually gets an error.

     ... as it should.  "Unboxing" an Integer to extract its int
value cannot proceed if the Integer reference is null, that is,
if there's no Integer to be unboxed.

> This code
>            Integer x = 1;
>            Integer o = 1;
>            if (x == o) {
>                 System.out.println("equal");
>            } else {
>                 System.out.println("not");
>            }
> prints "equal".

     Right, but perhaps not for the reason you may imagine.
The comparison is not made between the unboxed values of the
Integer references, but is the traditional "reference identity"
comparison.  That is, the comparison checks whether the two
references x and o refer to the same Integer instance.

     Java happens to guarantee that the Integer instances produced
by "boxing" small int values are identical: It caches a bunch of
small-valued Integer objects and uses them over and over.  So if
you box the int value 1 twice, you get two references to the same
cached 1-valued Integer, and == pronounces them identical.

     If you box some int values whose corresponding Integers are
*not* cached, you get two brand-new Integer instances that == will
declare to be different.  I forget what the mandatory range of cached
values is (and individual implementations are allowed to cache more
than are required), but if you experiment with changing the 1's in
your example to -192837465's or some such, you may well get a different
outcome.

> This code
>            Integer x = new Integer(1);
>            Integer o = 1;
>            if (x == o) {
>                 System.out.println("equal");
>            } else {
>                 System.out.println("not");
>            }
> prints "not".

     Right.  The x reference is to a brand-new 1-valued Integer, while
the o reference is to a 1-valued Integer in the JVM's cache.  The ==
sees that these two are different objects, and says so.

> This code
>            Integer x = new Integer(1);
>            int o = 1;
>            if (x == o) {
>                 System.out.println("equal");
>            } else {
>                 System.out.println("not");
>            }
> prints "equal".

     Right, because comparison between an Integer and an int works
by "unboxing" the Integer and comparing the two int values.  The
comparison is shorthand for `x.intValue() == o'.

> This code
>            Integer x = null;
>            int o = 1;
>            if (x == o) {
>                 System.out.println("equal");
>            } else {
>                 System.out.println("not");
>            }
> gets a NullPointerException on the if.

     As above, the comparison is `x.intValue() == o', and when x is
null you can't call instance methods on it.

> Of course Eclipse at this point knows x is null and shows a warning on the if, but if you break it out as the real code would be, it compiles without error and just crashes when you run.
>
>       public static void main(String[] args) {
>            Integer x = null;
>            checkThis(x);
>       }
>       public static void checkThis(final Integer checkMe) {
>            int o = 1;
>            if (checkMe == o) {
>                 System.out.println("equal");
>            } else {
>                 System.out.println("not");
>            }
>       }
>
> Solutions?

     It's not clear to me just what problem you think needs solving.
Boxing and unboxing conversions can be confusing, agreed, but once
Sun decided to add them to Java there was no going back: You simply
need to know what the rules are, or know how to stay away from the
situations where the confusing bits arise.

> 1) Change all the constants to objects
> public static final Integer AVALUE = 1;

     Still plenty of room for surprises:

	if (new Integer(1) == AVALUE) ...

... and similarly for any other 1-valued Integer of unknown provenance.

> 2) Add null checks to all conditions
> if (checkMe != null && checkMe == o) {

     This avoids the NullPointerException, but as with (1) it can
still yield surprises.  (Also, although it reliably detects "present
and equal" it fails to distinguish between "absent" and "present but
unequal."  In a real program, you'd probably want to treat the three
cases differently.)

> Is there a third option? [...]

     I'd recommend not comparing Integers (or Bytes, etc.) with the ==
and != operators.  Comparing them with int (byte, ...) values is okay
if the references are non-null, because unboxing occurs and you get a
value-based comparison.  It's also okay to compare non-null references
with <, <=, >=, and >, because these also cause unboxing.

     To avoid nulls, try to use Integer (etc.) only when forced to and
prefer to use int (etc.) wherever you can.  When you must use an
Integer -- for example, when you're storing values in a Collection --
be careful to null-check when you need to:

	Map<Thing, Integer> occurrences = ...;
	for (Thing thing : collectionOfThings) {
	    Integer count = occurrences.get(thing);
	    occurrences.put(thing, count == null ? 1 : count + 1);
	}

> [...] Is there a difference in declaring static int constants versus Integers for memory use, performance?

     There's certainly a difference in memory use.  An int value takes
four bytes, period.  Using an Integer requires the Integer object itself
plus a reference variable that points to it.  On my system (yours may be
different) that's sixteen bytes for the Integer and four more for the
reference.  As mentioned above, though, some smallish Integers are
cached and re-used, so part of the twenty-byte total may be "free" or
at the least "amortized;" it's hard to come up with an exact measurement
of the int-to-Integer penalty.

     Performance?  Dunno, but I suspect the difference is fairly small,
probably too small to be measured without a Real Whole Lot of work.
You could take it on as a research project, I guess.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32973

On Monday, November 2, 2015 at 2:16:30 PM UTC-5, Eric Sosman wrote:
>      I'd recommend not comparing Integers (or Bytes, etc.) with the ==
> and != operators.  Comparing them with int (byte, ...) values is okay
> if the references are non-null, because unboxing occurs and you get a
> value-based comparison.  It's also okay to compare non-null references
> with <, <=, >=, and >, because these also cause unboxing.
> 
>      To avoid nulls, try to use Integer (etc.) only when forced to and
> prefer to use int (etc.) wherever you can.  When you must use an
> Integer -- for example, when you're storing values in a Collection --
> be careful to null-check when you need to:
> 
> 	Map<Thing, Integer> occurrences = ...;
> 	for (Thing thing : collectionOfThings) {
> 	    Integer count = occurrences.get(thing);
> 	    occurrences.put(thing, count == null ? 1 : count + 1);
> 	}
> 
> > [...] Is there a difference in declaring static int constants versus Integers for memory use, performance?
> 
>      There's certainly a difference in memory use.  An int value takes
> four bytes, period.  Using an Integer requires the Integer object itself
> plus a reference variable that points to it.  On my system (yours may be
> different) that's sixteen bytes for the Integer and four more for the
> reference.  As mentioned above, though, some smallish Integers are
> cached and re-used, so part of the twenty-byte total may be "free" or
> at the least "amortized;" it's hard to come up with an exact measurement
> of the int-to-Integer penalty.

So, == and != are fine if we're comparing int to int, but if I need to compare Integer to int our best bet is to check for null and use the method
     public static void checkThis(final Integer checkMe) {
          int o = 1;
          if (checkMe != null && checkMe.equals(o)) {
               System.out.println("equal");
          } else {
               System.out.println("not");
          }
     }
or this should be about the same
          if (checkMe != null && checkMe.intValue() == o) {

and a better option would be to avoid the primitive objects altogether.
For example, I made a custom class which extends JTable.  I have a custom method getCellStyle(int row, int col) which is returning Integer, and I'm trying to compare this to int constants (public static final class variables) for different custom cell styles.  If this row, col does not reference a valid cell it's returning null.  So instead I should be returning int, and if it's not a valid cell just return a valid int which corresponds to a constant that means not a valid cell.

[toc] | [prev] | [next] | [standalone]

#32974

On 11/2/2015 4:03 PM, Eric Douglas wrote:
> On Monday, November 2, 2015 at 2:16:30 PM UTC-5, Eric Sosman wrote:
>>       I'd recommend not comparing Integers (or Bytes, etc.) with the ==
>> and != operators.  Comparing them with int (byte, ...) values is okay
>> if the references are non-null, because unboxing occurs and you get a
>> value-based comparison.  It's also okay to compare non-null references
>> with <, <=, >=, and >, because these also cause unboxing.
>>
>>       To avoid nulls, try to use Integer (etc.) only when forced to and
>> prefer to use int (etc.) wherever you can.  When you must use an
>> Integer -- for example, when you're storing values in a Collection --
>> be careful to null-check when you need to:
>>
>> 	Map<Thing, Integer> occurrences = ...;
>> 	for (Thing thing : collectionOfThings) {
>> 	    Integer count = occurrences.get(thing);
>> 	    occurrences.put(thing, count == null ? 1 : count + 1);
>> 	}
>>
>>> [...] Is there a difference in declaring static int constants versus Integers for memory use, performance?
>>
>>       There's certainly a difference in memory use.  An int value takes
>> four bytes, period.  Using an Integer requires the Integer object itself
>> plus a reference variable that points to it.  On my system (yours may be
>> different) that's sixteen bytes for the Integer and four more for the
>> reference.  As mentioned above, though, some smallish Integers are
>> cached and re-used, so part of the twenty-byte total may be "free" or
>> at the least "amortized;" it's hard to come up with an exact measurement
>> of the int-to-Integer penalty.
>
> So, == and != are fine if we're comparing int to int, but if I need to compare Integer to int our best bet is to check for null and use the method
>       public static void checkThis(final Integer checkMe) {
>            int o = 1;
>            if (checkMe != null && checkMe.equals(o)) {
>                 System.out.println("equal");
>            } else {
>                 System.out.println("not");
>            }
>       }
> or this should be about the same
>            if (checkMe != null && checkMe.intValue() == o) {

     Fine.  Or, perhaps,

	if (checkMe == null) {
	    // nothing there
	} else if (checkMe.intValue() == o) {
	    // something equal to o is there
	} else {
	    // something unequal to o is there
	}

> and a better option would be to avoid the primitive objects altogether.

     "Altogether" is perhaps a bit strong, as there are situations where
you simply cannot use a primitive.  I've mentioned Collections and Maps
and the like (which can only contain Objects), you've mentioned some of
the Swing framework, DecimalFormat#parse() returns a Number (which isn't
actually a wrapper class, but has some of the same issues), and so on.
Use the wrapper classes when an API demands them, or when you find it
useful to distinguish null from zero-or-whatever, but use the primitives
whenever you can.

     By the way, "primitive object" is a peculiar turn of phrase.  The
Java Language Specification uses "primitive type" to mean one of char,
boolean, byte, short, int, long, float, or double, and when people see
the word "primitive" they're likely to think you mean one of these.  The
classes Character, Boolean, Byte, Short, Integer, Long, Float, and
Double are called the "wrapper classes" for the corresponding primitive
types, and I think you and your students might benefit from using that
terminology instead of the oxymoronic "primitive object."

> For example, I made a custom class which extends JTable.  I have a custom method getCellStyle(int row, int col) which is returning Integer, and I'm trying to compare this to int constants (public static final class variables) for different custom cell styles.  If this row, col does not reference a valid cell it's returning null.  So instead I should be returning int, and if it's not a valid cell just return a valid int which corresponds to a constant that means not a valid cell.

     Perhaps instead of an Integer your method should return a CellStyle
of your own devising.  An enum might be attractive here, and would be a
bit more type-safe than a bunch of static finals.  Just a suggestion.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32975

Hi,

Switch off autoboxing and unboxing, and you can't
compile most of your stuff below. Which explains
the behaviour.

Bye

P.S.: BTW autoboxing has improved so that
you can even compile and execute the
following code:

     public static void p(Number n) {
         System.out.println("n.getClass()="+n.getClass());
     }

     public static void main(String[] args) {
         p((byte)1);
         p((short)1);
         p(1);
         p(1L);
         p(0.1);
         p(0.1f);
     }

The result will be:

n.getClass()=class java.lang.Byte
n.getClass()=class java.lang.Short
n.getClass()=class java.lang.Integer
n.getClass()=class java.lang.Long
n.getClass()=class java.lang.Double
n.getClass()=class java.lang.Float

But you wont be able to compile:

        p('A');

P.P.S.: It is recommended to call Integer.valueOf()
and Long.valueOf() instead of new Integer() or new Long(),
since both will give cached value objects for small ranges.

There are also Double.valueOf() and Float.valueOf(),
but I havent seen that they returned cached value
objects.

Eric Douglas schrieb:
> I just discovered something which created a minor problem in my class.  What would be the best way to solve it?
>
> I have some constant values defined such as this
> public static final int AVALUE = 1;
>
> some methods in the class have conditions defined such as this
> if (myValue == MyClass.AVALUE) {
>
> I'm passing in myValue as Integer with a possibility it could be null.
> I hadn't tested these methods with the null value so I didn't realize it actually gets an error.
>
> This code
>            Integer x = 1;
>            Integer o = 1;
>            if (x == o) {
>                 System.out.println("equal");
>            } else {
>                 System.out.println("not");
>            }
> prints "equal".
> This code
>            Integer x = new Integer(1);
>            Integer o = 1;
>            if (x == o) {
>                 System.out.println("equal");
>            } else {
>                 System.out.println("not");
>            }
> prints "not".
> This code
>            Integer x = new Integer(1);
>            int o = 1;
>            if (x == o) {
>                 System.out.println("equal");
>            } else {
>                 System.out.println("not");
>            }
> prints "equal".
> This code
>            Integer x = null;
>            int o = 1;
>            if (x == o) {
>                 System.out.println("equal");
>            } else {
>                 System.out.println("not");
>            }
> gets a NullPointerException on the if.
> Of course Eclipse at this point knows x is null and shows a warning on the if, but if you break it out as the real code would be, it compiles without error and just crashes when you run.
>
>       public static void main(String[] args) {
>            Integer x = null;
>            checkThis(x);
>       }
>       public static void checkThis(final Integer checkMe) {
>            int o = 1;
>            if (checkMe == o) {
>                 System.out.println("equal");
>            } else {
>                 System.out.println("not");
>            }
>       }
>
> Solutions?
> 1) Change all the constants to objects
> public static final Integer AVALUE = 1;
>
> 2) Add null checks to all conditions
> if (checkMe != null && checkMe == o) {
>
> Is there a third option?  Is there a difference in declaring static int constants versus Integers for memory use, performance?
>

[toc] | [prev] | [next] | [standalone]

#32976

Jan Burse schrieb:
> Switch off autoboxing and unboxing, and you can't
> compile most of your stuff below. Which explains
> the behaviour.

Well this is not fully true, I guess your tests
include some interesting border cases, such
as mixing of boxing and unboxing etc.., which
need additional explanation.

But I was too lazy..

BTW: I recently noticed that there are also
a couple of new methods for the class Integer
in JDK 8, like exact arithmethic, and already
before JDK 8, things like:

JDK 1.2:

     public int compareTo(Integer anotherInteger);

JDK 1.7:

     public static int compare(int x, int y);

Which makes it more and more annoying to develop
for different JDK versions. For example I was
focusing on JDK 1.5, but now sometimes I am
tempted to use JDK 1.7.

What helps here is the IntellJ inline function.
If I see myself using a JDK 1.7 function,
I just inline it, e voila, its gone.

Bye

[toc] | [prev] | [next] | [standalone]

#32977

On 11/2/2015 4:46 PM, Jan Burse wrote:
> Hi,
>
> Switch off autoboxing and unboxing, and you can't
> compile most of your stuff below. Which explains
> the behaviour.
>
> Bye
>
> P.S.: BTW autoboxing has improved so that
> you can even compile and execute the
> following code:
>
>      public static void p(Number n) {
>          System.out.println("n.getClass()="+n.getClass());
>      }
>
>      public static void main(String[] args) {
>          p((byte)1);
>          p((short)1);
>          p(1);
>          p(1L);
>          p(0.1);
>          p(0.1f);
>      }
>
> The result will be:
>
> n.getClass()=class java.lang.Byte
> n.getClass()=class java.lang.Short
> n.getClass()=class java.lang.Integer
> n.getClass()=class java.lang.Long
> n.getClass()=class java.lang.Double
> n.getClass()=class java.lang.Float
>
> But you wont be able to compile:
>
>         p('A');

     ... because Character is not a subclass of Number.  Change
the parameter of p() from Number to Object, though, and it will
compile and run fine, and will also work with

	p(true);

... illustrating the boxing conversions of non-numbers.

> P.P.S.: It is recommended to call Integer.valueOf()
> and Long.valueOf() instead of new Integer() or new Long(),
> since both will give cached value objects for small ranges.

     Nitpick: JLS promises this for Integers (-128 through 127), for
Characters ('\u0000' through '\u007f'), and for Boolean (true and
false), but does not promise that any Bytes, Shorts, Longs, Floats,
or Doubles are cached.  A given Java implementation *may* cache other
values and types, but is not required to do so.  (IMHO the promises
are rather silly, but that's just MHO.)

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33002

On Mon, 2 Nov 2015 10:11:03 -0800 (PST), Eric Douglas wrote:

> I just discovered something which created a minor problem in my class.  What would be the best way to solve it?

> I have some constant values defined such as this
> public static final int AVALUE = 1;

> some methods in the class have conditions defined such as this
> if (myValue == MyClass.AVALUE) {

> [...]

> Is there a third option?  Is there a difference in declaring static int constants versus Integers for memory use, performance?

It sounds like you may want to take a step back and consider whether your
problem is not actually a use case for enums. It certainly looks like it
might be from the outside.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#33003

On Thursday, November 5, 2015 at 4:19:43 PM UTC-5, Joerg Meier wrote:
> It sounds like you may want to take a step back and consider whether your
> problem is not actually a use case for enums. It certainly looks like it
> might be from the outside.

Certainly, as I believe that was already mentioned.
The problem there is the reference.  This is in an API and those constants are public.  If we have any programs using those constants those would have to be updated if I change these to enums.

I taught myself Java (I went to school in the 90s where application coding was still mainly COBOL) so I wasn't even aware of enums when I started this class much less their use case.  In our programs from other languages ie BASIC the constants were just numeric variables so we stuck with that.  If I design a Java class with constants from scratch I'd use enums now.

Our current language is BBj (see www.basis.com) which uses hybrid syntax.  BBj stands for Business BASIC which runs on Java, so we write BASIC programs but we can also use Java objects.  They handle the interpretation behind the scenes with proxies.

[toc] | [prev] | [next] | [standalone]

#33022

On 11/5/2015 4:31 PM, Eric Douglas wrote:
> I taught myself Java (I went to school in the 90s where application
> coding was still mainly COBOL)

In the 90's you should have been taught Pascal and/or C++ (which
both has enums) if the school had been following trends.

Arne

[toc] | [prev] | [next] | [standalone]

#33038

On Saturday, November 7, 2015 at 10:21:54 PM UTC-5, Arne Vajhøj wrote:
> In the 90's you should have been taught Pascal and/or C++ (which
> both has enums) if the school had been following trends.
> 
> Arne

I've never heard of either of those being used for business applications.
I went to college from 1993 to 1996.  Most companies were using COBOL.
I did have one intro to C++ course.
Let me guess, you're one of those people, who gets a BS in CS for a career in CIS.

[toc] | [prev] | [next] | [standalone]

#33040

On 11/9/2015 7:52 AM, Eric Douglas wrote:
> On Saturday, November 7, 2015 at 10:21:54 PM UTC-5, Arne Vajhøj wrote:
>> In the 90's you should have been taught Pascal and/or C++ (which
>> both has enums) if the school had been following trends.
>>
>> Arne
> 
> I've never heard of either of those being used for business applications.
> I went to college from 1993 to 1996.  Most companies were using COBOL.
> I did have one intro to C++ course.
> Let me guess, you're one of those people, who gets a BS in CS for a career in CIS.
> 

Actually, C++ is used quite a bit in non-financial businesses
applications.  Other languages such as C are used more, but mainly
because those are older.

PASCAL isn't used much in business for the same reason it makes a great
learning tool.  It places you in a straightjacket, and results in a
slower development cycle.  OTOH, that same straightjacket teaches good
programming techniques that can be applied to virtually any language.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#33047

On Monday, November 9, 2015 at 8:54:58 AM UTC-5, Jerry Stuckle wrote:
> PASCAL isn't used much in business for the same reason it makes a great
> learning tool.  It places you in a straightjacket, and results in a
> slower development cycle.  OTOH, that same straightjacket teaches good
> programming techniques that can be applied to virtually any language.

I've never written PASCAL but I've never seen a programming straightjacket language worse than RPG.

[toc] | [prev] | [next] | [standalone]

#33048

On 11/9/2015 10:27 AM, Eric Douglas wrote:
> On Monday, November 9, 2015 at 8:54:58 AM UTC-5, Jerry Stuckle wrote:
>> PASCAL isn't used much in business for the same reason it makes a great
>> learning tool.  It places you in a straightjacket, and results in a
>> slower development cycle.  OTOH, that same straightjacket teaches good
>> programming techniques that can be applied to virtually any language.
> 
> I've never written PASCAL but I've never seen a programming straightjacket language worse than RPG.
> 

Oh, RPG was fun. A simple language that allows simple managers to
quickly create reports from a database.  Not much for computational
power, but it didn't need it for what it did.

PASCAL is much worse.  For instance, two variables, each defined as
char[80] are not considered the same type.  You need to define a new
type such as "char80" then have the two variables of that type.  Now
they can be compared, assigned, etc.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#33049

On Monday, November 9, 2015 at 10:51:33 AM UTC-5, Jerry Stuckle wrote:
> Oh, RPG was fun. A simple language that allows simple managers to
> quickly create reports from a database.  Not much for computational
> power, but it didn't need it for what it did.
> 
> PASCAL is much worse.  For instance, two variables, each defined as
> char[80] are not considered the same type.  You need to define a new
> type such as "char80" then have the two variables of that type.  Now
> they can be compared, assigned, etc.

I learned about RPG in school, never had to use it for work.  The language was so ugly, and the teacher for it told war stories instead of teaching, that no one bothered to learn it.  They just copied the labs from someone who had the class before.  I can't imagine a worse 'language' than one that tells you what characters you can type and hard codes columns to type them in.

[toc] | [prev] | [next] | [standalone]

#33050

On 11/9/2015 11:28 AM, Eric Douglas wrote:
> On Monday, November 9, 2015 at 10:51:33 AM UTC-5, Jerry Stuckle wrote:
>> Oh, RPG was fun. A simple language that allows simple managers to
>> quickly create reports from a database.  Not much for computational
>> power, but it didn't need it for what it did.
>>
>> PASCAL is much worse.  For instance, two variables, each defined as
>> char[80] are not considered the same type.  You need to define a new
>> type such as "char80" then have the two variables of that type.  Now
>> they can be compared, assigned, etc.
> 
> I learned about RPG in school, never had to use it for work.  The language was so ugly, and the teacher for it told war stories instead of teaching, that no one bothered to learn it.  They just copied the labs from someone who had the class before.  I can't imagine a worse 'language' than one that tells you what characters you can type and hard codes columns to type them in.
> 

You never used FORTRAN on punched cards then :)

Columns 1-6  were numeric for statement number; 7 a continuation column
(non-blank means the statement continued from the previous card).  8-72
for the code itself, and 73-80 "free form" - generally used to
sequentially number the cards for when you dropped the deck :)

But you couldn't beat RPG for rapid report generation, even by a
non-technical user.  When I learned it, there was no SQL or relational
databases, no MS Access or similar.  Without RPG the manager would have
to find a programmer (probably COBOL at the time) who would need several
days to create the same report the manager could in a couple of hours.
But all it was good for was generating reports (hence the name "Report
Generating Program").  You could fetch some data, filter it and spit it
out in a pretty column format, but not much else.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#33052

On Monday, November 9, 2015 at 11:57:43 AM UTC-5, Jerry Stuckle wrote:
> You never used FORTRAN on punched cards then :)
> 
> Columns 1-6  were numeric for statement number; 7 a continuation column
> (non-blank means the statement continued from the previous card).  8-72
> for the code itself, and 73-80 "free form" - generally used to
> sequentially number the cards for when you dropped the deck :)
> 
> But you couldn't beat RPG for rapid report generation, even by a
> non-technical user.  When I learned it, there was no SQL or relational
> databases, no MS Access or similar.  Without RPG the manager would have
> to find a programmer (probably COBOL at the time) who would need several
> days to create the same report the manager could in a couple of hours.
> But all it was good for was generating reports (hence the name "Report
> Generating Program").  You could fetch some data, filter it and spit it
> out in a pretty column format, but not much else.

Nope, punch cards were before my time.  My first experience with programming was BASIC in 8th grade on TRS-80s.  By the time I got to college we had regular IDEs on Pentium class machines.

Column 8-72 sounds liberal, COBOL does that stuff.  RPG tells you what goes in column 26, what goes in column 27, etc.  I never had to work with it but saw some tedious looking templates.  I wrote my own report writer over the past several years.  It runs Java, so platform independent.  It can keep a report in memory, print multiple text sizes on the same page, print images, draw lines, print 5 pages then go back and put a total on page 1, preview the report on screen, save a copy to PDF and send a copy to multiple printers...so much flexibility and it's a fairly complex report that takes me more than an hour to write.

[toc] | [prev] | [next] | [standalone]

#33053

On 11/9/2015 11:57 AM, Jerry Stuckle wrote:
> On 11/9/2015 11:28 AM, Eric Douglas wrote:
>> On Monday, November 9, 2015 at 10:51:33 AM UTC-5, Jerry Stuckle wrote:
>>> Oh, RPG was fun. A simple language that allows simple managers to
>>> quickly create reports from a database.  Not much for computational
>>> power, but it didn't need it for what it did.
>>>
>>> PASCAL is much worse.  For instance, two variables, each defined as
>>> char[80] are not considered the same type.  You need to define a new
>>> type such as "char80" then have the two variables of that type.  Now
>>> they can be compared, assigned, etc.
>>
>> I learned about RPG in school, never had to use it for work.  The language was so ugly, and the teacher for it told war stories instead of teaching, that no one bothered to learn it.  They just copied the labs from someone who had the class before.  I can't imagine a worse 'language' than one that tells you what characters you can type and hard codes columns to type them in.
>>
>
> You never used FORTRAN on punched cards then :)
>
> Columns 1-6  were numeric for statement number; 7 a continuation column

	s/6/5/
	s/7/6/

Also, a "C" in column 1 meant that columns 2-80 were ignored; "C" meant
"comment."

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33057

On 11/9/2015 1:28 PM, Eric Sosman wrote:
> On 11/9/2015 11:57 AM, Jerry Stuckle wrote:
>> On 11/9/2015 11:28 AM, Eric Douglas wrote:
>>> On Monday, November 9, 2015 at 10:51:33 AM UTC-5, Jerry Stuckle wrote:
>>>> Oh, RPG was fun. A simple language that allows simple managers to
>>>> quickly create reports from a database.  Not much for computational
>>>> power, but it didn't need it for what it did.
>>>>
>>>> PASCAL is much worse.  For instance, two variables, each defined as
>>>> char[80] are not considered the same type.  You need to define a new
>>>> type such as "char80" then have the two variables of that type.  Now
>>>> they can be compared, assigned, etc.
>>>
>>> I learned about RPG in school, never had to use it for work.  The
>>> language was so ugly, and the teacher for it told war stories instead
>>> of teaching, that no one bothered to learn it.  They just copied the
>>> labs from someone who had the class before.  I can't imagine a worse
>>> 'language' than one that tells you what characters you can type and
>>> hard codes columns to type them in.
>>>
>>
>> You never used FORTRAN on punched cards then :)
>>
>> Columns 1-6  were numeric for statement number; 7 a continuation column
> 
>     s/6/5/
>     s/7/6/
> 
> Also, a "C" in column 1 meant that columns 2-80 were ignored; "C" meant
> "comment."
> 

Ah, yes, you're right.  It's been a long time since I used punch cards :)

Thanks for the correction.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#33071

On 09/11/15 18:28, Eric Sosman wrote:
> Also, a "C" in column 1 meant that columns 2-80 were ignored; "C" meant
> "comment."

columns 73-80 were always ignored.
Beware the "verbose" programmer who's statement strayed into column 73.

On a punched card it was reasonably easy to spot. But editing code on a teletype using a line editor was a different matter.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web