Norbert Muench

Greenhorn
+ Follow
since Mar 09, 2012
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
3
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Norbert Muench

Nothing. The code won't compile.
Because count is an instance variable. Therefore both enum objects (Weather.RAINY and Weather.SUNNY) carry their own copy, each with the value 1 (initialized with 0 and incremented by 1 in the constructor).

Been Zaidi wrote:From the console here is the input given


In my opinion, the instruction is asking to find one or zero match of aa. But here is the output generated


No, the ? only binds to the second a, so the pattern that regex is looking for is one 'a' followed by zero or one 'a'
To look for one or zero matches of aa, the regex would be "(aa)?".

Been Zaidi wrote:Another additional thing, inside the book it is written that the engine backtracks as well. Why is that so?


Imagine you have the regex ".*c" and are looking for a match in "abc". Since the * is greedy, the initial match for the beginning of the regex (".*") would be as long as possible, therefore matching the whole string. But then the end of the regex wouldn't fit anymore, so the pattern matching has to backtrack, making .* only match ab instead of abc.

saloni jhanwar wrote:
Hi Norbert
You didn't get my point, yes above code will work fine ,because you are compiling file using source file name while interpreting using class name that is different scenario but i asked that if i interpret also using same source file name ? then it wont work.


Of course it won't work. The name you pass in as a parameter to the java vm is the name of the class with the main method in it, not the source file. If I would have tried to run "java foo" in my example above, the java vm would have looked for a class named foo (which in turn means the classloader would have looked for a file named foo.class anlong the class path). As such a class does not exist, you get an error.

saloni jhanwar wrote:Hi Anayonkar Shivalkar
You were giving me wrong knowledge that is not good .Every greenhorn posts doubts here to get clarification not to get more confused.This all will lead to frustrating about this forum.


Now come on, this hardly seems fair. Anayonkar just tried to help you and made an honest mistake. That can happen to everyone. I think you should apologise to him.
The lesson to take away here is that you should always verify the answers you get, instead of blindly accepting them. In this concrete example you could have noticed, that Anayonkars answer actually contradicts your findings in your first post in this thread.
All you need to need to know about thread ids to answer this mock question is stated in the Javadoc for the getId() method in class java.lang.Thread:

Returns the identifier of this Thread. The thread ID is a positive long number generated when this thread was created. The thread ID is unique and remains unchanged during its lifetime. When a thread is terminated, this thread ID may be reused.


You should start by asking yourself which of the given lines will even compile. (This will eliminate one line)
Then ask yourself which of the remaining lines actually output two numbers. (This will eliminate another line)
Then you should ask yourself what it means when the output is "4 4". How many threads did the program start in this case?

Ted North wrote:Why would the constructor load twice though if construction of an object only depends on the Weather class and not the enum blueprint?


The constructor will be called once per enum constant. You have two constants in your enum, so your enum constructor will be called twice.
Under the hood, the compiler will build a class out of your enum type which will roughly resemble the code below (the class that the compiler builds will actually extend java.lang.Enum):

Edit: Fixed typo in the code

Anayonkar Shivalkar wrote:What do you mean by 'program doesn't run'? Have you written your main method in non-public class? If yes, then it won't work.


Not true. The following will compile and run fine, although the main method is not in a public class:

saloni jhanwar wrote:When I tried different name other than non public classes, then my program doesn't run with that, then what is use to put different name and why should i use.Thanks


What do you mean by that? If I take your example code above and save it in a file called foo.java, the code will compile and run without problems.
Yes, objects are created on the heap. The stack overflow is causes by the nested calls to A's constructor, which will eventually overflow the stack long before the A objects you create exhaust the heap.
Line 2 of your code will essentially cause the constructor of class A to call itself.
A short look into the Javadoc for the PriorityQueue answers your question:

The Iterator provided in method iterator() is not guaranteed to traverse the elements of the priority queue in any particular order. If you need ordered traversal, consider using Arrays.sort(pq.toArray()).

ayush raj wrote:What is this link then all about ?

ORACLE'S OCPJP-6


??? That seems to lead to the same page that I linked to in my post above. And it doesn't say anything about requiring the OCA cert as a prerequisite.
According to Oracle's certifcation website the OCPJP-6 does not require the OCA certification, only OCPJP-7 does.

Matheus Souza wrote:This is not what meant. I want to know if I lock an method syncronized, the whole set of static members would be locked too?


I think you misunderstand how locking works. If one thread holds a lock to an object, it doesn't prevent other threads from modifying any of the objects member variables. It just prevents other threads from aquiring a lock to the same object. And threads will only aquire a lock when starting a synchronized block or synchronized method.

Take the following code as an example:


Now imagine you have two threads, thread 1 and thread 2. Thread 1 has just called MyClass.staticSyn1() and is in the middle of working through that method. So it holds a lock to the MyClass class object.
If thread 2 would start running now, it could modify the static member MyClass.si1. The fact that thread 1 holds the lock on the MyClass class object doesn't come into play here at all. Thread 2 could also call MyClass.static1(), because that class method isn't synchronized.
But what happens, if thread 2 tries to call MyClass.staticSyn1(), MyClass.staticSyn2() or syn1() on any object of type MyClass?
At the start of the synchronized block, the thread would try to aquire a lock on MyClass.class. That lock is already held by thread 1 however. So in this case thread 2 would be moved from the running state to the blocked state. Once thread 1 releases the lock on MyClass.class, thread 2 would aquire the locks and would be moved from blocked to runnable (and eventually to running).

Matheus Souza wrote:I have another question: when I use the syncronized keyword in a static member it means that all my template (static member - variables and methods) are lockeds?


No, it means that threads executing the synchronized method need to aquire a lock on the class object.
is functionally equivalent to


Helen Ma wrote:By the way, will the following scenario be possible ?


I would say yes. And the solution is described in K&B chapter 9, section "Using wait() in a Loop". Basically, before calling wait() you should check if the event you want to wait for has already happened.

Janki Shah wrote:Thank you Norbert for your explanation. So, in order to work with wait(), notify(), and notifyAll()... All these three methods have to acquire a lock on an object not on threads, Right? And wait() and notify() or notifyAll() they both have to get lock on the same object to work with each other? Please correct me if I am wrong.


That is correct.

Janki Shah wrote:But this conflicts with this " the thread must own the lock on the object that wait() is being invoked on " From K & B book chapter 9 question 7.
I am very confused in this logic who should own the lock on whom??? Can you please explain this?


Locks are on objects, but they are aquired and owned by threads. When a thread enters a synchronized block, it aquires the lock on the object the synchronized block refers to. In case of a synchronized method, this will be the object the method is called for.
Once one thread has aquired a lock on an object, no other thread can aquire a lock on the same object until the thread holding the lock releases it.
Same as you would call any other method.
The thread code still might get stuck in the call to wait() though, as there is no guarantee that the notifyAll() wouldn't be excuted before the wait().