• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Something I can't understand in hadoop source code?

 
sara ahmed
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ,,
when I am studying the hadoop source code I found these 2 commands :


the code from class : org.apache.hadoop.mapred.JobClient
the code link source : http://grepcode.com/file/repo1.maven.org/maven2/com.ning/metrics.collector/1.2.1/org/apache/hadoop/mapred/JobClient.java#JobClient.submitJobInternal%28org.apache.hadoop.mapred.JobConf%29
hadoop source code version : 1.2.1




At the first command he made a new object "context" and initialize it with jobCoby with is representing the configuration object
then at the second command he called getConfiguration() function which return the configuration object and but it in jobCoby
shouldn't it be the same, so why he wrote the second command ??
 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes it should be the same.

This code look awkward but keep in mind that JobContext might further initialize jobCopy with more values.

Nevertheless, the reference to jobCopy should still be valid with updated values if jobContext set more values on it. So that line:

jobCopy = (JobConf)context.getConfiguration();

might just return a reference to self.

Try to comment out the line to find out.

Kind in mind that when you pass an object reference to a method, the method can freely modify your object even if the method is called getXXX. Of course, this is bad practice!

To get readonly behavior in critical use cases, we typically clone the object (sometimes using deepcopy) before passing it to any method.
 
sara ahmed
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A.J. Côté wrote:Yes it should be the same.

This code look awkward but keep in mind that JobContext might further initialize jobCopy with more values.

Nevertheless, the reference to jobCopy should still be valid with updated values if jobContext set more values on it. So that line:

jobCopy = (JobConf)context.getConfiguration();

might just return a reference to self.

Try to comment out the line to find out.

Kind in mind that when you pass an object reference to a method, the method can freely modify your object even if the method is called getXXX. Of course, this is bad practice!

To get readonly behavior in critical use cases, we typically clone the object (sometimes using deepcopy) before passing it to any method.


thanks so much for your reply and I will try to command the line to see what will happen
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic