aspose file tools*
The moose likes Java in General and the fly likes If i want to report a bug Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "If i want to report a bug" Watch "If i want to report a bug" New topic
Author

If i want to report a bug

Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
Hi Ranchers,

If i found a bug in the java compiler , where to report?


SCJP5-(100%)
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3446
    
  12
Sun's bug site


Joanne
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Sun has a bug database for these.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3446
    
  12
Originally posted by Joanne Neal:
Sun's bug site


Although it might be worth showing us the bug here. It may be something you are doing wrong or other people may have seen a similar thing and can point you to an existing bug or tell you about a workaround.
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
If i have 2 seprate classes in two different packages

package in;
public class Animal {
public Animal() {
}
//accessible only throw inhertance or throw the dot operator if the accessing class is in the same package
protected void eat()
{
System.out.println("animal");
}
}
--------------------------------------------------
package out;
public class Horse extends in.Animal {
public Horse() {
}
/*
* Override the protected method eat
*/
protected void eat()
{
System.out.println("horse");
}
}
-------------------------------------
package in;
import out.Horse;

public class BarnHorse
{
public BarnHorse()
{
Animal a=new Horse();
//calling polymorphiclly the eat method in the horse class
a.eat();
}
}

the code compiles fine and calles the Horse version of eat and outputs "horse" although the calling class shouldn't know anything about the Horse eat version.
[ May 28, 2008: Message edited by: Amgad Muhammad ]
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
any update?
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3446
    
  12
The method that is called is decided by the type of the object, not the type of the reference to the object. What if there was no reference variable at allWhich method would you expect to be called here.
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
Originally posted by Joanne Neal:
The method that is called is decided by the type of the object, not the type of the reference to the object. What if there was no reference variable at allWhich method would you expect to be called here.


this should results in compilation error

back to the code
Animal a=new Horse();
a.eat();

the compiler should check for it as it checks to see if the overriden method is more restrictive.It should treats this case as if it was private

the Horse version doesn't exist for the barnhorse class.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38334
    
  23
That's not a bug; that's normal polymorphism.
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
Originally posted by Campbell Ritchie:
That's not a bug; that's normal polymorphism.


The Horse eat version is not accessible to the barnHorse class due to the protected access modifier behavior.

what if the Horse eat version does a really important protected code which i don't any other class outside the package or a not subclass to know about

by writing this code i cracked this relationship and the code inside this function became exposed to any other class which makes the protected modifier meaningless.
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3446
    
  12
Originally posted by Amgad Muhammad:

this should results in compilation error


You're right. I missed the protected qualifier on the method.
Guido Sautter
Ranch Hand

Joined: Dec 22, 2004
Posts: 142
Originally posted by Joanne Neal:


You're right. I missed the protected qualifier on the method.


Since BarnHorse is in the same package as Animal, it can invoke Animal.eat() even though it's protected. The fact that Horse overwrites Animal.eat() with an own implementation does not change the fact that the eat() method is declared in Animal, and thus accessible to all class that (a) extend Animal, or (b) are in the same package as Animal.
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
Originally posted by Guido Sautter:


Since BarnHorse is in the same package as Animal, it can invoke Animal.eat() even though it's protected. The fact that Horse overwrites Animal.eat() with an own implementation does not change the fact that the eat() method is declared in Animal, and thus accessible to all class that (a) extend Animal, or (b) are in the same package as Animal.


okay but because Horse does overrides the Animal eat() ,that requires the compiler to check to see if the overriden version also accessible to the calling class (BarnHorse), which in this case the overriden version is not accessible. so it should result in compiler error

the same case happens when you override a public method to be a private method , the compiler disagree with you because you made the overriden version not accessible to the calling class.
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3446
    
  12
Originally posted by Guido Sautter:


Since BarnHorse is in the same package as Animal, it can invoke Animal.eat() even though it's protected. The fact that Horse overwrites Animal.eat() with an own implementation does not change the fact that the eat() method is declared in Animal, and thus accessible to all class that (a) extend Animal, or (b) are in the same package as Animal.


My response was in reply to my earlier post where I had suggested tryingThis will not compile because Horse is in a different package to BarnHorse
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

As far as the compiler cares your variable a is of the type Animal. What the compiler looks at is:

For the methods available to it, it only looks at what is to the left of the assignment operator. And Animal has an eat method that is accessible to the calling code (because it is in the same package). If you has written this:

You would get a compiler warning. Remember polymorphism is runtime behaviour, not compile time, so the compiler does not care that at runtime the Animal is actually a Horse, it just calls the eat method available to it (in Animal). That it has been overridden in Horse is outside its scope.
[ May 28, 2008: Message edited by: Paul Sturrock ]
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

There's no compiler bug.

The compiler will always make sure that a variable is initialized before use.

Otherwise, it never looks at the contents of a variable. In compiling the line

a.eat();

a Java compiler is not allowed to consider, and never will consider, the contents of the variable "a"; this line is compiled in isolation. Period.


[Jess in Action][AskingGoodQuestions]
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
so why when you override a method with more restrictive access modifier the compiler does complains about it? if polymophism was only a runtime behavior the compiler shouldn't complain about it..it should let it go and the JVM crashes and everything goes down..

but because the compiler has to make sure that all the rules are applied correctly it complains if you do so.
[ May 28, 2008: Message edited by: Amgad Muhammad ]
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Originally posted by Amgad Muhammad:
so why when you override a method with more restrictive access modifier the compiler does complains about it?


I'm not sure what you mean here. You're allowed to override a method and make access less restrictive (where "restrictive" just refers to the strict private/default/protected/public ordering); if you try to make it more restrictive, that is an error and won't compile.
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
Originally posted by Ernest Friedman-Hill:


I'm not sure what you mean here. You're allowed to override a method and make access less restrictive (where "restrictive" just refers to the strict private/default/protected/public ordering); if you try to make it more restrictive, that is an error and won't compile.




if you do so the compiler complains because you made the eat method in the child class private.

what is wrong with making the child's eat() private is when you do something like this



the actual invoked method is the child version which is no more accessible to the calling class

how does the compiler know something like that because it does that extra check to make sure that in case of a polymorphism the calling class could actually (in you system design) make the polymprphic method invocation in otherwords your system design allows this calling class to access that version of that method(the child eat version).
this is exactly like the situation am discussing in the code above
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

I understand what you're saying, but that's just not how it works. If a class A has a protected method, and if a class B has access to that protected method, then by definition class B can call that protected method on any reference variable a of type A, regardless of the runtime class of the object that a points to. This is part of the definition of the Java language; it's not a compiler bug.

I agree that what your program demonstrates can be surprising, and is even a little strange. But in this case the strangeness is a well-defined part of the language specification. There's a basic conflict between the idea of a hierarchy of access control levels and the idea of packages.

There are other ways of apparently circumventing the access control or type systems in Java. One example is something like

Object[] o = new String[3];
o[0] = new Integer();

which compiles fine but throws an ArrayStoreException at runtime. This one is a result of the (bad, in hindsight) rules about inheritance relationships between array types. Note that when they designed generics, they didn't make this same mistake!
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
Originally posted by Ernest Friedman-Hill:
There are other ways of apparently circumventing the access control or type systems in Java. One example is something like

Object[] o = new String[3];
o[0] = new Integer();

which compiles fine but throws an ArrayStoreException at runtime. This one is a result of the (bad, in hindsight) rules about inheritance relationships between array types. Note that when they designed generics, they didn't make this same mistake!


but the RuntimeException says it loud "you can't do this".

but in my case, there is nothing telling me that you can't do this ..everything works perfectly as if am allowed to do so.

there must be something to prevent such behavior don't you think?
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Originally posted by Amgad Muhammad:

there must be something to prevent such behavior don't you think?


No -- because it's not wrong. The language says it's OK.
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
with all do respect to the language but it's not right
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30293
    
150

Originally posted by Amgad Muhammad:
with all do respect to the language but it's not right

It may not be logical, but it isn't a bug


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38334
    
  23
Originally posted by Jeanne Boyarsky:

It may not be logical, but it isn't a bug
It is logical; if your Horse has an eat() method then BarnHorse has an eat() method too.

If the BarnHorse eat() method ceases to be accessible, then a BarnHorse IS-NOT-A Horse, in which case it doesn't "extend" Horse. That is [part of] the basis of inheritance in OO programming, so any code which has access to Horse#eat() must also have access to BarnHorse#eat().
Guido Sautter and Ernest Friedman-Hill have already said, your subclass methods cannot have more restrictive access than the superclass methods.
[ May 29, 2008: Message edited by: Campbell Ritchie ]
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
why it's not a bug .

what is the defintion of the protected access modifier?what it should allow and what it shouldn't?

what is the definition of a bug?

answer both question and then decide

it doesn't matter if the language says that it's okay...i still have my brain
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3446
    
  12
@Campbell - I think you meant to refer to the Animal and Horse classes in your last post. The BarnHorse class doesn't extend Horse and so never had an eat method.

@Amgad - if a program works in a way that is incompatible with the specification it was written against then there are bugs in that program. If the specification says that a class that represents a fish should have a rideBike method then that's illogical but not a bug.
If the Java Language Specification says that this is how the compiler should work then there is no bug in the compiler. It may or may not be logical but it's not a bug.
[ May 29, 2008: Message edited by: Joanne Neal ]
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
Originally posted by Joanne Neal:

@Amgad - if a program works in a way that is incompatible with the specification it was written against then there are bugs in that program. If the specification says that a class that represents a fish should have a rideBike method then that's illogical but not a bug.
If the Java Language Specification says that this is how the compiler should work then there is no bug in the compiler. It may or may not be logical but it's not a bug.

[ May 29, 2008: Message edited by: Joanne Neal ]


the language spec says that the protected member could only be accessed throw inheritance or a class in the same package, then you write some code that does access the protected member from outside the package and not throw inheritance, then you did something that wasn't suppose to happen.

what you call this?
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Originally posted by Amgad Muhammad:


the language spec says that the protected member could only be accessed throw inheritance or a class in the same package, then you write some code that does access the protected member from outside the package and not throw inheritance, then you did something that wasn't suppose to happen.

what you call this?


Ingoring access modifiers is not difficult to do nor is it a bug. Reflection for example lets you bypass these access constraints. However, Reflection shares a property with your example in that it is runtime not compile time behaviour. The language specification only refers to access modifiers with regards to "compilation units", not runtime behaviour.
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
Originally posted by Paul Sturrock:


Ingoring access modifiers is not difficult to do nor is it a bug. Reflection for example lets you bypass these access constraints. However, Reflection shares a property with your example in that it is runtime not compile time behaviour. The language specification only refers to access modifiers with regards to "compilation units", not runtime behaviour.



if i can ignore access modifiers then why they are created in the first place , am not talking about reflection am talking about that specific situation where i can not ignore the access modifiers
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

You can't ignore them at compilation time, that is why they exist. Your example doesn't ignore them, it works round them via runtime behaviour.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Amgad Muhammad:

the language spec says that the protected member could only be accessed throw inheritance or a class in the same package


In fact, it doesn't:

from http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6.2

6.6.2.1 Access to a protected Member

...

* If the access is [...] by a method invocation expression E.Id(. . .), where E is a Primary expression, then the access is permitted if and only if the type of E is S or a subclass of S.


Which in fact would mean that

new Horse().eat();

shouldn't produce a compile time error either, should it?

And the whole reason for this behavior is that otherwise subclasses wouldn't be subtypes, according to Liskov's Substitution Principle.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
Originally posted by Ilja Preuss:


Which in fact would mean that

new Horse().eat();

shouldn't produce a compile time error either, should it?


it will produce compiler error, try it.


Let Horse be the class in which a protected member eat is declared. Access is permitted only within the body of a subclass S of Horse. In addition, if Id denotes an instance field or instance method, then:

If the access is by a field access expression E.Id, where E is a Primary expression, or by a method invocation expression E.Id(. . .), where E is a Primary expression, then the access is permitted if and only if the type of E is S or a subclass of S.


which is not the situation here BranHorse not Horse not a subtype of Horse

correct me if am wrong
Prakash Subramanian
Ranch Hand

Joined: Feb 03, 2005
Posts: 32
You misunderstood Ilja in the previous post. It was not said that it will 'not' produce a compiler error. The point was being explained with regards to the reference given.

Going through the posts, if you mention that what is happening with respect to the protected member access is wrong and should be disallowed by the compiler, then there wont be any difference between 'protected' and 'default' access.

Also in the JLS it states that 'A protected member or constructor of an object may be accessed from outside the package in which it is declared only by code that is responsible for the implementation of that object'. I am not sure if I am right, but that statement seems to explain the point, even from a runtime perspective. Correct me if I am wrong, since I am not very sure about this.

Also when you had mentioned about the security aspect of protected code being accessed by a seeming violation, I think that security does not fit within this scope. In fact if you want to completely protect your method, then it should be made private or default.
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
it doesn't have to do anything with the difference between the default and protected

all am saying is

if calling Horse.eat() in the BarnHorse will give compiler error this means that BranHorse must not know anything about the Horse eat().that is the way it must work. always.
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3446
    
  12
I can see what you're saying, but, as I don't have time to read the JLS at the moment, I can't say whether you are right or wrong. If you are convinced you are right, then open a bug with Sun and get an answer straight from the horse's mouth ( ).
If you do do this, let us know the bug number so that we can follow the progress.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38334
    
  23
Yes, Joanne, you are right, I was getting Horse, Animal and BarnHorse confused. It ought to have been Horse IS-NOT-AN Animal and similar.
Guido Sautter
Ranch Hand

Joined: Dec 22, 2004
Posts: 142
At the danger of repeating myself ...

RarnHorse can access Animal.eat() because it's in the same package. Thus, BarnHorse can access the eat() method in any Animal object, regardless if this at runtime means invoking the actual implementation from the Animal class or an overriding implementation from a sub class of Animal, as in the example. Because of this, it does not matter if a sub class that extends Animal and lies in a different package is overriding the eat() method or not.

Consider the following:
suppose you have a sub class of Animal that does not override the eat() method, and you pass it to some method in BarnHorse, then BarnHorse could access the eat() method of this very sub class because the actual implementation is in the same package. Now you decide to override the eat() method in your sub class, and all of a sudden, BarnHorse would not be able to access the eat() method in this class any more. This would make no sense at all!

For access modifiers and package visibility, the decicive point is where the method is declared (Animal), not in which package an overriding implementation may lie (Horse).
Amgad Muhammad
Ranch Hand

Joined: Mar 26, 2008
Posts: 46
Okay finally what you all agree on calling this situation?
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3446
    
  12
Originally posted by Amgad Muhammad:
Okay finally what you all agree on calling this situation?


Well, everyone apart from you appears to think it is working as designed.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: If i want to report a bug