Figure : architectural diagram with most popular technologies used 

Web architecture basically focuses on how web application is internally built regarding its web client and the web server with all the other supporting services and components.

Currently there are many technologies being used in different components of web architecture.Different kind of technologies have their inherent advantages as well as draw backs. So when a web developer is selecting the most matching technology for his web application he needs to first go through and find what is his requirement and which one is more serving to his this requirement.

Synchronization is basically connected with aquiring the lock,but what is this lock?
Every object in java has its own one and only one lock.So acquiring the lock means,one thread's getting that object's lock letting other threads to wait till it releases it.
Only methods and code blocks can have synchronized option and not variables or classes. 
When a thread goes to sleep,it does not release its locks.
A thread can acquire more than one lock. 
Anyway, synchronization slows down the process as threads have to wait to grab the lock.
Now look at this Q

• Q)

public class ExceptionEg implements Runnable{
public synchronized void run() {
    System.out.print("A");
    System.out.print("B");
}   
    public static void main(String[] args) {
    ExceptionEg r=new ExceptionEg();
    new Thread(r).start();
    new Thread(r).start();
       
    }
}

 What would be the output?
- We know that a thread can be started only once. Before going to synchronization,you should note that .start() method is called twice.Would that be an issue?
No,because you need to see that it's not the same thread started twice,but two different threads created from the same runnable which is perfectly legal.

-Now from the synchronization aspect,you see that method run() has been synchronized,which means that a thread to execute run() it should first grab the object's lock.

Fine,now how many locks are available? To know that we need to know how many objects are there? You can see there's only one runnable object named 'r' ,start() method is called to the same runnable object 'r' through two different thread objects.So one lock.

 

First of all note that the aim of these lessons are not to cover simple basics (like no guarantee threads would run in an order) but to give a deeper understanding on tricky points.



Have you ever used a thread in java? You can't say no :D You should've definitely used public static void main(String[] args) { which is a thread!Threads begins as an instance of java.lang.Thread whether run() method is in Thread subclass or a Runnable implemetation ,you anyway need a Thread object.

• A thread in java always begins by invoking run() method.
• When you say t.start() the JVM creates a new stack for the newly created thread to run. .You call start() on a Thread instance and not Runnable instance.
• Thread states are as follows

  

• As we discussed before,not handling checked exceptions would lead to compilation failures,unlike runtime exceptions

 public static void main(String[] args) {
        throw new Exception();
         }

This is CE (for here onwards,I'll refer it CE=compilation error:P )

• Creating Exceptions,

 

•   See throws clause as a filter (like we saw try - catch as nets ).They inform an exception may come.

 

• Q)

public class ExceptionEg {
   
    static void A() throws Exception{
        System.out.print("A");
        throw new Exception();
    }
    static void B(){
        System.out.print("B");
        A();
        System.out.print("C");
    }
   

    public static void main(String[] args) {
        try {
            System.out.print("D");
            B();
            System.out.print("E");
           
        } catch (Exception e) {
            System.out.print("caught");
        }
       
    }
}

what would be the output?

 

Output would be D B A then CE.

So how can we avoid the CE? simply adding a filter (throws clause) at B method or putting a net (try - catch block) at  A or B methods.

  

• What happens at method overriding then? Easy,two simple rules

If the superclass method does not declare an exception 

*   If the superclass method does not declare an exception, subclass overridden method cannot declare the checked exception but it can declare unchecked exception.  

If the superclass method declares an exception 

*   If the superclass method declares an exception, subclass overridden method can declare same, subclass exception or no exception but cannot declare parent exception. 

•  You get an ExceptionInInitializerError if something goes wrong in the static initializer block.
  
  class C
  {
    static
    {
       // if something does wrong -> ExceptionInInitializerError
    }
  }

 So hope that this wraps up all the necessary important points that a java developer should know when it comes to exception handling :)

Even if you were following the correct steps of installing ubuntu along side with windows,there is a possibility that, at the installation type window, you are shown the whole hard disk instead of the hard drive with windows partition like the figure below.

 

  

or if you were trying to install only ubuntu,you may have warned that,

 

Then you are having this problem that I'm addressing here.

This happens mainly because if you had Windows 8,it is in UEFI mode with gpt partitions, and then if you are reinstalling like Windows 10 in BIOS boot mode,  Windows DOES NOT correctly convert from gpt to MBR(msdos). It leaves backup gpt table.  

The main problem here is even though you have some gpt left in your hard disk,if you check hard drive from windows (from disk manager's properties or from command prompt) it does not show you that.

 

Golden splendor of the moon,drawn on the night sky.
Stolen from the sun,but neither is he proud.
It is just the burning of his inner spirit into flames.


The curly waves that ocean wears,
a wonderful creation of moving breeze.
But  even the breeze is not the master of his helm.


Nothing can beat the smiling rose with her dark red wings.
Oh poor she! Her very own weapon has betrayed her.
Left her alone making her crying in a fading white dress.


Every corner,if looked closer,filled with reflections of that eternal truth.
Nothing lasts,not even the pain of losing.
When even the ‘ownership’ does not really  own a meaning,

Why bother? Why greedy?

GoogleDrive, OneDrive, Dropbox can be hacked without user’s passwords

You may most probably have heard of Man-in-the-Middle attacks where a malicious actor makes a cyber attack by inserting himself between the sender and receiver and gain access to their confidential and/or valuable data. While last couple of years, the giant enterprises of world got so shocked by  Man-in-the-Middle attacks,well,now they have something more to worry seriously about.

According to the latest research presented in Black Hat conference 2015,Las Vegas, Man-in-the-Cloud(MITC)  is the new type of cyber attack which gets access to cloud-based files, get this,even  without using any particular malicious code  or compromising the victim’s user name or password, thus making  it really difficult to detect.  If  it’s not explicit credentials  or Man-in-the-Middle, what is it?,you may be wondering. The magic wand is synchronization token. 

Let me explain how it happens,as per the  Black Hat conference .MITC attacks are driven on file synchronization services such as GoogleDrive, OneDrive, Dropbox, and Box as their infrastructure for command and control (C&C), data exfiltration, and remote access.File  synchronization allows the users to have the most updated copies of file repositories across the multiple devices.Service providers through a synchronized software installed at the user end,checks for changes made in the cloud hub and mirrored them locally in “sync folder” through a dedicated channel and vice versa. Authenticating to cloud is mostly done using a synchronized token by them which would not compromise the whole account but gives the ability to share with other collaborators through compromised token.

Now let’s see how the vulnerability of synchronization token open space for MITC attacks.

    ⦁ After the authentication process with explicit credentials,file synchronization does not require them again for any further operations since it’s done through synchronization token.

⦁ This machine independent token would be then stored in a file or a registry depending on the service provider.

⦁ The attacker creates an account and stores a synchronization token which represents attacker’s account in the victim’s machine’s appropriate place.

⦁ Then the needed token is copied to victim’s sync folder,so now the attacker has the token which is being synchronized with his created account

That is it, easy peasy! No middle-man thing ,No username,No password.

See,that is why it is hard to avoid MITC attacks or to trace them because no footprint is left as such,but just a simple code 

                                                                ⦁      to modify file

                                                                ⦁ to do a registry edit

Even though the thought of exposing your cloud based data to a state which can possibly be hacked would give you goosebumps, still a totally trusted solution cannot be recommended.An enterprise can use Cloud Access Security Broker (CASB) to monitor and detect an abnormal behavior in their file synchronization services.So it is finally if your dedication towards controlling access to synchronized file is highter,the security level would be higher,which on the other hand need not to be mentioned.

   There are a few more important things to cover in runtime exceptions,explaining them using example questions would give a proper understanding.

• Q)

public class ExceptionEg {

    static void m(){
        try {
            throw new RuntimeException();
        } catch (NullPointerException e) {
           
        } finally {
            System.out.print("Hey");
        }
    }
    public static void main(String[] args) {
        try {
            m();
        } catch (IllegalArgumentException e) {
            }
        }
}

What is the output?
a)prints Hey followed by an exception report
b)prints an exception report followed by Hey
c)prints only Hey
d)compilation fails

At method m,a runtimeException is thrown,but the relevant catch block cannot catch the thrown exception.(Because RuntimeException > NullPointerException).So the runtime exception would be propagated to m method's caller which is the main method.Besides that,since try block was executed,its relevant finally block should definitely executed.So "Hey" would be printed.

Now the exception is at the main methods level.But even its catch block cannot catch this exception because IllegalArgumentException is a subclass of RuntimeException (if it was other way round,it could've caught)

But will a compilation error ocurr? No,because the not handle exception is a runtime exception and hence code will compile fine and would give an exception at runtime.
So the answer is: (a) 

•  Q)

public class A{
    public void method1() {
        B b=new B();
        b.method2();
        System.out.print("A");
    }
}

public class B{
    public void method2(){
        throw new NullPointerException();
    }
}

public class ExceptionEg {

    public static void main(String[] args) {
        try {
            A a=new A();
            a.method1();
          
        } catch (Exception e) {
            System.out.print("an error occured");
    }
      
    }
}
 
 Would "A" and "an error occured" print?
 Here the exception would be propagated to a.method1() line.Then the relevant catch block would catch the exception and print "an error occured".
But "A" would not be printed because at the moment an exception occured,the rest of the code would not run and immediately find a relevant catch block (but if there were a finally block it would run before - we discussed about it in the part I)

• Q)

public class ExceptionEg {
   
    static void test() throws RuntimeException{
        try {
            System.out.print("test");
            throw new RuntimeException();
        } catch (Exception e) {
            System.out.print("exception");
        }
    }

    public static void main(String[] args) {
        try {
            test();
           
        } catch (RuntimeException e) {
            System.out.print("an error occured");
    }System.out.print("end");
       
    }
}

 What would be the output?
First of all,you should notice this,

 Having nets of not matching way would not lead to a compilation failure because these two nets(catch blocks) are in different try blocks.
Immediate matching catch block(Exception e) will catch it.
Since those are runtime exceptions (or even if they were checked exceptions,since there are handled in try - catch block) program would not crash and hence,even the "end" would be printed after catching the exception.

so the answer is:

  "test exception end"
 



 

We'll try to go deep into java exception handling covering tricky things to gather a clear understanding,but first of all we need to understand the hierarchy of java exceptions. From java.lang -> Object -> Throwable.

• Throwables that can be included inside a try-catch can be divided like below.But note that you should only catch java.lang.Error at the highest level,even though catching them doesn't make sense in most of the cases.

 

• Exceptions should handled from narrower to the wider.See a try-catch block as a safe net that tries to catch a bomb which is about to hit the ground and blast.

  

• These are the only 3 legal formats of try - catch - finally,

• If you reach try block,then final block would always execute even if there is return in try block,unless you have system.exit() in try block!

• Q)

public class ExceptionEg {

    int bar() throws NullPointerException{
        throw new IllegalArgumentException();
    }
    public static void main(String[] args) {
        // TODO Auto-generated method stub
        System.out.print(new ExceptionEg().bar());
      
        }
} 

what would be the output?

a)compilation error because method does not handle or declare the thrown exception

b)compilation error due to a missing return statement in bar() method

c)compiles fine,but an exception is thrown at runtime.

There we cover very important two points in java.

 

1)Both NullPointerException and IllegalArgumentException are runtime exceptions which do not need to be handled or declared in throws clauses, but are always implied.You ended up in an exception report and not compilation failure.

But the checked exceptions would give compilation errors if not handled.

So,in this Q,not handling the exception thrown,or throwing an exception(IllegalArgumentException) other than what is specified in throws clause(NullPointerException) would not make any compilation errors.(If it was a checked exception,compilation would fail).

2)Then about not returning an int.

It would also not be an issue,because in java,instead of returning you can throw an error.

So the answer is:(c)

• Under what conditions should actually throw a runtime exception?

When you detect an error with the way your class or method is used, throw a runtime exception.
Generally, there are two categories of situations when you need to throw a runtime exception:

• Passing invalid parameter values - This is the most common cause of runtime exceptions. Most parameter validation exceptions should be runtime exceptions. Java provides several subclasses to signal these specific problems.
• Calling methods in a wrong sequence - This is another common cause. When certain methods cannot be called until a class finishes initialization or some other preparatory steps, calls at the wrong time should cause runtime exceptions

Let's talk more about runtime excepitions in part II :)