Go Back   Rhinocerus > Newsgroup > Newsgroup comp.soft-sys.sas

Reply
 
Thread Tools Display Modes
  #1 (permalink)  
Old 05-16-2006, 09:16 AM
John Kirkpatrick
Guest
 
Posts: n/a
Default Accessing a complex Java application using DECLARE JAVAOBJ

I have an application that I need to call from a SAS data step using the
DECLARE JAVAOBJ statement. The application is quite complex and consists of
a single main class and a number of helper classes.



There are a number of issues relating to the use of Java classes by SAS that
I have managed to resolve (mainly by reading Richard Devenezia's excellent
papers on the topic: many thanks, Richard), but one that is currently
stumping me is accessing packaged classes, especially when using JRE 1.5.



(Yes, I know JRE 1.5 isn't supported by SAS, but it can be used. As JRE 1.5
is installed on many Windows boxes by default and you can't tell SAS which
JRE to use when multiple JREs are installed on the same machine, I need to
find a way of getting things running under JRE 1.5.)



Here's what I've found out so far:



1. SAS doesn't support classes compiled with the package statement.



2. You can't redefine classpath, or use the JREOPTIONS system option in the
config file or command line to do so when using JRE 1.5. (The security
settings of the Java plug-in don't allow it.)



3. My application can be called by SAS if I place the main class and all
the helper classes in a single java file, make the main class the only
public class, remove all package statements and place the resultant jar file
in the classes folder under the JRE 1.5 home folder.



However, this isn't satisfactory for a number of reasons: it's a nightmare
for me to maintain; it makes life difficult for other programmers in the
situation where many custom classes are required (for a start, we have to be
aware of the names of each others classes).



What I'd like to be able to do is create an appropriate class hierarchy in
the classes folder under JRE home. For example classes/myapp/main.jar,
classes/myapp/helpers/class1.jar, classes/myapp/helpers/class2.jar.



When I do this, although SAS can find the main class, it can't instantiate
it. As I can't instatiate it, it's difficult to get any useful error
information returned, though I suspect the failure is due to an inability to
find and create the helper classes.



I've tried various combinations of jar file names, use and non-use of jar
file names and use and non-use of package statements, all without success.
Can anyone shed some light on the problem? Even telling me it can't be done
would be a help!



I realise this is quite a complex post. If I've failed to make anything
clear, or if you need more information, please feel free to ask for
clarification.



Thanks in advance,



John







*** Posted via a free Usenet account from http://www.teranews.com ***
Reply With Quote
Alt Today
Advertising
 
and become member of Rhinocerus
Standard Sponsored Links

  #2 (permalink)  
Old 05-16-2006, 03:12 PM
Richard A. DeVenezia
Guest
 
Posts: n/a
Default Re: Accessing a complex Java application using DECLARE JAVAOBJ

John Kirkpatrick wrote:
> I have an application that I need to call from a SAS data step using
> the DECLARE JAVAOBJ statement. The application is quite complex and
> consists of a single main class and a number of helper classes.



Remember, JavaObj is simple bridge (interface) for doing many things in the
JVM with accessible Java classes. It can not do generic interfacing as is
commonly done with ClassForName, nor can it receive an instance reference as
a return from a method { very limiting ideas for Java raised young'ns }

You often have to write your own adapters to simplify the bridging between
SAS and your Java system or library.

> There are a number of issues relating to the use of Java classes by
> SAS that I have managed to resolve (mainly by reading Richard
> Devenezia's excellent papers on the topic: many thanks, Richard), but
> one that is currently stumping me is accessing packaged classes,
> especially when using JRE 1.5.


You're welcome !

> Here's what I've found out so far:
>
> 1. SAS doesn't support classes compiled with the package statement.


Not sure why you think this. Can you show a simplified sample? Recall that
the JavaObj requires slashes as path separator (not dots) and dots for a
nested class are $ separated

declare JavaObj ("my/company/com/super/duper$handler")

> 2. You can't redefine classpath, or use the JREOPTIONS system option
> in the config file or command line to do so when using JRE 1.5.
> (The security settings of the Java plug-in don't allow it.)


Classpath can only be set at invocation of your SAS session. Once SAS is
running you can't change the classpath (Short of writing your own class
loaders with appropriate wrappage to let JavaObj use them)

> 3. My application can be called by SAS if I place the main class and
> all the helper classes in a single java file, make the main class the
> only public class, remove all package statements and place the
> resultant jar file in the classes folder under the JRE 1.5 home
> folder.


JavaObj is experimental, and IIRC, the way the classpath is
specified/controlled at invocation seemed to vary a little over the SAS v9
releases. It's probably either CLASSPATH environment variable or one of the
nested -D settings in the -JREOPTIONS env.var in your SAS sessions config
file (e.g. ...\nls\en\SASV9.CFG)

Not sure, but you may need to specify each individual jar, even if a folder
in the path contains multiple jars.

> However, this isn't satisfactory for a number of reasons: it's a
> nightmare for me to maintain; it makes life difficult for other
> programmers in the situation where many custom classes are required
> (for a start, we have to be aware of the names of each others
> classes).


Good Java design and access via JavaObj can often conflict. Flattening the
richness of OO for use in linear functional/procedural systems can be
aggravating.

> What I'd like to be able to do is create an appropriate class
> hierarchy in the classes folder under JRE home. For example
> classes/myapp/main.jar, classes/myapp/helpers/class1.jar,
> classes/myapp/helpers/class2.jar.


> When I do this, although SAS can find the main class, it can't
> instantiate it. As I can't instatiate it, it's difficult to get any
> useful error information returned, though I suspect the failure is
> due to an inability to find and create the helper classes.


> I've tried various combinations of jar file names, use and non-use of
> jar file names and use and non-use of package statements, all without
> success. Can anyone shed some light on the problem? Even telling me
> it can't be done would be a help!


Wouldn't dare say it can't be done with SAS.

> I realise this is quite a complex post. If I've failed to make
> anything clear, or if you need more information, please feel free to
> ask for clarification.


Do clarify or show a concrete example. While trying simplfy the situation
enough to make a succinct problem statement you may find your own solutions!

--
Richard A. DeVenezia
http://www.devenezia.com/


Reply With Quote
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to make Forth interesting? DavidM Newsgroup comp.lang.forth 73 05-08-2009 06:30 AM
Re: Update: SAS/InrNet Application Dispatcher Problem Alan Churchill Newsgroup comp.soft-sys.sas 1 12-09-2007 03:59 AM
Re: Check it out--we're java programmers Drew Eginton Newsgroup comp.soft-sys.sas 0 03-27-2007 08:05 PM
Re: SAS application dispatcher maximum concurrent users Don Henderson Newsgroup comp.soft-sys.sas 0 04-14-2006 03:46 PM
Re: Question: How does one move from SAS to Java? owner-sas-l@LISTSERV.UGA.EDU Newsgroup comp.soft-sys.sas 0 11-22-2004 02:16 PM



All times are GMT. The time now is 04:39 PM.


Copyright ©2009

LinkBacks Enabled by vBSEO 3.3.0 RC2 © 2009, Crawlability, Inc.