Praveen Balaji

Ranch Hand
+ Follow
since Jun 17, 2001
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Praveen Balaji

Vladimir Ozerov wrote:This is almost exactly what Embeddables are used for.

Not sure Embeddables are a solution, or like I said, I haven't figured it out yet. To quote from

In an application object model some objects are considered independent, and others are considered dependent parts of other objects. In UML a relationship to a dependent object is consider an aggregate or composite association. In a relational database this kind of relationship could be modeled in two ways, the dependent object could have its own table, or its data could be embedded in the independent objects table.

In JPA a relationship where the target object's data is embedded in the source object's table is considered an embedded relationship, and the target object is considered an Embeddable object. Embeddable objects have different requirements and restrictions than Entity objects and are defined by the @Embeddable annotation or <embeddable> element.

The way I understand this is, an Embeddable should have corresponding columns in a Database. In my case, the StudentDetails is merely a containing structure which holds data that would otherwise have been in the Student class.
Here's a simplified example of what I want to achieve:

I have 3 tables:

1. STUDENT_REF colums have a foreign key referring to STUDENT_ID column.
2. There is a One-To-Many relationship between STUDENT and HOBBY/AWARD.

The standard way to model this in Java classes is:

However, I want to introduce another containing class - StudentDetails - which does not have a mapping to any table and model it thus:

Note that Hobby and Award classes have a reference back to Student and not to StudentDetails.

How can I achieve this? Should I be using embedded objects? I haven't (yet) figured out how. Any hints will be appreciated and devoured.

Thanks in advance
Thanks a lot guys for the input and links.
14 years ago

Originally posted by Rahul Bhattacharjee:
To my best of knowledge it has got nothing to do with performance.

Just curious to know that what made you think that it has something to do with performance.

I USUALLY prefer early aborts - specially when I'm validating function input. But someone mentioned it has performance implications. Googling didn't help much, but there may be a better search string I should be using.
14 years ago

Originally posted by praveen balaji:

As I mentioned above, the question is about performance.

Just for the record, there are several stylistic reasons for and against the use of "guard code" (Case 1). However, I'm interested in the performance implications.

Someone mentioned it has something to do with how Java allocates the function stack. I was looking for details.
14 years ago

Originally posted by Rahul Bhattacharjee:
Would you like modify a function with 10 exits/returns ,
knowing the fact that there are no JUnits for unit testing that piece ?

As I mentioned above, the question is about performance.

Just for the record, there are several stylistic reasons for and against the use of "guard code" (Case 1). However, I'm interested in the performance implications.
[ May 29, 2007: Message edited by: praveen balaji ]
14 years ago

Originally posted by Amit A. Patil:
Case 2 is always good from maintenance and support point.
When some other developer is looking at your code there makes it easier for hiom if there is a single return in the method

I should have been clearer there. I wanted to know from a performance POV. I modified the question.
14 years ago

Originally posted by Rahul Bhattacharjee:
I will go with Case II.I always prefer single return point for methods.

Someone mentioned that. Any reason why?
14 years ago
From a performance POV, is it better to return at just one place from a function rather than several places? Someone mentioned something to do with JVM allocations on the function stack.


Case 1:

Case 2:

Is Case 2 better than Case 1?
[ May 29, 2007: Message edited by: praveen balaji ]
14 years ago
The ouput is like that because the JVM has been written to do that But I'm sure that's not what you intend to ask.

Can you explain what you understood and what the confusion is? The code just displays basic java thread behaviour. So, if you can explain which part of the output is confusing you, I will be able to help you with an explanation.

PS: If you are new to threads, you may want to read an online tutorial. Apart from a lesson on Threads, this will give you a good understanding of Thread.sleep() which, I guess, is creating confusion in this case. Try Sun Trail on Threading and Concurrency.
Difficult to explain this on a forum, but I'll try.

The BEST way to figure how the execution happens is by naming the threads and debugging through the code. You'll see multiple threads being created and figure out which steps can be executing parallely.

Remember that with paralelly executing threads, it's often difficult to predict the order of execution. There are some synchronization constructs, however, that can assure a "happens-before" relationship between instructions. You should look up the JSR-133.

Having said that, here is an attempt to answer your question. I have broken up the code in the main method.

I'm sure it's confusing. But that's the way with threads. As one of the senior programmers at my previous company said: "Threads are like snakes. Dont use them if you dont have to".

PS: If it interests you: the more I think about it, the more I seem to believe that the world is single-threaded and procedural. It's like a see-saw. One end goes up and the other goes down. If you look at it separately, they are two events happening parallely.
The world is probably single threaded: think about parallel universes - the see-saw of the universe.

[ November 27, 2006: Message edited by: praveen balaji ]
[ November 27, 2006: Message edited by: praveen balaji ]
You can geta list of all running threads: List Of All Running Threads

I am not sure how you can figure the threads created by a particular code block. I was thinking about stack trace but stack trace is per thread and not across threads. So, it's not possible to know where it was spawned.

If your threads are named (or you could induce code to name them at the point they are created), you could probably iterate through the list of threads to check. But I am not sure you want to/can do that.

If you explain why you need to do this, we may be able to offer an alternative.
Not sure I got the question. Can you explain what you mean when you say you want to get the number of threads ... "by reading the java file"?

Do you intend to say you have a java class that spawns several threads and you want to see how many threads have been spawned by that particular class?
Short answer: It's possible. It's called Thread Starvation.

You may want to google for

1. Thread Starvation
2. Thread Busy Wait

I believe you are exploring threads (considering you posted 3 questions). Might be a good idea to invest in a book. I dont know which one, but someone should be able to point you to a good book.

I always find Sun Trails a nice place to start reading about any java features/libraries. You get a broad idea of what is offered and what you should look (google) for.
[ November 24, 2006: Message edited by: praveen balaji ]
Distinguish between code blocks and threads of execution. Multiple threads of execution could be executing the same code blocks.

CurrentThread referes to the thread that is executing that code block and not to all threads that are running in the JVM at that time.

Thread-1 and Thread-2 are simultaneously executing the below code path:


They both end up executing the System.out.println(). For Thread-1's execution path, CurrentThread is Thread-1. Similarly for Thread-2.

I hope I understood your question right.