small mistake in ExamLab

[Suranga Nath Kasthurirathne]

and im just as stunned as you are... wonder whats happening... but im pretty sure that my exam certificate says that the cut off mark is 66% or so....

[Tommi Vd]

how long is taht ago?

i'm making this examn from the examlab and i do not understand a question:

It's a question about serialization,

A class Forest has a Tree but it is declared static...
The Tree class does not implements Serializable.
Now they try to serialize a forest object, so i think this must succeed without exception that class Tree needs to implement Serializable?

Why? Because static vars aren't serialized right...

any help?

[Suranga Nath Kasthurirathne]

that was on the first of this month

[Suranga Nath Kasthurirathne]

static objects wont get serialized.. but that wont give an error.. only when you try to access the static object do you get a null pointer excaption..

but if it was not static and yet did not impliment serilizable then an exception is thrown because it sees that tree is not serializable...

hope that this answer is correct ...

[Tommi Vd]

Well you say what i mean, but in the question of the exam it gives an exception because the class Tree is not serializable...
But the instnace of tree is declared static in the class from witch an instance gets serialized...
So actually there shouldn't be an error...?


you understand what i mean?

  
class Tree{}

class Forest{
     private static Tree tree = new Tree();
     private static void main(String[] args){
           Fores f = new Forest();
          
           //SERIALISATION AND DESERIALISATION

     }
}

  

Here the answer is exception thrown because class Tree isn't serializable. But the instance of Three in Forest is static...

[Tommi Vd]

Anyone?

[Lucas Smith]

You pass that static reference to writeObject method so JVM is going to serialize it - but the exception is thrown.

But Serialization won't be one exam. Bert wrote that.

[Ankit Garg]

Thomas Van Driessche wrote:Anyone?

Please read this. You should be patient about answer to your questions ...

[Tommi Vd]

oops sorry

not a reference of tree is passed to writeobject, a reference of f.
And since the instance var tree from f is static, there shouldn't even be a try to serialise that...
So there can not be thrown a runtime exception though?

[Nitish Bangera]

Well....passing the tree reference is ok. But letz see the JVM looks at the class and sees the class Forest is serializable and what's this this class has a relationship with the Tree class i.e Tree is in the Object graph of Forest. So following the all or nothing rule the JVM fails at runtime throwing the NOSerializtionError : Tree.

[Ankit Garg]

Thomas Van Driessche wrote:oops sorry

You broke another rule No Need To Say Sorry. But don't say sorry for breaking the rule or you'll broke that rule again

not a reference of tree is passed to writeobject, a reference of f.
And since the instance var tree from f is static, there shouldn't even be a try to serialise that...
So there can not be thrown a runtime exception though?

Your Forest class itself is not serializable. Its not about the Tree class. Your Forest class needs to be serializable for you to be able to serialize its objects...

[Nitish Bangera]

Actually he copied the question wrongly from examlab. Well here yes the FOrest is not serializable. Even if it implemented Serializable then also no instance of forest will be serializable. This question was discussed here Coderanch

[Tommi Vd]

Static variables are implicitly transient - that's true, but it will not apply here, because we are serializing the object of the tree variable directly.

i do not really get this...
is it because the reference to the object is static? but the object itself isn't?

[Lucas Smith]

AGAIN: Serialization will NOT be on exam! And read my post above. Thanks!

[Nitish Bangera]

  public class MT extends Thread{
     private static StringBuffer sbf=new StringBuffer("SBF");
     private static StringBuilder sbl=new StringBuilder("SBL");
     private static Thread mt;
     private static int x=0;

     public void run(){
          switch(x){
               case 1:
                    synchronized(sbf){
                         try{mt.join();}catch(Exception e){}
                    }break;

               case 2:
                    synchronized(sbl){
                         try{mt.join();}catch(Exception e){}
                    }break;
          }
     }

     public static void main(String args[])throws Exception{

          mt=Thread.currentThread();
          MT mt1=new MT();
          MT mt2=new MT();
          x=1;
          mt1.start();
          Thread.sleep(1000);
          x=2;
          mt2.start();
          sbl.append("AAA");
          Thread.sleep(1000);
          System.out.print("Builder Passed, ");
          sbf.append("AAA");
          System.out.print("Buffer Passed, ");
     }
}  

This is 44th question of Examlab. Well I think the explanation is a little bit off. See when mt2.start() is executed it will not run. Main will continue to run and will append sb1 and then it sleeps. So synchronization or not this code is fine. In the explanation it was said that the lock sb1 was held by a thread but due to non synchronized methods it can change it.

[Lucas Smith]

The whole question is good, but tricky.

  public class Testing2 extends Thread{
     private static StringBuffer sbf=new StringBuffer("SBF"); //synchronized methods
     private static StringBuilder sbl=new StringBuilder("SBL"); //non synchronized methods
     private static Thread mt;
     private static int x=0;

     public void run(){
          switch(x){
               case 1:
                    synchronized(sbf){ //sbf's lock is acquired
                         try{mt.join(); //join() holds the lock ant waits for finishing MainThread
                         System.out.println("mt1");
                         }catch(Exception e){}
                    }
                    break;

               case 2:
                    synchronized(sbl){
                         try{mt.join();
                         System.out.println("mt2");
                         }catch(Exception e){}
                    }
                    break;
          }
     }

     public static void main(String args[])throws Exception{

          mt=Thread.currentThread();
          Testing2 mt1=new Testing2();  //only object
          Testing2 mt2=new Testing2(); //only object
          x=1; //case 1 will be chosen
          mt1.start(); //m1 thread starts-> going to runnable
          Thread.sleep(1000);
          x=2;
          mt2.start();
          sbl.append("AAA");
          Thread.sleep(1000);
          System.out.print("Builder Passed, ");
          sbf.append("AAA"); //is actually synchronized append(...) so MainThread has to wait for the lock
          					//which is acquired by mt1 thread - deadlock
          System.out.print("Buffer Passed, ");
     }
}  

The only thing that will be printed is: BuilderPassed,

ExamLab's thread questions are the hardest ones

[Nitish Bangera]

I got the answer right i understand the problem. I read the explanation and i thought the explanation was little off coz the m2.start() doesn't run untill the thread sleeps again. So what i was telling is that m2 won't run so it won't acquire the lock for sb1 that's all.

  mt2.start();
          sbl.append("AAA");  //<--< explanation said that as sb1 append is not synchronized so even main thread can change. What i meant was mt2 is not running as main hasn't slept yet so it will be the same even if sb1 was a StringBuffer. 
          Thread.sleep(1000);  

[Lucas Smith]

How do you know that mt2 won't run? You can not predict it. Thread Scheduler can put MainThread into Runnable and let mt1 to go. The fact is Thread.sleep(...) helps with thread switching but without it the switching can perform.

[Nitish Bangera]

Well the other way round is also can be debated on....but here those things don't matter hehe.