Re: Not true for Java about Function Hijacking.
I recall specific cases, though, in which hijacking can happen in java. I
coded them up to make sure I remembed it correctly. Imagine a base
class A and subclass B.
=-=-= file A.java =-=-=
public class A {
// pretty boring
}
=-=-= file B.java =-=-=
public class B extends A {
private void foo(long x) {
System.out.println("B.foo(long)");
}
private void put(Object o) {
System.out.println("B.put(Object)");
}
public void doStuff() {
foo(0xcafebabe);
put(this);
}
public static void main(String[] args) {
B b = new B();
b.doStuff();
}
}
As is, doStuff() prints:
B.foo(long)
B.put(Object)
But in a new version of the base class A, some new methods are added
that are intended to be overriden.
public class A {
// These methods are added later and hijack B's methods because they
// match better
public void foo(int x) {System.out.println("A.foo(int)");}
public void put(A a) {System.out.println("A.foo(A)");}
}
Because they are a better match for the arg types in doStuff(), they are
called instead. But that's not what the designer of class B intended :-(
It compiles with javac without warning. Now the output from doStuff()
is:
A.foo(int)
A.foo(A)
// Opposite case. A subclass hijacks functions of a base class
class X {
// launch is a new function that a designer intended to be
// overridable. But the designer has no way of knowing that launch()
// is already implemented in a subclass somewhere (some other
// company perhaps), and it does something completely different.
public void launch(int x) {
// Launch application ID x
System.out.println("X.launch app id " + x);
}
public void cleanup() {
launch(42);
}
}
// When class Y was designed, X didn't have a launch method
class Y extends X {
// If @Override keyword was required for overrides, then this
// would be flagged. Or at least provide a switch to warn about this.
public void launch(int sec) {
// Launch the missle in 'sec' seconds
System.out.println("Y.launch missle in " + sec + " sec");
}
public static final void main(final String[] args) {
Y y = new Y();
y.cleanup();
}
}
Mathew, it sounds like netbeans flags this case, but I think it will go
unnoticed if your builds are done with something like ant and javac.
--
Dan Olson
Re: Not true for Java about Function Hijacking.
On 5/23/2011 5:37 PM, Jonathan M Davis wrote: Report errors on the website and online documentation in bugzilla: http://d.puremagic.com/issues/ . Choose "D" (out of D, DStress, and puremagic.com) to get to the correct bug report form, and select "websites" as the component of the bug report. Bugs and enhancement requests that aren't entered into bugzilla tend to get lost. - Jonathan M Davis Thanks Jonathan. -- Matthew Ong email: on...@yahoo.com
Re: Not true for Java about Function Hijacking.
On 2011-05-23 02:22, Matthew Ong wrote:
> Hi Digitalmars/Walter Bright,
>
>
> http://www.digitalmars.com/d/2.0/hijack.html
>
> This talk covers function hijacking, where adding innocent and
> reasonable declarations in a module can wreak arbitrary havoc on an
> application program in C++(maybe true) and Java(not true).
>
> Since I have not done C++ for a long while, I am not going to comment
> about that. But Java I have to place this request for correction from
> DigitalMars.
>
> javac(from sun) Compiler will complain if there is an ambiguous to link
> any indentifier that has the same signature for contructor,
> methods(static/overloaded/overriden)
>
> Overload Sets
> Java denys global functions. All functions/methods are within a single
> class. Within the same class, the overloaded methods cannot have the
> same signature.
>
> public class MyClass{
>
> public int myVal(){
> }
>
> public String myVal(){ // compiler will complain here as error and NOT
> warning.
> }
> }
>
> Both the method identifier and zero param list makes a identical signature.
>
> Derived Class Member Function Hijacking
> IDE like Netbeans and does flag:
>
> @override
> public void myMethodA(){ // Say you did not use the override tag
> }
>
>
>
> Base Class Member Function Hijacking
> to prevent the child class from stealing your implementation for this
> single method, do:
>
> public final void myMethodA(){ // final == sealed in C#
> }
>
>
> That is shown clearly when you tries to import both this 2 classes
> within Java:
> import java.util.Date;
> import java.sql.Date;
>
> public class MyTest{
> public static void main(String[] args){
> Date now=new Date(); // thinking that you are using
> java.util.Date;
> }
> }
>
>
> Again, as a senior Java Developer since java jdk 1.1 I agrees D as a
> good replacement for C++ because of modern design and approaches.
>
> Kindly correct that to avoid confusing the new Java to D developer.
>
> There are also other run time intelligent build into JVM to avoid
> malicious hacker attack on such thing using class proxy & stub.
Report errors on the website and online documentation in bugzilla:
http://d.puremagic.com/issues/ . Choose "D" (out of D, DStress, and
puremagic.com) to get to the correct bug report form, and select "websites" as
the component of the bug report. Bugs and enhancement requests that aren't
entered into bugzilla tend to get lost.
- Jonathan M Davis
Not true for Java about Function Hijacking.
Hi Digitalmars/Walter Bright,
http://www.digitalmars.com/d/2.0/hijack.html
This talk covers function hijacking, where adding innocent and
reasonable declarations in a module can wreak arbitrary havoc on an
application program in C++(maybe true) and Java(not true).
Since I have not done C++ for a long while, I am not going to comment
about that. But Java I have to place this request for correction from
DigitalMars.
javac(from sun) Compiler will complain if there is an ambiguous to link
any indentifier that has the same signature for contructor,
methods(static/overloaded/overriden)
Overload Sets
Java denys global functions. All functions/methods are within a single
class. Within the same class, the overloaded methods cannot have the
same signature.
public class MyClass{
public int myVal(){
}
public String myVal(){ // compiler will complain here as error and NOT
warning.
}
}
Both the method identifier and zero param list makes a identical signature.
Derived Class Member Function Hijacking
IDE like Netbeans and does flag:
@override
public void myMethodA(){ // Say you did not use the override tag
}
Base Class Member Function Hijacking
to prevent the child class from stealing your implementation for this
single method, do:
public final void myMethodA(){ // final == sealed in C#
}
That is shown clearly when you tries to import both this 2 classes
within Java:
import java.util.Date;
import java.sql.Date;
public class MyTest{
public static void main(String[] args){
Date now=new Date(); // thinking that you are using
java.util.Date;
}
}
Again, as a senior Java Developer since java jdk 1.1 I agrees D as a
good replacement for C++ because of modern design and approaches.
Kindly correct that to avoid confusing the new Java to D developer.
There are also other run time intelligent build into JVM to avoid
malicious hacker attack on such thing using class proxy & stub.
--
Matthew Ong
email: on...@yahoo.com
