Date:         Sat, 3 Mar 2001 22:51:54 -0500
Reply-To:     "David L. Ward" <dward@INTERNEXT-INC.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "David L. Ward" <dward@INTERNEXT-INC.COM>
Subject:      Re: JAVA replacing SAS? and J2EE...
Content-Type: text/plain; charset="iso-8859-1"

Jay Stevens <jay@WHITEHURST-ASSOCIATES.COM> wrote (in part)...

>Oh another prediction... AF/SCL are dead dinosaurs.  They have already
begun to look an awful lot like Java.  My guess... they soon WILL be
Java.

My primary client is an AF shop.  We have had direct confirmation from
technical support that SCL is no longer going to be developed (we may not
see another version or any more enhancements).  This does not mean, however,
that it will go away.  SAS usually does pretty well with keeping
functionality around for many years (heck, why do you think your 8.1
installation is 350 MB?).  Have you ever noticed how much of the SAS system
is written using SCL?  (I mean the user interface).  Under windows,
practically the whole display manager is frame, with the objects and classes
coming from sashelp.*.  We've learned how to use some of the institute's
internal classes to customize our software in ways that weren't intended.
SAS could begin to "re-write" their front-end, but that would take time and
they are still actively releasing the 8.* series.  I think Java support will
come in the form of allowing us to build java classes that import from a set
of SAS libraries that would call BASE/SAS procs and code.  I don't think we
could call SCL objects like frames or classes or lists from Java
stand-alone.  Rather, that kind of support would probably come from SCL in a
frame, allowing us to call Java methods instead of SAS methods:

The most logical way of SAS handling Java classes would be to simply allow
us to place our class and jar files in libnames, so that we have a new file
type (jclass).  We could then do this:

Import MyClasses.MyJarFile.<...>.Class1.jClass;
Import MyClasses.Class2.jClass;
Dcl class1 obj = _new_ class1();
init:
  class1.property=...;
  class1.method();
return;


The Java syntax could be something like:

Import SAS.proc.*;
Import SAS.code.*;
Import SAS.af.*;
// or SAS.*
public class myClass();
  public static void main(String[] args) {
    ProcMeans means = new ProcMeans();
    ProcMeans.data = "data file";
    ProcMeans.<other attributes>;
    ProcMeans.execute();
  }
}

I could also see two other ways SAS could integrate Java into their product:

Call Java classes in data steps:
data _null_;
  import 'path to class file';
  rc=java('class',args...);
run;

It is also logical to allow the use of applets of console applications
instead of Frames that could act as front-ends to SAS in a DM session.  The
java code would offer some kind of syntax similar to the SCL submit blocks.


This kind of thinking is actually really neat, it would force us AF
developers into the Java world and also allow some of our SAS apps to be
*more* portable.  The thing I hate most about doing SCL work is that users
must have SAS licensed to run AF apps.  With Java front-end support and some
kind of re-distributable SAS core maybe we can eventually write stand-alone
apps (how would this affect SI's business model?...).


My 3c (I've said enough)

Regards,
David Ward
------------------------------------
President
InterNext, Inc.
Software for the Internet Generation
------------------------------------