TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Date: Sun, 11 Apr 0100 23:59:47 GMT
Parts/Attachments: text/plain (59 lines)
>I admit I do not know Java, but from your description below I have one
>question.

Fair enough

>Ada allows pointer arithmetic.  It is difficult (unchecked conversion is
>needed) but possible.  Does Java have any means of "breaking" its
>references (turning them into integers and back again)?  If not, then their

>statements are true.

Any language where you can call functions from another language can be misused
to break the system. As long as such breakage requires either jumping out of
the system, or willful misuse, I see no problem.

Quote from
http://web2.java.sun.com/docs/books/tutorial/overview/language.html
Some clients, such as the serialization service, development tools, and debuggers,
need to bypass the default access controls built into the Java programming language
when they use reflected members or constructors. These controls govern how method
and constructor reflectives can access fields, invoke members, and create new
class instances according to whether the field, method, or class is public,
private, or protected.

So, you can bypass a lot of things: but like removing a safety, it's obvious
in the code and not trivial to do.

Just as if in Ada your first line of every program is pragma SUPPRESS_ALL_CHECKS,
if every 2nd line makes use of UNCHECKED_CONVERSION, and of course Ye Dreadedde
goto, you can make rubbish. But it's obvious rubbish. Similarly in Java (but
some of the rubbish is less obvious - like the example below).

Of course, as all Java Objects are passed by reference not by value, it's impossible
to gaurentee that a piece of 3rd party code you inform of an object's existence
won't change that object in some way. There's no "const", and no "in" restriction
on parameters.

Another problem is Java's lack of information hiding (though you *can* get the
same problem in Ada, it's more difficult)

viz in the code fragment,

   a = 1;
   b = a;
   a = a+1;

what does b equal?

In Java:
if b is the primitive "int", then b=a-1
if b is the class "Integer" then b = a means in Ada terms b renames a. For which
we can thank C.
If b is a primitive, you can't do text output of it. Which is why Java is either
littered with "new Integer(a)" statements to make an object of class Integer
constructed using a, just for printing it out, or the use of class Integer in
the gubbins of the code which leads to many inadvertant errors.

But this is getting OT.

ATOM RSS1 RSS2