Java 1.6 becoming idiot-proof or just slack?

[Joshua Cranmer]

Hi,

I've had the following code running on Java 1.6 happily for sometime and
only after someone tried to compile it with 1.4 did I discover my recurring
:-( school-boy error of saying intVar = new Object. I've changed the code so
that it now it says intVar = Integer.parseInt(stringStuff) but I was just
wondering why it ever worked. JAVAC "just knew" I wanted the .value()
instead of the object or is this really useful functionality that comes in
Java 1B

Ever hear of autoboxing? int's and Integers can freely convert between
the other most of the time. (Came from 1.5)

 

[Richard Maher]

Hi,

I've had the following code running on Java 1.6 happily for sometime and
only after someone tried to compile it with 1.4 did I discover my recurring
:-( school-boy error of saying intVar = new Object. I've changed the code so
that it now it says intVar = Integer.parseInt(stringStuff) but I was just
wondering why it ever worked. JAVAC "just knew" I wanted the .value()
instead of the object or is this really useful functionality that comes in
Java 1B

Regards Richard Maher

public class DateVMS
{
int year;
int month;
int day;
int hour;
int minute;
int second;
int hsecs;

DateVMS (String inDate)
{
this.year = new Integer(inDate.substring( 0, 4));
this.month = new Integer(inDate.substring( 4, 6));
this.month--;
this.day = new Integer(inDate.substring( 6, 8));
this.hour = new Integer(inDate.substring( 8, 10));
this.minute = new Integer(inDate.substring(10, 12));
this.second = new Integer(inDate.substring(12, 14));
this.hsecs = new Integer(inDate.substring(14, 16));
}
public int getYear()
{
return year;
}

 

[Lew]

Ever hear of autoboxing? int's and Integers can freely convert between
the other most of the time. (Came from 1.5)

Until I read your response I was scratching my head trying to figure out where
in the posted code the OP's difficulty was. I just could not see anywhere in
the posted code a

It takes a gift of active listening to step outside the problem statement to
discern the real issue. It was instructive to me to find my blind spot in this
case.

-- Lew

 

[Daniel Pitts]

Hi,

I've had the following code running on Java 1.6 happily for sometime and
only after someone tried to compile it with 1.4 did I discover my recurring
:-( school-boy error of saying intVar = new Object. I've changed the code so
that it now it says intVar = Integer.parseInt(stringStuff) but I was just
wondering why it ever worked. JAVAC "just knew" I wanted the .value()
instead of the object or is this really useful functionality that comes in
Java 1B

Regards Richard Maher

public class DateVMS
{
int year;
int month;
int day;
int hour;
int minute;
int second;
int hsecs;

DateVMS (String inDate)
{
this.year = new Integer(inDate.substring( 0, 4));
this.month = new Integer(inDate.substring( 4, 6));
this.month--;
this.day = new Integer(inDate.substring( 6, 8));
this.hour = new Integer(inDate.substring( 8, 10));
this.minute = new Integer(inDate.substring(10, 12));
this.second = new Integer(inDate.substring(12, 14));
this.hsecs = new Integer(inDate.substring(14, 16));
}
public int getYear()
{
return year;
}

Java 1.5 introduced something called auto boxing/unboxing, which
allows primitives to be automatically boxed by there Object
counterpoints, and visa versa.

In any case, you'd be better off using
Integer.parseInt(stringToParse). It returns an "int" rather than an
"Integer". Your existing code has the effect of parsing an int,
creating an Integer object around it, and then converting it BACK to
an int.

Oops

 

[Lew]

Java 1.5 introduced something called auto boxing/unboxing, which
allows primitives to be automatically boxed by there Object
counterpoints, and visa versa.

In any case, you'd be better off using
Integer.parseInt(stringToParse). It returns an "int" rather than an
"Integer". Your existing code has the effect of parsing an int,
creating an Integer object around it, and then converting it BACK to
an int.

Oops

Conceivably the JIT could optimize that away. In fact, static analysis of the
program would lead to inlining and optimizing that whole mechanism away.

The real question is what best expresses the programmer's intentions, which in
this instance argues for the parseInt() call, but it looks like Java is
intentionally blurring the distinction between primitives and their boxed
versions.

Weirdly, Java tries to make it easier on programmers with autoboxing, then we
aren't comfortable with it so we go back to the more rigorous ways anyhow.

-- Lew

 

[Ashoka!]

Conceivably the JIT could optimize that away. In fact, static analysis of the
program would lead to inlining and optimizing that whole mechanism away.

The real question is what best expresses the programmer's intentions, which in
this instance argues for the parseInt() call, but it looks like Java is
intentionally blurring the distinction between primitives and their boxed
versions.

Weirdly, Java tries to make it easier on programmers with autoboxing, then we
aren't comfortable with it so we go back to the more rigorous ways anyhow.

-- Lew

We are from the old school Lew, Java is copying C# with this auto
boxing stuff. If you have worked with C# you know the problems it can
lead to errors in parts of the code you have never written and the
only way to correct them is by changing project settings.

regards
Usman Ismail

 

[Chris Uppal]

Weirdly, Java tries to make it easier on programmers with autoboxing,
then we aren't comfortable with it so we go back to the more rigorous
ways anyhow.

If you are the kind of person who likes that kind of ambiguity (between
primitive values and their object wrappers) then presumably you wouldn't have
been attracted to Java in the first place. (The "you" is generic here, of
course, not personal).

Some people like -- or at least, don't really notice -- semantic slush, but why
would they want to use Java ?

-- chris

 

[Joshua Cranmer]

Weirdly, Java tries to make it easier on programmers with autoboxing,
then we aren't comfortable with it so we go back to the more rigorous
ways anyhow.

-- Lew

If I remember correctly, the main impetus for auto-boxing/-unboxing was
because of generics, thus it is probably only intended for generics.
I've never used it outside of the Collections, although it is
conceivable that a few classes in Swing are slightly helped by the
introduction of auto-boxing/-unboxing.

 

[Daniel Pitts]

If I remember correctly, the main impetus for auto-boxing/-unboxing was
because of generics, thus it is probably only intended for generics.
I've never used it outside of the Collections, although it is
conceivable that a few classes in Swing are slightly helped by the
introduction of auto-boxing/-unboxing.

It has some "usefulness". It makes code "look" cleaner if you have
need to convert between primitives and objects.

For instance, if you have a Form object which can take an optional
integer.

public class Form {
private Integer myInteger;
public void setMyInteger(Integer i) {
myInteger = i;
}
public Integer getMyInteger() {
return myInteger;
}
}

But, say you have a case where you need a default value of 43...

In the past, you would have to have written
myForm.setMyInteger(new Integer(43));
but now, you can safely use myForm.setMyInteger(43);

 

[Richard Maher]

Hi Daniel,

Your existing code has the effect of parsing an int,
creating an Integer object around it, and then converting it BACK to
an int.

Oops

Bit of room to move on the performance front then

I've gone for the Integer.parseInt(myString) strategy and all is well, but I
couldn't let the opportunity go without whinging about the JavaScript
version of parseInt() and why my 13 byte alert message was being truncated
to 11 bytes. No one here probably cares but just in case. . .

I receive 3 ASCII numeric digits over the network which tells my client how
many more bytes to read to get the message text; in this case "013" or
thirteen bytes to come. No with Java you get a lovely 13 returned from
parseInt("013") but with Javascript you get 11 because JS has taken it upon
itself to deem the leading "0" as a radix identifier and tell me it's octal
:-( So now I have to tell it it's decimal with the second parameter.
Standards eh?

Cheers Richard Maher

 

[Richard Maher]

Hi Joshua,

Ever hear of autoboxing?

Nope.

But I've looked it up now thanks to your reply.

Cheers Richard Maher

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I receive 3 ASCII numeric digits over the network which tells my client how
many more bytes to read to get the message text; in this case "013" or
thirteen bytes to come. No with Java you get a lovely 13 returned from
parseInt("013") but with Javascript you get 11 because JS has taken it upon
itself to deem the leading "0" as a radix identifier and tell me it's octal
:-( So now I have to tell it it's decimal with the second parameter.
Standards eh?

Java and JavaScript share 4 letters in the name, but not that much else.

Different language different rules.

Arne

 

[fy4.net]

Hi,

I've had the following code running on Java 1.6 happily for sometime and
only after someone tried to compile it with 1.4 did I discover my recurring
:-( school-boy error of saying intVar = new Object. I've changed the code so
that it now it says intVar = Integer.parseInt(stringStuff) but I was just
wondering why it ever worked. JAVAC "just knew" I wanted the .value()
instead of the object or is this really useful functionality that comes in
Java 1B

Regards Richard Maher

public class DateVMS
{
int year;
int month;
int day;
int hour;
int minute;
int second;
int hsecs;

DateVMS (String inDate)
{
this.year = new Integer(inDate.substring( 0, 4));
this.month = new Integer(inDate.substring( 4, 6));
this.month--;
this.day = new Integer(inDate.substring( 6, 8));
this.hour = new Integer(inDate.substring( 8, 10));
this.minute = new Integer(inDate.substring(10, 12));
this.second = new Integer(inDate.substring(12, 14));
this.hsecs = new Integer(inDate.substring(14, 16));
}
public int getYear()
{
return year;
}

More see here!
http://www.flash50.com/index.php

 

[Lew]

More see here!
http://www.spam...50.com/index.php

What a piece of crap your website is, fy4. It's poorly laid out, poorly
written, won't work if Javascript is disabled, visually ugly and has
absolutely nothing to do with Java. Garbage.

I hope this feedback is useful to you. Others have already spoken to your
bloody offensive spam practice. Also garbage.

-- Lew