Re: compiling BSF4ooRexx from sources - not yet
rony
first and foremost: compiling the Java sources is currently a little bit cumbersome (I just realized
this from your posting, I must admit), as not all dependencies are explicitly documented, sorry for
that!
The good news is however, that all Java source-files are compiled and in the install archive. There
should be no need to re-compile the Java sources (in Java 32-bit and 64-bit is not relevant for the
Java class files).
However, this is clearly not desirable for the release version. Will try to come up with the
necessary Maven definitions, which also includes all dependencies which automagically will be
resolved by the Maven build environment.
The situation is different for the cc-source file, which may need recompilations for different
platforms (e.g. MacOSX). Here all the necessary files should exist in "BSF4ooRexx.dev/source_cc/";
plus a setup to point to the JDK-include directory (for resolving the JNI datatype definitions for
your platform).
---
Inline comments for your questions/observations:
Uli Zinngrebe wrote:
> Hi there,
>
> if you compile BSF4ooRexx from sources, you maybe have some comments.
>
> I use the script compile_all.cmd (from BSF4ooRexx_sources.zip) as a
> blueprint and encounter:
> 1) External dependencies to other packages:
> I put into archive at top level:
Great!
> junit 3.8.2 :
> http://sourceforge.net/projects/junit/files/junit/
Though, could be foregone as BSF has a fallback class in the case that junit is not available (one
cannot expect that client installations would have junit available).
> asm-util and asm-tree : svn checkout
> svn://svn.forge.objectweb.org/svnroot/asm/trunk/asm/src/org/objectweb/asm/tree
> svn://svn.forge.objectweb.org/svnroot/asm/trunk/asm/src/org/objectweb/asm/util
Great!
---
All of these are only needed, if you wish to recompile BSF itself (as then the various script
engines get created as well):
> There are a few more dependencies (probably optional):
> Tcl, jython, netrexx, xslt and a some com.sun.star.* packages
> I don't see where xalan would be necessary.
Oh, there is a BSF engine ("XSLTEngine") for it (and examples supplied that take advantage of this
engine, cf. "samples/apache_bsf_samples/xsl"), actually cool stuff as one can take advantage of this
script engine from Rexx as well (as is possible with all the other script languages).
> 2) One source file (RexxAndJava) uses strange character encoding (for
> non-English characters).
> Probably this isn't related to java; I edited the few instances by hand.
> I'm concerned that there may be wrong encodings that the compiler doesn't
> complain about.
>
> org/rexxla/bsf/engines/rexx/RexxAndJava.java:3605: warning: unmappable
> character for encoding UTF8
> // "\n\t[a-�-o-�-u-�-A-�-O-�-U-�-sz-�]\t\n"+
> ^
> org/rexxla/bsf/engines/rexx/RexxAndJava.java:4519: warning: unmappable
> character for encoding UTF8
> "Jansen, Ren�" + "\n" +
> ^
Beware!
;)
This is a classic character encoding problem. It depends on your editor and the encoding of the text
files it assumes. Maybe the correct solution for this would be to use the Unicode code-points for
these non-US-chars (e.g. cf. <http://java.sun.com/docs/books/tutorial/i18n/text/convertintro.html>).
Note: [oo]Rexx should support Unicode, natively. On Unix-based systems UTF-8 encoded text files
become more and more the norm (the shells process by default Unicode chars), the same can be seen on
Windows.
[It seems that native English-speaking developers do not realize at all, how important native
Unicode is for Rexx!]
> 3) One source file (TestFile) has an unreported exception
>
> +
> javac -cp /usr/lib64/jvm/java:/usr/lib64/jvm/java/bin:/usr/share/java:. -source
> 1.4 -target 1.4 org/oorexx/misc/RgfFilter.java
> org/oorexx/misc/TestFile.java org/oorexx/misc/Test.java
> org/oorexx/misc/TestFile.java:30: unreported exception
> java.net.URISyntaxException; must be caught or declared to be thrown
> super(new URI("oha")); // this works, no super() injected by
> compiler: defines throwing java.net.URISyntaxException
> ^
> 1 error
> error: Bad exit status from /home/uli/packages/tmp/rpm-tmp.39415 (%build)
That is quite strange as the class TestFile reports that it throews "java.net.URISyntaxException"!
> 4) bin/JavaInfo4BSF4RexxInstallation.java is in directory BSF4ooRexx.dev.
Yes, that is correct.
> 5) There are a few warnings about depreciation - nothing serious probably.
>
> +
> javac -cp /usr/lib64/jvm/java:/usr/lib64/jvm/java/bin:/usr/share/java:.:/usr/share/java/junit -source
> 1.4 -target 1.4 -Xlint:deprecation
> org/apache/bsf/test/BSFEngineTestTmpl.java org/apache/bsf/test/BSFTest.java
> org/apache/bsf/test/fakeEngine.java
> ./junit/runner/BaseTestRunner.java:60: warning: [deprecation]
> save(java.io.OutputStream,java.lang.String) in java.util.Properties has
> been deprecated
> getPreferences().save(fos, "");
The warnings are o.k.
Regards,
---rony
ML
>> [It seems that native English-speaking developers do not realize
>> at all, how important native Unicode is for Rexx!]
Who cares? Unicode is rated 'important for Rexx', but ObjectRexx isn't
Rexx and doesn't really care about Rexx in general at all. ObjectRexx
is perhaps the worst thing that happened to Rexx. Realize it? Perhaps.
Care about it? No. Moving on...
> simply don't have the resources to deal with it.
Then don't attempt to write a Rexx interpreter, missing parts that are
rated to be 'important'. I'm not sure native Unicode is important, but
a claim of being volunteers hardly matches with programming languages.
That just requires a certain level, e.g. not breaking stuff. Part of
the problem. The simplicity of (O)Rexx is a great way to hide a lack
of skill, and there aren't that many well-known Rexx applications. I
cannot mention one historical one. In a way it's a paradox, needing
skilled people who use(d) Rexx as their tool.
> [1] OOREXX also has objects, and I would expect Unicode support to
> take advantage of that.
Sure. But 'OOREXX' isn't 'Rexx'. C++ also has objects. And an 'if'. ;-)
---