Date:         Mon, 5 Mar 2001 11:32:23 -0600
Reply-To:     Jonathan Goldberg <jonathan@MATLOCK.WUSTL.EDU>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Jonathan Goldberg <jonathan@MATLOCK.WUSTL.EDU>
Subject:      Re: JAVA replacing SAS? and J2EE...
Content-Type: TEXT/PLAIN; charset=US-ASCII

The poster below raises what is for me a personal issue.

I have so far managed to avoid learning both SAS and JAVA.  But I
have just started a new job at a shop with a fairly large investment
in AF/SCL code.  So, I assumed that I would have to go ahead an learn
SCL.

Now it is suggested that SCL is being replaced by JAVA.  Is it best to
skip SCL as far as possible and go straight to JAVA?  What does that
cost me in the near term?

I need to plan training soon.  I have two co-workers who are also facing
a similar decision.  Any thoughts as to what is best to do?

Jonathan


-----Original Message Seperator-----
>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