> > Am 09.07.2022 um 06:31 schrieb David Crayford <dcrayf...@gmail.com>: > > On 8/07/2022 7:43 pm, Rony G. Flatscher wrote: >>> On 08.07.2022 03:38, David Crayford wrote: >>> On 7/07/2022 7:53 pm, Rony G. Flatscher wrote: >>>>> When I select a language for a job, one of the things that I look at is >>>>> the ecosystem. I prefer ooRexx to Perl, but I find myself using >>>>> Perl for some tasks because CPAN is an awesome resource. Python may not >>>>> be the best language for the task at hand, but it pays to check what >>>>> packages are available. >>>> >>>> Indeed Perl and Python have a great wealth of libraries available to them. >>>> >>>> There is one ecosystem that beats Perl, Python and practically any others: >>>> Java >>> >>> According to http://www.modulecounts.com/ which shows the number of unique >>> packages >> >> Methodology: "... Data is collected /by scraping the relevant websites /once >> a day via a cron job and then stored in a Postgresql database for later >> retrieval. Growth rates are calculated by averaging data over the last week. >> I'm gathering counts of separate modules, so multiple versions of the same >> module/package/gem only count once (foo-1.2, foo-1.3 and bar-1.0 would count >> as 2 total). ..." >> >> Questioning the methodology, completeness, correctness and as a result the >> relevance. Did not find any checkbox for Java there hence wondering where >> your Java figures come from. > > It gets the Java figures from Maven Central https://search.maven.org/stats. > There is no denying that Java has an gigantic eco-system. And a hell of a lot > of it is top notch. The product I'm currently working on wouldn't exist > without Java open source. > > >> >>> Node.js 2019534 >>> Java 483102 >>> Python 386118 >>> Perl 18354 >>> >>> So the undisputed winner as far as ecosystem is JavaScript. >> >> This may be more an indication that there are many shortcomings and many >> packages by different authors that try to make the same needed >> functionalities available. >> >> ... cut ... >> >> Ad Java: JRE comes already with a wealth of packages on board that are >> add-ons in other languages. > > The gripe I have is that what comes with the JRE is typically not as good as > open source. For example, JDK 11 finally included a half decent HttpClient > but it doesn't support anyway near the feature set of open source clients > such as OkHttp or Jetty > https://www.mocklab.io/blog/which-java-http-client-should-i-use-in-2020/. To > my knowledge there is still no support for JSON or Yaml even in JDK 18. There are Java libraries for it.
Ad Java evolution, maintenance, here a nice overview: https://en.wikipedia.org/wiki/Java_version_history, covering Java 1 through 19 and giving a brief outlook (there would be more on the openjdk.org homepage, look for the JEP - Java enhancement proposals - projects for Java). >> >> In addition, almost all important business applications have Java APIs such >> that one can regard such applications as additional Java packages (e.g. >> OpenOffice/LibreOffice mainly implemented in C++ gained Java APIs and the >> ability to implement modules in Java; one result is the creation of a Java >> scripting framework for OpenOffice/LibreOffice which allows any language for >> which a javax.script implementation exists to be used as a scripting and >> macro language; one example for this comes with BSF4ooRexx). >> >> Or think of the JDBC packages of the different database vendors, or ... >> >>> I just downloaded vsam.js to process a VSAM data set in Node on z/OS and it >>> works well. IBM are certainly giving >>> Node more love then REXX which will never officially support VSAM. >> >> Indeed this is strange that IBM does not support REXX the same as other >> technologies. > > IBM also provide a VSAM I/O module for Go > https://github.com/ibmruntimes/go-recordio. > > >> >> Has that possibly to do (wild guess) that the developers do not know how to >> create REXX APIs on the mainframe? As probably C++ has a role here, then >> probably CMake based ooRexx 5 with its C++ APIs would make the creation of >> external ooRexx function libraries quite simple on the mainframe as well >> (judging from the existence of "z/OS XL C/C++ Library Reference SA22-7821" >> and "z/OS XL C/C++ Programming Guide SC09-4765"). > > The REXX programming services on z/OS are built for assembler. Bridging to > C/C++ can be done. I have code to do that but it's tricky. Porting ooRexx to > z/OS is very difficult. I actually managed to build it around 2008. If you > look in the oorexx-devel archives you will se conversations between myself > and Rick McGuire. There is a lot of weird pthread stuff intertwined with > message passing that made it unsuitable for running in an ISPF environment. I > put it in the too-hard basket and a a couple of years later discovered Lua > which was simple to port and unbelievably effecient. Several orders of > magnitude faster than TSO REXX. 2008 is 14 years ago, in the Internet age almost more than 100 years ago! The world has revolved quite a few times since then… ;) Seriously, you have probably ported ooRexx 3.x which contained the original IBM kernel, Rick McGuire rewrote the entire kernel for ooRexx and among many other things added a great new native API to ooRexx (the REXXSAA interface is basically string based with stem support, the native API is fully object-oriented). With this new kernel development has changed dramatically, e.g. for the first time it became possible to create a 64-bit version of ooRexx from the same code that was used to create the 32-bit version (this was not possible before that). This rewriting of the kernel allowed also for easying the porting of ooRexx to so many platforms that you can witness today. The kernel of ooRexx 5.0 got reshaped and improved in many aspects, the native APIs got enhanced accordingly. As ooRexx 5.0 is CMake based one could probably port it today as easily as maybe Lua. One thing that has become incredible easy with the new kernel is writing C++ code for creating external ooRexx function (callable as functions and procedures) and ooRexx method (using them as ooRexx methods) libraries. On the native side it is even possible to have the CSelf maintained with its peer OSelf: this makes it easy to have e.g. a C++ object stored in an ooRexx object and access it easily on the native side. There are samples distributed with ooRexx that demonstrate how to create and use such external function and method libraries. If you look them up you would be immediately able to write external function libraries for any new environment, e.g. allowing to access the ZFile library from ooRexx using the C++ external function or method library. This way it would become possible to quickly create a few important, target related external function and/or method libraries to experiment with. It would also be easy to create ooRexx classes (like the Java classes) that define access to e.g. ZFile functions/methods as plain ooRexx methods. In addition, being Rexx after all, one could use the command interface to implement any command environment in C++ (if you have BSF4ooRexx you can even do that in pure Java!). In ooRexx 5.0 one even gains the possibility of redirected commands (ANSI, one can redirect stdin, stdout and stderr from/to ooRexx stems or collections). Then, if you have the functionality to bridge to the REXX assembler interfaces, you would be able to make that infrastructure available through ooRexx. This does not sound bad, does it? :) >> But then, if ooRexx and BSF4ooRexx were there (and they are available in the >> Linux subsystem), then one can use ooRexx to exploit com.ibm.jzos.ZFile >> (there seem to be samples on the Internet that demonstrate using it >> <https://www.ibm.com/docs/en/sdk-java-technology/7?topic=SSYKE2_7.0.0/com.ibm.java.zsecurity.api.70.doc/com.ibm.jzos/com/ibm/jzos/sample/vsam/file/package-summary.html>). > > The first requirement from users on this list would be to run ooRexx from > TSO. The vast majority of z/OS folks don't know how to use a shell. I was > speaking to one of our ported tools devs a couple of weeks ago and he told me > that a lot of folks are invoke our Git port from TSO using bpxwunix() in > REXX. This is a dangerously close to undefined behavior. Git needs to be run > using Rockets bash for file encoding conversion to work predictably. > Using the redirected command environment of ooRexx it would be possible for such users to use stdin, stdout and stderr without any shell knowledge. They merely would use „ADDRESS SYSTEM some_command WITH OUTPUT stem out. ERROR stem err.“. You get the idea… —-rony Rony G. Flatscher (mobil/e) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
