Java quiz series

[red.evil]

Code: (java) [Select]

class Quiz
{
   public static void main( String args[] )
   {
      int x = 0;
      int y = 55;
 
     try
     {
  System.out.println( y/x );
     }
     catch( Exception e )
     {
         e.printStackTrace();
     }
  }
}

Will there be an exception thrown?
If yes:
  when will it be thrown?
     At compiletime? or
     Runtime?
  what Exceptiontype is it?
  Why is it thrown at this specific time ( Runtime / Compiletime ) ?
 

[Uriah]

An exception will be thrown because you are dividing by zero, at run-time because this is a semantic, not syntax error, and the exception is "ArithmeticException"


If im correct I dont have the next quiz.

[red.evil]

It's correct.

[Deque]

Code: [Select]

System.out.println(0610 + 0b10);
What is the result of that addition and why?

[red.evil]

The result is 394, because 0610  ( = 392|10 ) is a number written in octal number system, which you can see on the leading 0 and 0b10 ( = 2|10 ) is one in binary system, because of the leading 0b. This binary notation works since SE 7.

[Deque]

The result is 394, because 0610  ( = 392|10 ) is a number written in octal number system, which you can see on the leading 0 and 0b10 ( = 2|10 ) is one in binary system, because of the leading 0b. This binary notation works since SE 7.

Correct. Do you have a next quiz?

[red.evil]

Yep, I have one:

Code: (Java) [Select]

class Clazz extends Runnable
{
   private volatile boolean stop = false;
   
    public void stop()
    {
        stop = true;
    }
 
    @Override
    public void run()
    {
        while( !stop )
        {
            // do Something
        }
    }
}
Why does the variable stop have to be volatile?

[Deque]

I would like to carry on with the quiz and since no one answered the last question I will try.

volatile is there to prevent optimizations of the compiler that might interfere with threaded access to the field; especially caching is a problem here.
So if you create a thread with that Runnable, the volatile makes sure you will always get the right value.

[red.evil]

Yep, thats right!

But, I talked to my lecturer today if I have to use it always or not, because of the leaking/ caching problem . He said, he never used it and also didn't have problems, so maybe it's already fixed by the JVM. If someone does have more information about it, it would be nice if he/she would share it with me.

[Deque]

Yep, thats right!

But, I talked to my lecturer today if I have to use it always or not, because of the leaking/ caching problem . He said, he never used it and also didn't have problems, so maybe it's already fixed by the JVM. If someone does have more information about it, it would be nice if he/she would share it with me.

Fixed?
This is nothing to be fixed. Caching is done to optimize, to get more speed. This is on purpose. If your professor says such things, this is just a big facepalm.
And of course you have to use volatile in certain circumstances if you use threads. Just because your professor didn't get a problem, it doesn't mean that a problem is not possible with code that doesn't use volatile where it should be used. Especially threaded code is hard to test, the order of execution of the threads might be different every time you run the code. So it is a bit of luck to get the problematic execution orders while testing.

See here for more explanation: https://stackoverflow.com/questions/106591/do-you-ever-use-the-volatile-keyword-in-java


Next quiz:

Code: [Select]

public static void main(String... args) {
       float i = 0;
       while (i != i + 1) {
           i++;
       }
       System.out.println(i);

}
Is this an endless loop?
Why (or why not)?

[daxda]

Next quiz:

Code: [Select]

public static void main(String... args) {
       float i = 0;
       while (i != i + 1) {
           i++;
       }
       System.out.println(i);

}
Is this an endless loop?
Why (or why not)?

I believe it is an endless loop, 'i' can never be higher than 'i'+1,
which means that the check 'i' != 'i'+1 is always True.

I have no clue about Java so feel free to create a new quiz.

[red.evil]

I think I inartfully expressed what I mean.
I meant it like, the JVM maybe already recognises that there's a variable used in a multithread system. So it's updating it in a way you won't get problems because of the caching (like MESI does on a physical multicore system). But yep, the reordering-problem still exists.

[Deque]

I believe it is an endless loop, 'i' can never be higher than 'i'+1,
which means that the check 'i' != 'i'+1 is always True.

Nope.

[Uriah]

I dont really understand everything, but i think it has something to do with the finite precision of floating point numbers. There is a certain point where x == x + 1 because of this. For these same reasons you have to be careful of comparing and doing important calculations with them because of their imprecision.

[Deque]

I dont really understand everything, but i think it has something to do with the finite precision of floating point numbers. There is a certain point where x == x + 1 because of this. For these same reasons you have to be careful of comparing and doing important calculations with them because of their imprecision.

That is correct.
float has 6 to 9 significant decimal digits precision. These are represented in the mantissa which uses 23 bits. Additionally there is 1 sign bit and 8 bits for the exponent.
Now imagine you have a pretty high number, the bits in the mantissa won't be enough to hold all of the digits. The exponent part makes it still possible to use very high numbers (or small ones), but the distance between two consecutive numbers that are representable with float grows with the numbers growing. So once you get to the point where this distance is higher than 1, (x == x + 1) is true, because the 1 you add will just be ignored as (x+1) is not representable anymore.