TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
text/plain; charset="iso-8859-1"
Tucker Taft <[log in to unmask]>, Ben Brosgol <[log in to unmask]>
Mon, 1 Nov 1999 14:10:32 -0500
Ben Brosgol <[log in to unmask]>
Ben Brosgol <[log in to unmask]>
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
text/plain (74 lines)
Tucker Taft wrote:
>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,
>> 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
>> 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.

A phenomenon not unique to Java :-)

>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),

I know about the AWT problems, but is this also an issue with Swing?

>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

I believe that the "one public class per source file" is a JDK restriction
and a suggestion to the implementation, but not a language requirement.  The
JLS does point out that host systems that store packages in a database need
not enforce the restriction.  I suppose that if all existing implementations
impose the restriction, then the flexibility does not matter today, but as
the technology matures this may be less of an issue.

>I sense that the effort to push Java into the real-time market is somewhat
>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.

My view of the metpahor is that this can work if you shave down the round
peg (Java) and then insert it into the round hole (real-time domain).  I.e.
you will need to avoid using some features that the language provides, and
on the other hand you might not satisfy the requirements of everyone who
needs to do real-time programming.

>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).

Both Real-Time Java specs also provide a mechanism for scoped / stack-based
allocation.  And it's also possible that for soft real-time apps, a
real-time garbage collector may be usable.

>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.

Partly it's an issue of library complexity, more generally it is also a
different style that is needed in using Java for real-time applications.  So
it will be interesting to see whether the potential users are willing /
ready to adapt their programming practices.

Ben Brosgol
[log in to unmask]