Possible to write compiler to Java VM? 
Author Message
 Possible to write compiler to Java VM?

|So I'm asking you all: how easy/hard/impossible would it be to write a
|compiler for your favorite language(s) that compiles to Java VM
|byte-codes.

Quote:

>[...]  A few companies are working on this as we speak; sorry no
>details.  An NCSA/Mosaic fellow mentioned Ada-95 as one language
>in the works by some other company.

Although Java is a programming language which is syntactically similar
to C++, it is semantically much closer to Ada 95.

Some pointers on using Ada for applet development follow (extracted from
the Ada-Belgium home page).

* Intermetrics is building a product to develop Java applets in Ada 95.
  More info on URL:
    http://www.*-*-*.com/

* ACM SIGAda dedicated a website to promoting the use of Ada95 as a
  major language for programming Web and Internet applets and
  applications, servers and browsers.  URL:
    http://www.*-*-*.com/

* Another Ada and WWW/Java page is in the "Resources for Ada" section of
  the HBAP (Home for the Brave Ada Programmers).  URL:
    http://www.*-*-*.com/

I hope this helps.

Dirk Craeynest

PS: Is anyone looking at the feasibility of retargetting GNAT (the
    freely available GNU Ada 95 compiler) to Java Byte Code?

--

   OFFIS NV/SA | c/o Eurocontrol - CFMU  |        cfmu.eurocontrol.be
   Ada-Belgium | Raketstraat 96          | Phone: ++32(2)729.97.36
   Team Ada    | B-1130 Brussel, Belgium | Fax:   ++32(2)729.90.22
--




Mon, 13 Jul 1998 03:00:00 GMT  
 Possible to write compiler to Java VM?

Quote:

> Although Java is a programming language which is syntactically similar
> to C++, it is semantically much closer to Ada 95.

I've heard this from several sources but havent seen a
reasoned argument in support of it..is there one sitting
around somewhere?

   thomas

--
Thomas Dunbar    540 231-3938 (fax 3714)   http://gserver.grads.vt.edu/
--




Wed, 15 Jul 1998 03:00:00 GMT  
 Possible to write compiler to Java VM?

Quote:

> Although Java is a programming language which is syntactically
> similar to C++, it is semantically much closer to Ada 95.

> I've heard this from several sources but havent seen a
> reasoned argument in support of it..is there one sitting
> around somewhere?

You may have a look on:

    http://lglwww.epfl.ch/Ada/Resources/Ada_Java.html

There is a table comparing Java, Ada and C++.

  Sam
--




Thu, 16 Jul 1998 03:00:00 GMT  
 Possible to write compiler to Java VM?

Quote:

> Although Java is a programming language which is syntactically
> similar to C++, it is semantically much closer to Ada 95.

> You may have a look on:
>     http://www.*-*-*.com/
> There is a table comparing Java, Ada and C++.

I looked at this web page, and it said that Ada-95 is the language
that Java 'should have been'.  With the exception of Ada's header
files, which are a clear advance over C/C++ header files, I think that
this analysis is completely wrong.  Ada-95 asked for suggestions on
how to improve Ada-83, and got around 1000, or so.  Many of them asked
for turning Ada into a bad approximation to C++, most of which were
thankfully rejected.  However, most of those suggestions asking to fix
the underlying problems with Ada-83 were rejected, as well.

The resulting language -- Ada-95 -- has flashes of brilliance (it
would have had more, but some of these flashes were doused by the
usual politics of language standardization), but carries far too much
baggage that it should have jettisoned.

Ada is by far the most frustrating language I have ever dealt with.
Even after many programs and many, many hours with the reference
manual, I would be loathe to attempt to predict that any of my
programs would compile the first time.  There are far too many bizarre
rules -- including some which no one can provide any comprehensible
reason for.  For many years, there ran in ACM Ada Letters a column
called 'Dear Ada', which basically discussed (with unseemly relish,
IMHO) all of these bizarre interactions of obscure rules.  Truly Ada
is a worthy successor to PL/I in this regard.

However, the single most important reason why Java is a _much_ better
language than Ada-95 is the fact that Java does garbage collection and
Ada does not.  Twice now, the Ada language people have gone AWOL
(absent without leave -- i.e., deserted) on the GC issue, and for no
technically supportable reasons.  Their cowardice under (friendly!)
fire leaves them no m{*filter*}high ground to claim any kind of superiority
over even Basic or Lotus 123, much less Java.

--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
--




Fri, 17 Jul 1998 03:00:00 GMT  
 Possible to write compiler to Java VM?

: However, the single most important reason why Java is a _much_ better
: language than Ada-95 is the fact that Java does garbage collection and
: Ada does not.

Actually, AdaMagic/Java does use garbage collection.  The Ada 95
standard does not mandate garbage collection, but it does allow it.
And the AdaMagic/Java implementation takes advantage of that
allowance.

Probably even the Java standard, were it to exist, could not easily
mandate any particular kind of garbage collection.  In this sense, Ada
95 and Java would be similar.  The difference is that there exists a
reference Java implementation that provides reasonable garbage
collection (albeit probably not acceptable for real-time
applications), and garbage collection is presumed to exist by Java
programmers.

Until the real-time and safety-critical community embraces garbage
collection, Ada clearly must support "manual" storage management.  I
might believe that their concerns about garbage collection are not
"technically defensible," but that doesn't change the fact of their
concerns.  Ada 83 tried to impose a particular task synchronization
model on the real-time community (rendezvous), and never convinced a
large portion of them.  To try to impose the garbage-collection model
of storage management at this stage on the same community would be a
similarly doomed effort.

Perhaps in 200x, with a decade of experience with implementations like
AdaMagic/Java, Java itself, concurrent Eiffel (presuming it becomes
widely available), Modula-3, etc., which attempt to address real-time
programming while providing garbage collection, it will be feasible to
banish support for manual storage management.  But only time will
tell.

--

Intermetrics, Inc.  Cambridge, MA  USA
--




Fri, 17 Jul 1998 03:00:00 GMT  
 Possible to write compiler to Java VM?

Quote:

> Ada is by far the most frustrating language I have ever dealt with.
> Even after many programs and many, many hours with the reference
> manual, I would be loathe to attempt to predict that any of my
> programs would compile the first time.

That's a strange objection.  When an Ada compiler rejects my source,
it is because compile-time consistency checks have caught me trying to
do something that does not make sense.  I am grateful to have had the
mistake caught before I wasted hours debugging.  I am far more
frustrated by C compilers that happily compile code containing the
kind of errors that an Ada compiler would have caught.

Quote:
> There are far too many bizarre rules -- including some which no one
> can provide any comprehensible reason for.

There may be rules whose reasons you are unaware of, but not rules
without reasons.

Quote:
> For many years, there ran in ACM Ada Letters a column called 'Dear
> Ada', which basically discussed (with unseemly relish, IMHO) all of
> these bizarre interactions of obscure rules.

I agree that this column sometimes focused too much on language
pathologies unlikely to arise in real programs.  As a "language
lawyer", I enjoyed reading these columns, but some of them were not
appropriate tutorial material and created the false impression about
Ada that you have conveyed.

Quote:
> Truly Ada is a worthy successor to PL/I in this regard.

No, the conversion and arithmetic-precision rules of PL/I led to {*filter*}
surprises in run-time behavior.  Pathological Ada programs might
sometimes surprise you by failing to compile, but they rarely have
surprising run-time effects.

Quote:
> However, the single most important reason why Java is a _much_ better
> language than Ada-95 is the fact that Java does garbage collection and
> Ada does not.  Twice now, the Ada language people have gone AWOL
> (absent without leave -- i.e., deserted) on the GC issue, and for no
> technically supportable reasons.

In fact, both Ada and Java allow, but do not require garbage
collection.  It is impossible for a programming language to REQUIRE
garbage collection because, in the absence of an overspecified storage
model, it is impossible to define a semantic difference between the
presence and absence of garbage collection--it only affects how soon
you run out of storage.  The Java language specification does express
the informal expectation that inaccessible storage will be reclaimed.
I agree that such behavior is desirable in many applications,
including web applets.  However, Ada is designed to be used, among
other places, for time-critical and safety-critical applications, for
which garbage collection is undesirable.

The Ada language design was correct to make garbage collection
optional.  It is regrettable that Ada implementers have not been eager
to provide this option, but I expect that to change in the future
because of market demands.  In particular, the Ada compiler targeted
to the Java virtual machine (JVM) will have garbage collection on any
JVM implementation that provides it.  Also, the free availability of
GNAT sources makes the addition of garbage collection to GNAT a very
tempting research topic for an ambitious graduate student.

Bottom line: Java programs do not contain any instructions
implementing garbage collection, but are targeted to run on
implementations of the Java virtual machine, and these implementations
provide garbage collection.  Ada programs can also be targetted to run
on Java virtual machines, and when they are, they too enjoy the
benefits of garbage collection.  The only platforms on which Ada
programs must run without garbage collection are those on which Java
programs do not run at all!

--

--




Fri, 17 Jul 1998 03:00:00 GMT  
 Possible to write compiler to Java VM?
"However, the single most important reason why Java is a _much_ better
language than Ada-95 is the fact that Java does garbage collection and
Ada does not.  Twice now, the Ada language people have gone AWOL
(absent without leave -- i.e., deserted) on the GC issue, and for no
technically supportable reasons.  Their cowardice under (friendly!)
fire leaves them no m{*filter*}high ground to claim any kind of superiority
over even Basic or Lotus 123, much less Java."

Henry's note included a lot of his usual uninformed rhetoric, but the
above paragraph is just plain nonsense.

Garbage collection is a technique for automatic storage management
that is pretty much language independent. It is a good idea for some
environments, and not for others. In particular, embedded applications
and hard real-time applications prefer to stay away from garbage
collection.

In the case of Ada, it is certainly possible to implement GC in an Ada
95 environment, and indeed the Ada compiler from Intermetrics that is
based on JBC technology does full garbage collection.

Requiring garbage collection at the formal semantic level is actually
a little tricky, even if it is considered desirable. Indeed we
discussed the question of requiring such technology, rather than
leaving it optional as in Ada 95, and a very concious decision was
made that it was a bad idea to require it.

I guess one person's cowardice is another persons considered technical
judgment. Many of these things are a matter of technical taste, and I
fear that I am not entirely happey with Mr. Baker's technical taste on
many things. Also I am a little reluctant to accept as an expert on
such things someone who, by his own admission, knows Ada so poorly
that he has trouble writing correct Ada programs!
--




Fri, 17 Jul 1998 03:00:00 GMT  
 Possible to write compiler to Java VM?
: However, the single most important reason why Java is a _much_ better
: language than Ada-95 is the fact that Java does garbage collection and
: Ada does not.

Quote:

> Actually, AdaMagic/Java does use garbage collection.  The Ada 95
> standard does not mandate garbage collection, but it does allow it.
> And the AdaMagic/Java implementation takes advantage of that
> allowance.

(Tucker & I have discussed this issue ad nauseum, so I don't think
anything I say here about Ada will come as any surprise to him.)

Ada83 did not mandate garbage collection, but allowed it.  However,
the only implementations I can think of that had GC were the AdaEd
interpreter, and the Symbolics version, and I'm not sure whether the
Symbolics version was ever worked on enough to collect all of its
garbage.  (It passed the certification test, but since GC wasn't
required, the GC code obviously wasn't tested by the certification
test.)

Quote:
> Probably even the Java standard, were it to exist, could not easily
> mandate any particular kind of garbage collection.  In this sense, Ada
> 95 and Java would be similar.  The difference is that there exists a
> reference Java implementation that provides reasonable garbage
> collection (albeit probably not acceptable for real-time
> applications), and garbage collection is presumed to exist by Java

                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Quote:
> programmers.

And that makes all the difference.  A strong 'de facto' standard will
beat an imposed standard any day of the week.

Quote:
> Until the real-time and safety-critical community embraces garbage
> collection, Ada clearly must support "manual" storage management.  I
> might believe that their concerns about garbage collection are not
> "technically defensible," but that doesn't change the fact of their
> concerns.

Many of the complaints I heard from the real-time community were about
Ada implementations with _storage leaks_ (type safety is pretty good
in Ada, so that complaint wasn't heard very much, contrary to the
situation in the C/C++ community).  A real-time system won't run
terribly long if it constantly leaks storage.  Since GC is an
excellent way to stop storage leaks, I suspect that they would be
thrilled if they were provided with a GC that solved this leak
problem.

Both Tucker & I have both written papers about how to do storage
management in Ada, and whether automatic or manual, it doesn't matter
-- Ada makes it nearly impossible to control what is going on, because
they didn't standardize the interface to the lower levels of the OS
interface and the I/O.

People want to _control_ storage management, but they don't want to
_do_ it themselves, because they know that they make mistakes.  One
can have GC's with 'reflective' interfaces to control them -- how do
you think that large Lisp operating systems ever worked?

Quote:
> Ada 83 tried to impose a particular task synchronization
> model on the real-time community (rendezvous), and never convinced a
> large portion of them.

That's because a) the model was never tested in any other language
before springing full-born from the brow of Zeus, and b) once people
tested it, they found that it sucked.

Quote:
> To try to impose the garbage-collection model of storage management
> at this stage on the same community would be a similarly doomed
> effort.

Big difference.  By the time Ada83 came out, the computer science
community had already had 23 years of experience with garbage
collection.

Quote:
> Perhaps in 200x, with a decade of experience with implementations
> like AdaMagic/Java, Java itself, concurrent Eiffel (presuming it
> becomes widely available), Modula-3, etc., which attempt to address
> real-time programming while providing garbage collection, it will be
> feasible to banish support for manual storage management.  But only
> time will tell.

No one wants to 'banish' manual storage management -- they want it to
coexist peacefully with GC and other approaches.  But if Ada doesn't
start leading instead of following, her days are numbered.

However, in death, Ada may finally ease the incredible pain and
suffering that has racked her body ever since she was born.

Ada's parents had a devil of a time getting pregnant in the first
place.  They consulted all sorts of witch doctors and spent millions
of dollars on fertility {*filter*}.  In the end, Ada's mother got pregnant
with quadruplets.  However, in order to save Ada, the other three
siblings were sacrificed.  Some say that Ada may have been the ugliest
of the litter.

Ada was born prematurely, with profound birth defects, and had to
spend the first 7 years on life support, and had to have several major
operations which cost hundreds of millions of dollars.  Even then, she
had trouble breathing on her own, and due to her crippling
disabilities had to have lots of expensive prosthetics.  She was fat,
ugly -- a kind of female 'Elephant Man'.  Many doctors had pity on her
and provided her free medical care, but their efforts financially
ruined their medical practises.

Ada spent the next several years living in a foster home, because her
parents had abandoned her.  They professed to care, but gave most of
Ada's Christmas presents to Cecilia, the neighborhood slut.  Ada
performed simple tasks like basket-weaving which passed the time, and
gave her something to make herself feel useful.  Within the walls of
this protected environment, Ada could avoid other children poking fun
at her disabilities and diapers.

More recently, her parents decided that if they could give her a
little plastic surgery, they could make her more beautiful, and
perhaps some prince in shining armor would sweep her off her crutches
and start paying for her medical bills.  The decision was made to try
to make her look more like Cecilia -- or more correctly, the way
Cecilia looked after _her_ plastic surgery.

We don't know yet whether Ada's surgery will achieve the desired
purpose, but it should be known that beneath those pretty petticoats
are some very crippled limbs on a still-fat body dressed in Depends.
--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
[There's no question, Henry wins the metaphor of the month award. -John]
--




Fri, 17 Jul 1998 03:00:00 GMT  
 Possible to write compiler to Java VM?

: However, the single most important reason why Java is a _much_ better
: language than Ada-95 is the fact that Java does garbage collection and
: Ada does not.

Quote:

> The reason for leaving it out is summarized in 2 words: REAL TIME. ...

You might want to take a look at Erlang, a real-time language for
telephony applications, which uses GC.

See http://www.ericsson.se/cslab/erlang/overview.html

Also, see Springer LNCS 986, Proc. IWMM'95.
--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
--




Sat, 18 Jul 1998 03:00:00 GMT  
 Possible to write compiler to Java VM?

Quote:

>Perhaps in 200x, with a decade of experience with implementations like
>AdaMagic/Java, Java itself, concurrent Eiffel (presuming it becomes
>widely available), Modula-3, etc., which attempt to address real-time
>programming while providing garbage collection, it will be feasible to
>banish support for manual storage management.  But only time will tell.

An example of a real-time environment with garbage collection is the Minima
Lisp system from Symbolics which we have used in an underwater research
vehicle.

-Bob

Robert L. Spooner             Applied Research Laboratory
(814) 863-4120                             PO Box 30

--




Sat, 18 Jul 1998 03:00:00 GMT  
 Possible to write compiler to Java VM?

: However, the single most important reason why Java is a _much_ better
: language than Ada-95 is the fact that Java does garbage collection and
: Ada does not.

I agree that it's really nice from the programmer's point of view to
have GC built in.  It makes programming way easier in many situations.
I've been doing some Java work lately and having GC is really nice.

: Twice now, the Ada language people have gone AWOL
: (absent without leave -- i.e., deserted) on the GC issue, and for no
: technically supportable reasons.  Their cowardice under (friendly!)
: fire leaves them no m{*filter*}high ground to claim any kind of superiority
: over even Basic or Lotus 123, much less Java.

The reason for leaving it out is summarized in 2 words: REAL TIME.
Ada is meant for real time programs and (pause, put on asbestos suit
and flame-retardant helmet) GC isn't.

In an environment like the Net the non-determinacy of GC is a drop in
the bucket compared with the non-determinacy of the Net itself.  (Will
accessing a file on another machine take 1/10 of a second or 1 minute?
Not sure, depends on the traffic today.)  In the world of embedded
real time systems GC cannot be relied upon.

- Mitch Gart
--




Sat, 18 Jul 1998 03:00:00 GMT  
 
 [ 188 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]

 Relevant Pages 

1. Possible to write compiler to Java VM? (I volunteer to summarize)

2. Smalltalk VM / JAVA VM?

3. Eiffel to Java and Java VM code generation

4. IBM Compiler for VM is in the Dec 92 compiler list

5. Language Foo -> Java VM compilers: which ones possible?

6. Java VM for 370 ?

7. J for the Java VM?

8. Java(tm) VM Research and Technology Symposium: August 1-2,

9. Smalltalk for Java VM?

10. Sun's intent to support Smalltalk on Java VM

11. Smalltalk on top of the Java VM

12. Smalltalk for the Java VM

 

 
Powered by phpBB® Forum Software