Float.MIN_VALUE

[10godina]

When I try to use:

float f = Float.MIN_VALUE; or
System.out.println(Float.MIN_VALUE);

I get:

Exception in thread "main" java.lang.Error: Unresolved compilation
problems:
Float.MIN_VALUE cannot be resolved

Why? I use jre1.5.0_12. According to java api it should be ok:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Float.html

 

[Arne Vajhøj]

When I try to use:

float f = Float.MIN_VALUE; or
System.out.println(Float.MIN_VALUE);

I get:

Exception in thread "main" java.lang.Error: Unresolved compilation
problems:
Float.MIN_VALUE cannot be resolved

Why? I use jre1.5.0_12. According to java api it should be ok:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Float.html

That lines compiles fine here.

Can you post your entire program showing the problem ?

You have not created your own Float class ??

Arne

 

[Stefan Ram]

System.out.println(Float.MIN_VALUE);

What happens when you use the following statement?

java.lang.System.out.println( java.lang.Float.MIN_VALUE );

 

[10godina]

What happens when you use the following statement?

java.lang.System.out.println( java.lang.Float.MIN_VALUE );

package operators;

public class Exponential {

public static void main(String[] args) {



java.lang.System.out.println( java.lang.Float.MIN_VALUE ); // works
fine
System.out.println(Float.MIN_VALUE); //error
System.out.println(Float.MAX_VALUE); //error
System.out.println(Double.MIN_VALUE); //works fine
System.out.println(Double.MAX_VALUE); //works fine

}

}

 

[Owen Jacobson]

  What happens when you use the following statement?

java.lang.System.out.println( java.lang.Float.MIN_VALUE );

package operators;

public class Exponential {

        public static void main(String[] args) {

                java.lang.System.out.println( java.lang.Float.MIN_VALUE ); // works
fine
                System.out.println(Float.MIN_VALUE); //error
                System.out.println(Float.MAX_VALUE); //error
                System.out.println(Double.MIN_VALUE); //works fine
                System.out.println(Double.MAX_VALUE); //works fine

        }

}

If you have a class named Float in the operators package that's
visible at compile time, it will be used for the two "error" lines
instead of java.lang.Float. However, fully-qualified class names
always refer to the same class, which is why the first line works (you
only needed to qualify java.lang.Float, not System).

 

[Patricia Shanahan]

What happens when you use the following statement?

java.lang.System.out.println( java.lang.Float.MIN_VALUE );

package operators;

public class Exponential {

public static void main(String[] args) {



java.lang.System.out.println( java.lang.Float.MIN_VALUE ); // works
fine
System.out.println(Float.MIN_VALUE); //error
System.out.println(Float.MAX_VALUE); //error
System.out.println(Double.MIN_VALUE); //works fine
System.out.println(Double.MAX_VALUE); //works fine

}

}

The implication is that there is a class Float that is not
java.lang.Float, and does not have a static field MIN_VALUE.

Are the errors at compile time or run time? How are you compiling or
running the program?

Patricia

 

[10godina]

The implication is that there is a class Float that is not

java.lang.Float, and does not have a static field MIN_VALUE.

There was a class Float which i made in the same package.

Is there a way to see which class is compiler trying to invoke. I'm
using IBM's Eclipse IDE.

Thanks you all.

 

[Lew]

There was a class Float which i made in the same package.

Is there a way to see which class is compiler trying to invoke. I'm
using IBM's Eclipse IDE.

The class in the same package will be used over any class in another package
if referenced by the unqualified name, by the rules of the language. There is
no need to "see which class [the] compiler [is] trying to invoke" - it's
deterministic. IDE and JVM don't matter. By putting the custom class 'Float'
in the same package as your other class, you completely hid the
java.lang.Float class as an unqualified name from the program.

<http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.6>

It's a really, really, really, really bad idea to name a class the same as a
class in java.lang.

 

[Patricia Shanahan]

There was a class Float which i made in the same package.

If that is really, really necessary, you will have to use
"java.lang.Float" any time that is what you mean in that package.

Because of the option of fully qualifying the name, it is not an error
to reuse a public type name from java.lang. However, it is usually a
very bad idea, because anyone reading your code will tend to assume
"Float" means "java.lang.Float".

Patricia

 

[10godina]

It was really stupid to name that class Float. Even I didn't believe
that I made one.

Thank you all.

 

[Stefan Ram]

If that is really, really necessary, you will have to use
"java.lang.Float" any time that is what you mean in that package.

Another possibility is

import java.lang.Float;

once at the top of the source file.

 

[Roedy Green]

There was a class Float which i made in the same package.

The theory in you can use packages to sort of which version of Float
you mean, but in practice you end up just shooting yourself in the
foot.

Sun screwed people up by reusing the word List for two totally
different purposes, but the compiler often gets discombobulated
especially when you use both in the same program.

The bottom line, give your classes unique names. It confuses the
compiler less. It confuses people less. Package disambiguation is an
emergency measure.

 

[Roedy Green]

Exception in thread "main" java.lang.Error: Unresolved compilation
problems:
Float.MIN_VALUE cannot be resolved

you have two classes called Float in different packages. Either rename
to something unique or fully qualify all references to each flavour of
Float with the package name.

See http://mindprod.com/jgloss/package.html

 

[Mark Space]

There was a class Float which i made in the same package.

Is there a way to see which class is compiler trying to invoke. I'm
using IBM's Eclipse IDE.

There should be an error message when you try to compile. Not one show
in the IDE when your editing but one on the console window when you
actually press the build button.

What does that console output say about the class it's getting the error on?

 

[Lew]

Another possibility is

import java.lang.Float;

once at the top of the source file.

Technically incorrect, but even if it worked it would be too ghastly. It's
much better not to hide java.lang classes, and so much easier. The import
does not solve the cognitive disconnect for the code maintainers - only
correct naming practices will do that.

The unqualified class name will cause a compile-time error due to the conflict
between the names, unless it's in the declaration of the local Vector class
itself.

The link I posted earlier this thread mentions:

The scope of a top level type is all type declarations in the package in which
the top level type is declared. ....
A compile-time error occurs if the name of a top level type is also declared
as a type by a single-type-import declaration (§7.5.1) in the compilation unit
(§7.3) containing the type declaration.

<http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.6>

 

[Lew]

There should be an error message when you try to compile.

Why? It's perfectly legal as long as he doesn't try to do a single-type
import on java.lang.Float. Just awful, but legal.

 

[Patricia Shanahan]

Technically incorrect, but even if it worked it would be too ghastly.
It's much better not to hide java.lang classes, and so much easier. The
import does not solve the cognitive disconnect for the code maintainers
- only correct naming practices will do that.

The unqualified class name will cause a compile-time error due to the
conflict between the names, unless it's in the declaration of the local
Vector class itself.

I think it does work in all compilation units other than the one
containing the Float declaration.

"A single-type-import declaration d in a compilation unit c of package p
that imports a type named n shadows the declarations of:

* any top level type named n declared in another compilation unit of p.
* any type named n imported by a type-import-on-demand declaration
in c.
* any type named n imported by a static-import-on-demand
declaration in c. "

http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.3.1

"import java.lang.Float;" is a single-type-import, so it shadows a top
level type Float in another compilation unit of the same package.

Of course, it would prevent simple name access to the in-package Float.

Patricia

 

[Lew]

I think it does work in all compilation units other than the one
containing the Float declaration.

"A single-type-import declaration d in a compilation unit c of package p
that imports a type named n shadows the declarations of:

* any top level type named n declared in another compilation unit of p.
* any type named n imported by a type-import-on-demand declaration
in c.
* any type named n imported by a static-import-on-demand declaration
in c. "

http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.3.1

"import java.lang.Float;" is a single-type-import, so it shadows a top
level type Float in another compilation unit of the same package.

Of course, it would prevent simple name access to the in-package Float.

I see where I went wrong. You are absolutely correct on that and I was mistaken.