TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To:
Ben Brosgol <[log in to unmask]>
Date:
Mon, 1 Nov 1999 11:56:48 -0500
Reply-To:
Tucker Taft <[log in to unmask]>
Subject:
From:
Tucker Taft <[log in to unmask]>
Content-Transfer-Encoding:
7bit
Content-Type:
text/plain; charset=us-ascii
Organization:
AverStar (formerly Intermetrics) Burlington, MA USA
MIME-Version:
1.0
Parts/Attachments:
text/plain (45 lines)
Ben Brosgol wrote:
> ...
> BTW I am perfectly well aware of the large number of omissions from Java
> (such as range constraints on variables, strongly typed scalars, generics,
> operator overloading,...), and I also understand the argument that such
> omissions may make the application programmer's job more complicated and
> thereby lead to less safe programs.  So I can argue this issue either way.
> But I have seen some folks from the Ada community dismiss Java as just a
> bunch of hype, and this is a serious delusion.

Perhaps.  On the other hand, Java is loaded with ideas that sound
good in theory, but which end up being less than ideal in practice.
Perhaps it is just a question of maturity, or waiting until Java 4.0.
Examples include the supposedly portable GUI aspects of Java, which really
have not worked out very well (most sophisticated Java programs
still only work well on one or two JVM implementations), or the
Just-In-Time compiler technologies, which tend to be buggy and
not that much of a speed improvement, or the switch from file-oriented
textual include to module-oriented "import," sullied by the fact that each
text file may contain only a single public class, resulting in hundreds
of files when a smaller number of conceptual modules would be more
managable.

I sense that the effort to push Java into the real-time market is somewhat like
trying to force fit a round peg into a square hole.  You can succeed
if you push hard enough, but you may not be very happy with the result.
Java will almost inevitably, ultimately, play a role in real-time systems.
But I suspect it will have to be combined with a fair amount of
gorddy C glue to make it all work, and the garbage collector will be
turned off in many cases, with awkward coding conventions adopted
in its stead (e.g. only create objects at class initialization time).

On the other hand, maybe the RT Java groups will produce something
that resolves all of these issues.  It will be interesting to see whether
some of the language simplicity ends up resulting in significant library
complexity to achieve effectiveness as a real-time tool.

> Ben Brosgol
> [log in to unmask]

--
-Tucker Taft   [log in to unmask]   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

ATOM RSS1 RSS2