• Post Reply Bookmark Topic Watch Topic
  • New Topic

Few questions on Core java  RSS feed

 
raja singh kumar
Ranch Hand
Posts: 189
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. In the string method indexOf(int ch) why the signature of the method accepts  an integer while the value passed is a character?
public int indexOf(int ch)

2. Is immutability acheived by making a class final?

3. Why type-casting is required when  using the compareTo method of Comparable interface? Look at line 4 in below code. Who is passing Object class(or child class object) as an argument to the compareTo() method? Is it again related to something which is an internal implementation which we should not bother about?


 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
raja singh kumar wrote:
2. Is immutability acheived by making a class final?


Well, that is one of the things that is done by the String class. The other obvious ones are (1) not providing any methods that can modify the string itself, and (2) not allowing the underlying character array to be accessed (either directly or via method), so that it can be modified.

Henry
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
raja singh kumar wrote:1. In the string method indexOf(int ch) why the signature of the method accepts  an integer while the value passed is a character?
public int indexOf(int ch)

I don't know why it's declared as an int instead of a char. I can only speculate that maybe it has to do with the fact that char is an integer type and that the authors wanted the method to be able to handle int values instead of forcing the use of char. The code below will not produce any errors although I don't know any reason for checking for a value greater than 65535, the equivalent int value of the maximum possible char value, '\uFFFF'.
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
raja singh kumar wrote:1. In the string method indexOf(int ch) why the signature of the method accepts  an integer while the value passed is a character?
public int indexOf(int ch)


The reason may be a bit complicated. Basically, ch is a code point. Java characters are only 16 bits long *but* unicode characters can be larger than 16 bits (and I believe the String class has to uses some sort of internal format to store characters larger than 16 bits, by using two characters). Anyway, the integer allows your to specify unicode characters larger than 16 bits.

Henry
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
raja singh kumar wrote:
3. Why type-casting is required when  using the compareTo method of Comparable interface? Look at line 4 in below code. Who is passing Object class(or child class object) as an argument to the compareTo() method? Is it again related to something which is an internal implementation which we should not bother about?




In your example, the casting is needed to allow the assignment to work. And the reason for the local variable, is to access the fields of the Country class.

As for "who is passing", well, it is any algorithm that need to compare two instances. It could be one of the sorting libraries provided by Java. Or it could be a sorting algorithm that you write on your own.  Or heck, it could be something that is not sorting related, that just needs to compare two Country instances.

Henry
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
raja singh kumar wrote:
2. Is immutability acheived by making a class final?

Not necessarily. A class/object is immutable if its state cannot be modified after it is initialized to something. Marking a class as final only makes it impossible to declare subclasses of it.  The fields in that class need to be protected from any change being made to them after object instantiation. Marking fields as final can help but again, that doesn't mean the class is immutable just because fields are marked as final.  In the case of fields that are references to objects/arrays, those objects can still be mutated if you give access to them from the outside by returning them as a result of a method call or assigning a visibility that's anything other than private.

For example:

Even though class Foo is declared as final, its instances are still mutable because the numbers field can be accessed directly by other classes in the same package. They can even assign a new array to that field. You might to fix that by doing this:

That still won't work because the getNumbers() method basically breaks encapsulation and gives any code that's in the same package as Foo direct access to the numbers field. Anything that external code does to the reference returned by getNumbers() will affect the field in this class. Say for example, if this code were in another class that was in the same package as Foo:

That is bad.

To make instances of Foo immutable, you'd have to do something like this:

Line 5 is what's called as "making a defensive copy" of the numbers field. You are defending against external code inadvertently and inappropriately modifying the object's internal state via a direct reference to one of that object's fields.

If you try what we did before:

Because Foo.getNumbers() now returns a defensive copy, anything that external code does to the int[] reference returned by getNumbers() cannot affect the Foo object's internal state. Changing nums[1] from 2 to 200 only happens in the nums array; it doesn't affect the numbers field in the foo object.

If you're dealing with fields that are objects from the Collections API, you make defensive copies with one of the Collections.unmodifiableXXX() utility methods. For your own custom classes, you have to carefully go through their design and make sure you're not breaking encapsulation and making defensive copies for every field value that you return from a non-private method. Of course, you should also make sure that none of your code in the class itself accidentally goes and changes the values of any of its fields after object instantiation.
 
Paweł Baczyński
Bartender
Posts: 2087
44
Firefox Browser IntelliJ IDE Java Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The class Country should be declared as:Then the compareTo method would be declared as:and you wouldn't need to cast.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I should also add that ensuring immutability can also involve making defensive copies of incoming objects.  Consider this definition of Foo:

The getNumbers() method keeps encapsulation intact by making a defensive copy of the field and returning that instead.  However, instances of Foo can still be mutated if the code that's calling the Foo(int[]) constructor keeps a reference to the int[] that was passed in to it. With that reference, the calling code can easily break the Foo object's encapsulation and reach into its numbers field to change any value it wants to change. The fix to that is to again make a defensive copy and assigning that copy to the numbers field.

I see many programmers do this kind of thing all the time and it can be the source of much surprise, grief, and long late nights of debugging. This is why I like to have a copy-constructor in classes that can be aggregated/contained by other classes.
 
Campbell Ritchie
Marshal
Posts: 56598
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have an array containing immutable reference types or primitives, what is wrong with myArray.clone()?

To expand on what Junilu says, this is what a copy constructor looks like:-The null pointer exception (=NPE) will be thrown whenever the constructor attempts to access the fields in object (if null), so there is no need to write throw new NPE();
 
Campbell Ritchie
Marshal
Posts: 56598
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:. . . I see many programmers do this kind of thing all the time . . .
You mean that many people allow mutable reference types into/out of their object without defensive copies? Defensive copies is something often not taught to undergraduates.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Junilu Lacar wrote:. . . I see many programmers do this kind of thing all the time . . .
You mean that many people allow mutable reference types into/out of their object without defensive copies? Defensive copies is something often not taught to undergraduates.

No, I mean professional developers. Most of the time there aren't any serious consequences to not creating defensive copies of incoming data. However, when there are, it can be pretty difficult to find the problem. In fact, that's what I suspect is behind some of intermittent bugs I get in the (legacy) application that I support. It's just not something you'd normally expect would cause the PoLA to come back and bite you but when it does, you're often left scratching your head and wondering how and what the heck just happened.
 
Campbell Ritchie
Marshal
Posts: 56598
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:. . . No, I mean professional developers. Most of the time there aren't any serious consequences to not creating defensive copies of incoming data. . . .
I was thinking about people writing code at all levels, so that would include professionals. If things are going to go wrong, a mutable reference type with multiple references is going to behave almost like a global variable. It is all a case of right first time. It might take a minute or so each time you take a defensive copy, but the hours and hours it takes to find these obscure bugs overwhelms any time saving there. Never mind the hazards of running buggy software.
 
raja singh kumar
Ranch Hand
Posts: 189
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Q) I have the code sample below. In this code who exactly is going to interrupt? Is interrupting a thread in my control? And which thread does the statement Thread.interrupted() refer to?

 
Paweł Baczyński
Bartender
Posts: 2087
44
Firefox Browser IntelliJ IDE Java Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In your code there is nothing that will interrupt your thread.

Thread.interrupted() refers to the current thread (the thread that calls the method).
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!