__Member Variables Access__:

You are not specifying an access modifier, Java defaults to package private. This means that any code outside of the package containing these classes can not access any of the member variables. This greatly reduces the usability of `Product` and `Location`.

In addition to this, there is nothing preventing code in the same package from replacing the existing values in `Inventory.Inv` or `Inventory.actualProduct`. If this happens, your code will start having many unexpected results (including runtime exceptions). Even if I don't replace the current instance, all of the public methods on both maps are accessible allowing for adding and removing elements outside of the control of `Inventory`.

Instead, you should make both `Inventory` member variables `private final`. These means 1) only `Inventory` can access the variables and 2) once they are assigned a value, it may not be changed. The second part will prevent `Inventory` from accidentally creating a new map instance.

In the case of `Product` and `Location`, they are both simple data objects. In these simple cases, it might be acceptable to directly expose the member variables. However, you have to take care in doing this. For example, say you want to represent a circle and in doing so, expose a `radius` variable. Everything is happy and other people start using your code. Then someone comes by and says because of reason X, the implementation of all circles needs to be done with a `diameter`. But since your public API already exposes a `radius` variable, removing it would everyone using your code now needs to change. However, if you had previously made the variable private and had a `getRadius()` method, you can easily change the class's underlying implementation without effecting anyone using your code.

-------
__Names__:

The convention for member variables in Java is camelCase. This means the concurrent map should not be capitalized.

My personal preference is to prefix member variables with an underscore. This is not a standard convention, so you can choose not to use it, but it has advantages.

1. You never have to worry about variable shadowing.
2. You never have to prefix them with `this.` because the function's arguments or local variables will never have the same name.
3. You can easily see what variables being used in a function are local versus member variables.

The variable names in `Inventory` are bad. `Inv` doesn't tell me any thing. If the class instance is the inventory, why does this member variable have a name that implies it is an inventory? Or maybe `Inv` actually stands for something else? I don't know because the name was abbreviated just to save a few characters. On the other side, `actualProduct` is a collection of things, but the name makes me thing it is only a single item. Your variable name should help the reader understand what value is being stored there. When you have multiple maps that are related, it is important to distinguish the relationship of the key to the value for each map. 

----

__Mutability__:

I've touched on it in a few places, but your code assumes people will use it the way it was indented and not break things. When you are trying to deal with thread safety, this is a very dangerous assumption. I've already explained why the `Inventory` member variables should be `private final`. When dealing with data objects like `Product` and `Location`, thread safety is much easier when the objects are not mutable. This means making their member variables `final` as well. Now you don't have to worry about the `id` for the pen object changing from 1 to 100.

__Map Lookups and Hashcodes__:

    Inv.put(actualProduct.get(id), Inv.get(actualProduct.get(id)).intValue()+quantity);

This is super ugly. In order to do a simple increment, you are doing 3 look ups. One can be immediately removed by storing the actual product in a local variable.
    
    Product acutal = actualProduct.get(id);
    Inv.put(acutal, Inv.get(acutal).intValue()+quantity);

The API you expose to the user expects an id, but mapping of products to quantities doesn't use the id as the key. Maybe that isn't the best way to do things.

Lets try changing the API to take a product instance instead of an id.

    void restockProduct(Product product, int quantity){
        //... 
        Inv.put(product, Inv.get(product).intValue()-quantity); 
    }

That seems nicer from the implementation stand point. However it won't work because two `Product` instances with exactly the same values are not seen as equivalent and will not be seen as the same key. In oder to solve this, you need to override `equals()` and `haschode()` for you data objects. And now that they are immutable, you don't need to worry about the hashcode of an instance changing when a member variable changes.

Taking a `Product` instance in the API might not be the correct answer, but having a map that uses a mutable value where the hashcode does not match what people would expect of objects with equivalent values is the wrong way to do things.

__Curly Brackets and Indentation__:

    void pickProduct(int id, int quantity){
        if(!actualProduct.containsKey(id))
        System.out.println("Sorry, the product is not available in inventory");

        else if(quantity<=0)
        System.out.println("Invalid Quantity");

        else if(Inv.get(actualProduct.get(id)).intValue()<quantity)
        System.out.println("Not enough stock");

        else
        Inv.put(actualProduct.get(id), Inv.get(actualProduct.get(id)).intValue()-quantity); 
    }

This is hard to people to read and easy to introduce unexpected bugs. If you aren't paying attention, you might not notice the chained `else` statements. Or you might want to add another statement to one of the blocks and completely break everything else. Instead, do the following:

    void pickProduct(int id, int quantity){
        if(!actualProduct.containsKey(id)) {
            System.out.println("Sorry, the product is not available in inventory");
        } else if(quantity<=0) {
            System.out.println("Invalid Quantity");
        } else if(Inv.get(actualProduct.get(id)).intValue()<quantity) {
            System.out.println("Not enough stock");
        } else {
            Inv.put(actualProduct.get(id), Inv.get(actualProduct.get(id)).intValue()-quantity); 
        }
    }

The indentations make it clear what the sub-block is. The curly brackets ensure that a second line can easily be added without worrying about if curly brackets are now required.

__Separation of Concerns__:

`Inventory` knows about anything this code will ever do and this prevents it from being used in other locations.

* `buildInventory()` is the only way to add items to the inventory. In tern, this means this code can only be used on a computer that:
1. Runs Windows
2. Has the directory path `\dev\eclipse_workspace\Warehouse\src\`.
3. That directory contains a files with a specific custom format.
* All of the other methods write directly to `stdout`. This means the code can only be used as a console application or it will write a bunch of output that might not make sense for a GUI application.
* There are very few operations that can be done with the information in the inventory and there is no way to do anything else.

I'm fairly confident that you are just starting out, so all of these things are not that surprising. It is more important to see how things can be done differently to allow you to reuse the code you have already written in different ways. While the following suggestions will make the project more complex, I hope you can see how it provides more flexibility.

* Keep all the business logic in `Inventory`.
* Extract all the output to the user to a different class that uses an `Inventory` instance.
* Extract the code to parse the file and produce the initial mapping of products to quantities. Then pass that mapping in as an argument to the `Inventory` constructor.