Letter to Eiffel Vendors: Eiffel and Java 
Author Message
 Letter to Eiffel Vendors: Eiffel and Java

Dear Eiffel Vendors:

The advent of Java will have a large impact on how software is developed.
Those of us who have decided to invest time and money using Eiffel as our
method of choice have a right to know how the Eiffel vendors will respond
to the upcoming changes in the software industry. Yet, to my surprise,
there seems to be little notice of these changes publicly acknowledged by
the Eiffel community. This makes me nervous.

In this note I briefly present the ways in which Java may impact software
development, outline possible responses by the Eiffel community, and plead
for the Eiffel vendors to be more forthcoming in their future plans.

HOW JAVA WILL AFFECT SOFTWARE DEVELOPMENT

In my opinion there are three major ways that Java will, within two years,
change the way software is developed:

1) Ubiquitous
This new, already overused buzzword simply means that the Java virtual
machine (VM) will be available on all major platforms and most minor
platforms. This means the compiled code on one system can be transferred
to a different system and be expected to run. This is one of the 3holy
grails2 of corporate MIS and will obviously change the way software is
developed, marketed, priced, and distributed.

2) Universal API1s
At the recent JavaOne conference it became clear that Sun Microsystems,
the developer of Java, is aggressively pursuing the creation of a base set
of API1s covering many aspects of programming once reserved by the
operating system. These include API1s for 2-d and 3-d graphics, network
security, database access, media (e.g. sound and movies), commerce (e.g.
selling things over the network), a new component model (Java beans), etc.

The advantage of the Sun API1s is that they, like Java, will be available
on all platforms. Assuming that these API1s become universal standards,
then all language system vendors will have to exactly match their
capabilities to remain competitive.

3) The Java Language
Java itself is a fairly attractive language. While it does not have the
sophistication of Eiffels object model (MI, generics, etc.), and it does
not have Eiffels features for creating correct programs (assertions etc.),
it avoids most of C++1s worst sins (excess complexity, pointers, etc) and,
despite its C syntax, Java is much closer philosophically to Smalltalk
than to C++.

There are two dangers for those of us who prefer Eiffel: First, that the
Java API1s will create a virtual and universal  computing platform from
which we will be frozen out (e.g. the platform is supported by the
universal API1s, Eiffel does not support these API1s) and second, that the
advent of an  wildly popular 3pretty good2 programming language will
further marginalize Eiffel since those who have recognized C++ flaws will
have another place besides Eiffel to go (e.g., Java). Thus, Eiffel is less
likely to achieve that critical mass needed to allow its wide spread
adoption and fewer companies will be willing to take a chance on Eiffel
technology.

HOW EIFFEL VENDORS CAN RESPOND

Here are five ways, in order from passive to aggressive, that Eiffel
vendors can respond:

1) Do nothing and hope Java is a failure.
Advantages: Very inexpensive.
Disadvantages: If wrong all vendors may go bankrupt.

2) Promise to create proprietary components to match capabilities of Java
components.
Advantages: An all Eiffel solution may be better than the Java solution.
Disadvantages: Not possible. Eiffel vendors do not have the resources to
compete with the many companies pooling their expertise and $1s in
supporting the Java effort. Any attempt to 3keep up with the Jonses2 will
fail.

3) Develop Eiffel/Java interface and lackadaisically port over Java API1s
to Eiffel.
Advantages: Will provide some Java API capability to Eiffel customers,
eventually.
Disadvantages: Eiffel/Java interface may be technically difficult and
inefficient. Speed of porting and attitude to porting may not inspire
sufficient confidence by Eiffel community.  

4) Develop Java/Eiffel interface and guarantee Java API availability to
Eiffel customers at same time API1s are available to Java customers (e.g.
upon initial release by Sun).
Advantages: Eiffel developers will be assured that they will not be frozen
out of emerging standards.
Disadvantages: Eiffel/Java interface may be technically difficult and
inefficient.

5) Modify Eiffel development environments to produce Java virtual machine
code instead of C code.
Advantages: Eiffel will instantly become available on all platforms.
Eiffel/Java interface would become trivial. Eiffel developers would be
guaranteed access to Java API1s as soon as they were available. Eiffel
customers would benefit from all technological improvements to the Java
technology. Eiffel vendors could spend more time improving Eiffel
methodology and developing useful proprietary libraries (such as ISE1s
EiffelMath) which may also be sold to Java customers (if the interface
goes two ways).  Corporate MIS departments may then view Eiffel as 3an
improved Java2 and would be less nervous about adopting Eiffel technology.
Disadvantages: It may be technically difficult to target the Java virtual
machine. The Virtual machine code may run too slowly. Eiffel vendors may
feel insecure about targeting the Java VM over which they have no control.
Comments: Sun has expressed a willingness to modify their VM to make it a
better target for vendors of other languages. Some companies are now
claiming that they will soon have technology which will allow Java VM code
to run at C/C++ performance levels.

I hope that the Eiffel community and the Eiffel vendors take the advent
and progress of Java as seriously as I do. I believe that only solutions
#4 and #5 will allow Eiffel to survive. If technically feasible I believe
that option #5 will serve us all the best. Finally, I plead for the Eiffel
vendors to respond publicly to this note and share their ideas and plans
with us.

Thank you,

Jeffrey W. Stulin



Fri, 27 Nov 1998 03:00:00 GMT  
 Letter to Eiffel Vendors: Eiffel and Java

Interesting to read Jeffrey Stulin's posting; similar thought had ocurred t=
o me.  =

I think he was a little over-pessimistic concerning Eiffel and over-optimis=
tic
about Java.

Quote:
> The advent of Java ...Yet, to my surprise,
> there seems to be little notice of these changes publicly acknowledged by=
> the Eiffel community. This makes me nervous.

Is that any different from response from C++ and Smalltalk communities?
Part of the problem here is the Java hype.  Many of the problems it
purports to address have already been solved by the technology around
Eiffel, C++, and Smalltalk.  Just not lied about loudly and publicly enough=
=2E

Quote:
> .. Eiffel vendors to be more forthcoming in their future plans.

They are working on it, but why should they give away strategic secrets to =

the enemy?  Or commit themselves to delivering tools that may prove unecono=
mic
or unnecessary to develop?  Recall ISE getting slagged for lateness with V3=
 ?

Quote:
> 1) Ubiquitous [Java Virtual Machine]
> ..compiled code on one system can be transferred
> to a different system and be expected to run. This is one of the =B3holy
> grails=B2 of corporate MIS ..

But what about ANSI-C ?  That is at least as ubiquitous, and available from=

many many suppliers rather than just two or three.  You will also find nume=
rous
other virtual machines available at least as widely, but with less hype.
Certainly Eiffel vendors already offer this capabililty.  Don't forget =

corporate MIS wants supplier independence as well as platform transparency.=

Quote:
> 2) Universal API=B9s
> ..Sun Microsystems..aggressively pursuing the creation of a base set
> of API=B9s .. include API=B9s for 2-d and 3-d graphics, network
> security, database access, media (e.g. sound and movies), commerce (e.g.
> selling things over the network), a new component model (Java beans), etc=

=2E

Universal API's are not the property of Sun or Java.  And few of them are
language specific beyond the requirement to support basic C types in a =

calling interface.  And they won't work as  "standards" if they simply lock=

users into a single track of development tools or language.  The whole poin=
t =

of object technology is that the inter-working of software components is =

de-coupled from the proprietorial internal nature of each component.

Quote:
> The advantage of the Sun API=B9s is that they, like Java, will be availab=
le
> on all platforms.

=2E.in many different versions, changing every year and forever incorporati=
ng new
bugs faster than the old ones can be ironed out.  There are already many VE=
RY
powerful software libraries in the object technology market place, with a d=
ecade =

of testing and development behind them.

Quote:
> Assuming that these API=B9s become universal standards,
> then all language system vendors will have to exactly match their
> capabilities to remain competitive.

  a) it will be relatively easy for mature vendors to match and exceed
     capabilities of Java libraries
AND/OR
  b) it will be quite possible for other vendors to support Java API
AND/OR
  c) all vendors will have to make their language systems work in distribut=
ed
     heterogeneous environment anyway, so whether any one component is Java=

     or Eiffel or C++ or CORBA will not make any difference.

Quote:
> 3) The Java Language
> Java itself is a fairly attractive language. =

I disagree.
Java is in almost all respects inferior to the Turing language, used at Ont=
ario
University for around a decade now.  They did it all and much more, a long
time ago (and it goes like greased lightning).

Quote:
> While it does not have the
> sophistication of Eiffels object model (MI, generics, etc.). and it does
> not have Eiffels features for creating correct programs (assertions etc.)=

,

It also compares badly with C++ in these respects.

Quote:
> it avoids most of C++=B9s worst sins (excess complexity, pointers, etc) =

Disciplined programmers working carefully with C++ utilising good tools and=

class libraries can also avoid the worst sins of C++, without having to mov=
e
over to a weaker and slower language.

Quote:
> despite its C syntax, Java is much closer philosophically to Smalltalk
> than to C++.

I disagree.  Nor will it come anywhere near competing with Smalltalk in the=
 kinds of
software development where dynamic typing and interpretive environments pay=
 off.

Quote:
> dangers ..virtual and universal  computing platform from
> which we will be frozen out =

Java VM will fail if it attempts to freeze out other systems.  The market
demands *OPEN* systems.

Quote:
> advent of an  wildly popular =B3pretty good=B2 programming language will
> further marginalize Eiffel since those who have recognized C++ flaws will=
> have another place besides Eiffel to go =

Always a problem .. but Eiffel can survive very profitably even in a tiny
fraction of the overall market..so long as vendors continue to provide good=

reasons to adopt Eiffel technology, and no reasons to avoid it.

Quote:
> HOW EIFFEL VENDORS CAN RESPOND
> 1) Do nothing and hope Java is a failure.

Not the case already.  The major suppliers already offer IDEs and CASE tool=
s
much more sophisticated and mature than anything in the Java arena.  And mu=
ch
more OODB connectivity.  And heterogeneous network distribution, standardis=
ed
basic API, several near-standard data structures, windows, graphics, and
networking APIs, virtual machine technology, commonality across major
platforms with or without the virtual machines.

Quote:
> 2) Promise to create proprietary components to match capabilities of Java=
> components.

Mostly done already.  Don't forget that the major advantage of Java offerin=
g =

secure operations in distributed or applet mode is turning out to be imposs=
ible
to achieve. And the transmission security you get by embedding stuff in HTM=
L =

comms. with, eg, Netscape's RSA encryption, is worthless outside USA.

Quote:
> 3) Develop Eiffel/Java interface and lackadaisically port over Java API=B9=

s

Why lackadaisically?  Why not do it properly?  They already have interfaces=
 to
C and C++ APIs.  I suggest that if Sun fix it so that port to Java API is =

significantly harder than port to C(++) API then it will DIE DIE DIE.

Quote:
> 4) Develop Java/Eiffel interface and guarantee Java API availability to
> Eiffel customers at same time API=B9s are available to Java customers (e.=
g.
> upon initial release by Sun).

not necessary (see 3 above)

Quote:
> 5) Modify Eiffel development environments to produce Java virtual machine=
> code instead of C code.

I would not be at all surprised if they are not already running this in
alpha.  Also many C compilers will soon be kicking out J-code, so Java
VM serving will become automatic for any system capable of generating C.
Will Sun be stupid enough to lock non-Java technology out of Java Virtual =

Machines?

-- =

person: Graham Perkins     paper: School of Computing

voice:  +44 190 883 4936          Milton Keynes MK7 6HP
dots:   +44 190 883 4948          United Kingdom



Sat, 28 Nov 1998 03:00:00 GMT  
 Letter to Eiffel Vendors: Eiffel and Java


Quote:
>Dear Eiffel Vendors:

>In my opinion there are three major ways that Java will, within two years,
>change the way software is developed:

>1) Ubiquitous
>This new, already overused buzzword simply means that the Java virtual
>machine (VM) will be available on all major platforms and most minor
>platforms. This means the compiled code on one system can be transferred
>to a different system and be expected to run. This is one of the 3holy
>grails2 of corporate MIS and will obviously change the way software is
>developed, marketed, priced, and distributed.

It seems to me that some performances issues must be resolved before
saying that the portability of the Java pre-compiled code will actually
interrest large scale applications development. I'm curious to ear what
really interest software developer: A language that s/he can compile on a
wide range of architecture or a source code that can be interpreted on a
wide range of architecture.

For myself, I never actually face problem of portability in Eiffel. I am
working with ISE Eiffel which generate basic C code from Eiffel programs.
Thus, provided a C compiler, which is not unreachable requirement, and a
runtime version, I can run my apps on basically all architecture.

Of course, two facts must be pointed out:

        First, all the targeted architecture must have the same minimal
        functionnality to ensure the run-time will work fine. But it's
        the same problem with the Java virtual machine.

        Second, you should have a run-time version for the targeted arch.
        This can be done without much efforts. I do it personnaly for
        Intel Paragon XP/s, Power Challenge Array, and various work stations.
        Because I am a PhD student I do not deeply test those Run-Times
        but the lesson from these ports is that it can be done and this
        is the job of the Eiffel vendors !

Quote:
>2) Universal API1s
>At the recent JavaOne conference it became clear that Sun Microsystems,
>the developer of Java, is aggressively pursuing the creation of a base set
>of API1s covering many aspects of programming once reserved by the
>operating system. These include API1s for 2-d and 3-d graphics, network
>security, database access, media (e.g. sound and movies), commerce (e.g.
>selling things over the network), a new component model (Java beans), etc.

I agree, a lot of work have to be done to normalize standard libraries. I
think that NICE is working on this, may be they should hurry up ?

But what you gives as examples are application domains dependant. Absolutly
necessary of course, but is it the job of Eiffel vendors or of other
society ?

Quote:

>The advantage of the Sun API1s is that they, like Java, will be available
>on all platforms. Assuming that these API1s become universal standards,
>then all language system vendors will have to exactly match their
>capabilities to remain competitive.

This will be a good thing.

Quote:
>3) The Java Language
>Java itself is a fairly attractive language. While it does not have the
>sophistication of Eiffels object model (MI, generics, etc.), and it does
>not have Eiffels features for creating correct programs (assertions etc.),
>it avoids most of C++1s worst sins (excess complexity, pointers, etc) and,
>despite its C syntax, Java is much closer philosophically to Smalltalk
>than to C++.

>There are two dangers for those of us who prefer Eiffel: First, that the
>Java API1s will create a virtual and universal  computing platform from
>which we will be frozen out (e.g. the platform is supported by the
>universal API1s, Eiffel does not support these API1s) and second, that the
>advent of an  wildly popular 3pretty good2 programming language will
>further marginalize Eiffel since those who have recognized C++ flaws will
>have another place besides Eiffel to go (e.g., Java). Thus, Eiffel is less
>likely to achieve that critical mass needed to allow its wide spread
>adoption and fewer companies will be willing to take a chance on Eiffel
>technology.

I agree. There's no time to sleep for us :-) It's not enough to say
"we got the best langage you need", you have to provide enough tools
to make it productive.

Quote:
>1) Do nothing and hope Java is a failure.
>Advantages: Very inexpensive.
>Disadvantages: If wrong all vendors may go bankrupt.

Even if Java is technically a bad solution, we must that care of its
current success ! Remember how Windows was badly design and offers
less possibilities that X Window, look at MS-DOS and Unix workstations
and then compare the success of MS-DOS and Windows/95 and PC-based
unix / X-Window solutions !!!

They answer to desire from the user, and we cannot ignore it.

Quote:
> [...]

>I hope that the Eiffel community and the Eiffel vendors take the advent
>and progress of Java as seriously as I do. I believe that only solutions
>#4 and #5 will allow Eiffel to survive. If technically feasible I believe
>that option #5 will serve us all the best. Finally, I plead for the Eiffel
>vendors to respond publicly to this note and share their ideas and plans
>with us.

Of course, the more interesting answer will come from the Eiffel vendors,
so ... let's wait again :-)

--
-----------------------------------------------------------------------

 Campus de Beaulieu                  Phone: (33) 99 84 74 08
 F-35042 RENNES CEDEX (FRANCE)       Fax  : (33) 99 38 38 32
-----------------------------------------------------------------------



Sat, 28 Nov 1998 03:00:00 GMT  
 Letter to Eiffel Vendors: Eiffel and Java

Jeffrey W. Stulin:

[Java changes the world]

Quote:
> Yet, to my surprise, there seems to be little notice of these changes
> publicly acknowledged by the Eiffel community. This makes me nervous.

Many vendors have announced 'Java support', though I would not bet on the
delivery date...

Quote:
> In my opinion there are three major ways that Java will, within two years,
> change the way software is developed:

The computer world is full of people who have promised that their new and
exciting technology was going to change the world in the next few years...
Most of them were wrong obviously.

Java may be the best thing since sliced bread, if you keep in mind the fact
that sliced bread has No Taste At All(tm)...

Quote:
> 1) Ubiquitous
> This new, already overused buzzword simply means that the Java virtual
> machine (VM) will be available on all major platforms and most minor
> platforms. This means the compiled code on one system can be transferred
> to a different system and be expected to run.

That may work... unless every platform vendor joins the my gizmo-is-better-
than-yours bandwagon and adds 'cool' proprietary extensions, killing
portability thanks to developers 'enhancing' for the mainstream platform
(the Netscape syndrome). I'm told Java programs which only work on
Windows 95 are already appearing (at that early stage!).

BTW, I'd like to understand why that concept is suddenly popular while
it has been available for years from other people (eg OSF ANDF) without
anybody noticing.

Quote:
> 2) Universal API's

Same problems as above, same attempts done before.

Quote:
> 3) The Java Language
> Java itself is a fairly attractive language. ...

Yes, but it is a _dynamic_, single inheritance language. It is direct
competition for languages like Objective C or Smalltalk, Eiffel is in
another category.

Quote:
> 1) Do nothing and hope Java is a failure.
> Disadvantages: If wrong all vendors may go bankrupt.

Will they? Eiffel still exists despite C++ success. I don't think Java is
going to replace all other languages even if it may, or may not, become a
major player (and I for one would not complain if it replaced C++).

Quote:
> 4) Develop Java/Eiffel interface and guarantee Java API availability to
> Eiffel customers at same time APIs are available to Java customers (e.g.
> upon initial release by Sun).

That's possible and useful, as another external interface. It does not
replace the need for software in Eiffel, as the Java components are not
going to have the benefits of Eiffel components from an Eiffel viewpoint.

Quote:
> 5) Modify Eiffel development environments to produce Java virtual machine
> code instead of C code.

People don't stop proposing that all the time. What about reading the
manual? The Java VM is _not_ like an abstract portable assembler. It
is like that _inside_ an object, but not between objects. The Java
object model, at the highest level, is imposed on JVM applications.

The result is that you cannot implement easily any language that doesn't
use the Java object model (single inheritance, dynamic language, etc) or
at a great cost. The only thing that seems meaningful to do is to change
the syntax (eg a language with an Eiffelish syntax and the Java object
model is feasible and sensible, but that's not Eiffel, that's just Java
with a proper syntax).

It may be possible to painfully emulate Eiffel on the JVM but I guess
that's doomed to be clumsy, inconvenient and with great limitations.

Quote:
> Eiffel/Java interface would become trivial.

No, for the reasons exposed above. An Eiffel object cannot equal a
Java object, therefore it cannot be 'trivial'.

Quote:
> Comments: Sun has expressed a willingness to modify their VM to make it a
> better target for vendors of other languages.

Well, that does not seem possible to me for languages like Eiffel without
dramatically changing it. Anyway, once the first release gets out in the
wider world, it will be to a large extent frozen, because older versions
will have to be supported.Sun is busy putting the JVM into silicon at
the moment, that doesn't look like it is something that is going to
change very often.


Sun, 29 Nov 1998 03:00:00 GMT  
 Letter to Eiffel Vendors: Eiffel and Java

Quote:

> Jeffrey W. Stulin:

> > 3) The Java Language
> > Java itself is a fairly attractive language. ...

> Yes, but it is a _dynamic_, single inheritance language. It is direct
> competition for languages like Objective C or Smalltalk, Eiffel is in
> another category.

==========
Java classes inherit single type (implementation), and implements
multiple interfaces. Interfaces are first class types in Java, meaning a
class that implements interface A is accepted anywhere interface A is
specified as a formal arg. In this sense, Java is much closer to Eiffel
than Smalltalk or even C++.


Mon, 30 Nov 1998 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Eiffel et Java; Viva Le Eiffel

2. The J-Eiffel project (Eiffel-to-Java compiler)

3. Project Bruce: Translating from Eiffel to Java (@Eiffel Liberty Journal)

4. Eiffel to Java and Java VM code generation

5. Free library offer from Eiffel vendor in Germany

6. JOOP letter on Eiffel type checking

7. JPN Eiffel 3 for Windows NT, including Eiffel Vision

8. An Eiffel World-Wide-Web entry at eiffel.com

9. Eiffel gripe (was Ada vs. Eiffel)

10. Eon/Eiffel - Shareware Eiffel compiler

11. Eiffel Object Representation (Eiffel-OR)

 

 
Powered by phpBB® Forum Software