Re: Java (Re: Some questions on SYSCALL

[Rony G. Flatscher]

Sorry for the late and brief comments (currently a little bit in 
"land-under-water" mode).

On 11.07.2022 10:42, David Crayford wrote:

On 10/07/2022 6:49 pm, Rony wrote:

  Am 09.07.2022 um 03:15 schrieb David Crayford :

On 8/07/2022 7:17 pm, Rony G. Flatscher wrote:

On 07.07.2022 17:45, David Crayford wrote:
On 7/07/2022 7:53 pm, Rony G. Flatscher wrote:

On 06.07.2022 11:03, Seymour J Metz wrote:

... cut ...
There is one ecosystem that beats Perl, Python and practically any others: Java. For every 
problem domain, for new emerging technologies there are Java class libraries which one can 
take advantage of. As Java classes get compiled to intermediate byte code, these Java class 
libraries can be deployed and used immediately on any hardware and any operating system for 
which a Java virtual machine exists.
That's debatable! I'm a full time Java programmer in the last few years and I like. We use 
Spring Boot which is a high quality framework that makes it pleasant to use. I would use SB 
even for a slightly complex command line interface. However, the build systems are a bit 
spotty compared to Node.js, Python etc.

Eclipse, NetBeans, IntelliJ, ...
I build Java in IntelliJ using Maven. Also, we use a DevOps pipeline driven by Jenkins so using 
an IDE is out of the question.




Maven is creaking with it's ugly XML pom.xml and

Beauty lies in the eyes of the beholder ...

Maven is not Java and still an incredible boon!
I agree. I just don't like XML. I would rather use Gradle with it's nice Groovy DSL where I can 
drop down and write code for tricky configurations.




Gradle doesn't work very well on some systems.

What does not work for you?

Would you think that the Java multiplatform build system which is done with Gradle would be 
possible, if that were true what you say?
Gradle doesn't work properly on z/OS. First thing I tried was to nobble spawning the daemon. I 
used AOT -Xshareclasses so start up times were not a problem. However, Gradle was downloading 
lots of unwanted dependencies and filled up the file system cache. I abandoned it and stuck to 
Maven.




C# is a far better language then Java.

Excuse me? 

Off the top of my header.

1. Generics done properly with reflection support, not puny type erasure.
Java retains generics information in byte code (for the compiler) after type erasure (such that 
the runtime does not have to recheck after compilation, after all the compiler checked already).



2. No checked exceptions
One can use no checked exceptions in Java if one wished. OTOH checked exceptions are there and 
one can take advantage of them.


The JRE uses checked exceptions so you can't avoid them. The damage is done. The mess created by 
checked exceptions became more evident when Java 8 introduced Lambda's. There is nothing more ugly 
than a try/catch block in a lambda function. Some people create wrappers but that's just bloat. 
Checked exceptions are widely considered a failed experiment.


This is a very narrow view at the concept of checked exceptions (claiming it to be a "failed 
experiment" is like claiming "coke is a failed experiment", because you prefer water ;) ) and does 
not assess the benefits and misbenefits of exceptions per se, let alone of checked vs. unchecked 
exceptions (there is a good reason why checked exceptions got introduced, such that the compiler can 
detect improper usage of checked exceptions). Having seen quite a lot of Java code exploiting lambda 
functions, I have not really noticed lambda functions that would have to apply a try/catch blocks 
(will from now on look out for it). But even so, if it needs to be stated, so be it, not a problem 
at all.







3. Unsigned integer types

Not really a problem.


It's a problem for our products. We process a lot of unsigned 64-bit integers and perform 
arithmetic such as division and a BigInteger is not acceptable for performance reasons. James 
Gosling admitted that Java didn't implemented unsigned integers as he wanted to keep the language 
simple for new programmers. That's another historical mistake that we are paying the price off. 
Back then Java was designed for very different use cases. Writing cryptographic algorithms in Java 
without an unsigned Long is painful. Gosling's nanny state hand holding hasn't aged well. He 
didn't implement operator overloading because he didn't like the way it was used for iostreams in 
C++. Another BIG mistake that makes the language awkward to use when doing arithmetic on 
BigDecimal, BigInteger types.


BTW, the very existence of Long.divideUnsigned() is proof enough that Java needs unsigned 
integers. In JDK16 they have optimized the function to use an algorithm from Hackers Delight that 
uses twos-complement binary operators. It's a shame we're stuck on JDK8 and the JDK16 code uses an 
unfriendly license for IBM code.


The license is GPL 2 with the classpath exception , also 
seeing from time to time IBM 

Re: Java (Re: Some questions on SYSCALL

[David Crayford]

On 10/07/2022 6:49 pm, Rony wrote:
  
Am 09.07.2022 um 03:15 schrieb David Crayford :

On 8/07/2022 7:17 pm, Rony G. Flatscher wrote:

On 07.07.2022 17:45, David Crayford wrote:
On 7/07/2022 7:53 pm, Rony G. Flatscher wrote:

On 06.07.2022 11:03, Seymour J Metz wrote:

... cut ...

There is one ecosystem that beats Perl, Python and practically any others: 
Java. For every problem domain, for new emerging technologies there are Java 
class libraries which one can take advantage of. As Java classes get compiled 
to intermediate byte code, these Java class libraries can be deployed and used 
immediately on any hardware and any operating system for which a Java virtual 
machine exists.

That's debatable! I'm a full time Java programmer in the last few years and I 
like. We use Spring Boot which is a high quality framework that makes it 
pleasant to use. I would use SB even for a slightly complex command line 
interface. However, the build systems are a bit spotty compared to Node.js, 
Python etc.

Eclipse, NetBeans, IntelliJ, ...

I build Java in IntelliJ using Maven. Also, we use a DevOps pipeline driven by 
Jenkins so using an IDE is out of the question.



Maven is creaking with it's ugly XML pom.xml and

Beauty lies in the eyes of the beholder ...

Maven is not Java and still an incredible boon!

I agree. I just don't like XML. I would rather use Gradle with it's nice Groovy 
DSL where I can drop down and write code for tricky configurations.



Gradle doesn't work very well on some systems.

What does not work for you?

Would you think that the Java multiplatform build system which is done with 
Gradle would be possible, if that were true what you say?

Gradle doesn't work properly on z/OS. First thing I tried was to nobble 
spawning the daemon. I used AOT -Xshareclasses so start up times were not a 
problem. However, Gradle was downloading lots of unwanted dependencies and 
filled up the file system cache. I abandoned it and stuck to Maven.



C# is a far better language then Java.

Excuse me? 

Off the top of my header.

1. Generics done properly with reflection support, not puny type erasure.

Java retains generics information in byte code (for the compiler) after type 
erasure (such that the runtime does not have to recheck after compilation, 
after all the compiler checked already).


2. No checked exceptions

One can use no checked exceptions in Java if one wished. OTOH checked 
exceptions are there and one can take advantage of them.


The JRE uses checked exceptions so you can't avoid them. The damage is 
done. The mess created by checked exceptions became more evident when 
Java 8 introduced Lambda's. There is nothing more ugly than a try/catch 
block in a lambda function. Some people create wrappers but that's just 
bloat. Checked exceptions are widely considered a failed experiment.






3. Unsigned integer types

Not really a problem.


It's a problem for our products. We process a lot of unsigned 64-bit 
integers and perform arithmetic such as division and a BigInteger is not 
acceptable for performance reasons. James Gosling admitted that Java 
didn't implemented unsigned integers as he wanted to keep the language 
simple for new programmers. That's another historical mistake that we 
are paying the price off. Back then Java was designed for very different 
use cases. Writing cryptographic algorithms in Java without an unsigned 
Long is painful. Gosling's nanny state hand holding hasn't aged well. He 
didn't implement operator overloading because he didn't like the way it 
was used for iostreams in C++. Another BIG mistake that makes the 
language awkward to use when doing arithmetic on BigDecimal, BigInteger 
types.


BTW, the very existence of Long.divideUnsigned() is proof enough that 
Java needs unsigned integers. In JDK16 they have optimized the function 
to use an algorithm from Hackers Delight that uses twos-complement 
binary operators. It's a shame we're stuck on JDK8 and the JDK16 code 
uses an unfriendly license for IBM code.




4. Value types

Not really a problem.


Maybe not for you. It's my understanding that you're an educator that 
teaches stuff like OLE and Windows GUI programming using JavaFX. The 
products I work on are back-end systems that process missions of records 
that originate from z/OS data sources. We need to serialize those binary 
records to other formats such as JSON as efficiently as possible. C# has 
struct value types and pointers (unsafe blocks) which would be brilliant 
for this kind of work. IBM realizes this and have implemented 
PackedObjects in their JDK which use intrinsics. Very similar to structs 
and value types in C#. Shame it's not portable!


https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=poet-packed-objects-2





5. Better support for functional program, LINQ

How so, which bytecodes do you think of?


I'm talking about FP and LINQ which is C# DSL for functional programming 
which looks a bit like SQL.

Re: Java (Re: Some questions on SYSCALL

[Rony]

> 
> Am 09.07.2022 um 06:31 schrieb David Crayford :
> 
> 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. 

Re: Java (Re: Some questions on SYSCALL

[Rony]

 
Am 09.07.2022 um 03:15 schrieb David Crayford :
> 
> On 8/07/2022 7:17 pm, Rony G. Flatscher wrote:
>>> On 07.07.2022 17:45, David Crayford wrote:
>>> On 7/07/2022 7:53 pm, Rony G. Flatscher wrote:
 On 06.07.2022 11:03, Seymour J Metz wrote:
>> ... cut ...
 
 There is one ecosystem that beats Perl, Python and practically any others: 
 Java. For every problem domain, for new emerging technologies there are 
 Java class libraries which one can take advantage of. As Java classes get 
 compiled to intermediate byte code, these Java class libraries can be 
 deployed and used immediately on any hardware and any operating system for 
 which a Java virtual machine exists.
>>> 
>>> That's debatable! I'm a full time Java programmer in the last few years and 
>>> I like. We use Spring Boot which is a high quality framework that makes it 
>>> pleasant to use. I would use SB even for a slightly complex command line 
>>> interface. However, the build systems are a bit spotty compared to Node.js, 
>>> Python etc. 
>> Eclipse, NetBeans, IntelliJ, ...
> 
> I build Java in IntelliJ using Maven. Also, we use a DevOps pipeline driven 
> by Jenkins so using an IDE is out of the question.
> 
> 
>>> Maven is creaking with it's ugly XML pom.xml and
>> 
>> Beauty lies in the eyes of the beholder ...
>> 
>> Maven is not Java and still an incredible boon!
> 
> I agree. I just don't like XML. I would rather use Gradle with it's nice 
> Groovy DSL where I can drop down and write code for tricky configurations.
> 
> 
>> 
>>> Gradle doesn't work very well on some systems.
>> 
>> What does not work for you?
>> 
>> Would you think that the Java multiplatform build system which is done with 
>> Gradle would be possible, if that were true what you say?
> 
> Gradle doesn't work properly on z/OS. First thing I tried was to nobble 
> spawning the daemon. I used AOT -Xshareclasses so start up times were not a 
> problem. However, Gradle was downloading lots of unwanted dependencies and 
> filled up the file system cache. I abandoned it and stuck to Maven.
> 
> 
>> 
>>> C# is a far better language then Java. 
>> 
>> Excuse me? 
> 
> Off the top of my header.
> 
> 1. Generics done properly with reflection support, not puny type erasure.
Java retains generics information in byte code (for the compiler) after type 
erasure (such that the runtime does not have to recheck after compilation, 
after all the compiler checked already).

> 2. No checked exceptions
One can use no checked exceptions in Java if one wished. OTOH checked 
exceptions are there and one can take advantage of them.

> 3. Unsigned integer types
Not really a problem.

> 4. Value types
Not really a problem.

> 5. Better support for functional program, LINQ
How so, which bytecodes do you think of?

> 6. Better enumeration support, with the yield|| statement
Hmm? Actually I would be interested about what you are missing in Java‘s enum 
support.

> I could go on. I don't use C# but I spent a weekend learning it and it's a 
> great language. Kotlin has similar features but is crippled by the JVM. For 
> example, there is no byte code support for unsigned integers.
There is also no real need for it (and if really needed for conversions there 
are the appropriate methods defined in the wrapper classes). 

> 
>> Kotlin meets 95% of the requirements but we dismissed it because it's not 
>> mainstream so we're stuck with Java.
Kotlin is by JetBrains (makers of IntelliJ), Google endorsing it for having a 
Java alternative for creating Android applications. 

„Stuck“ is not really true: Kotlin compiles to Java bytecode which you can use 
as if that bytecode was created by a Java compiler.

The same holds for NetRexx programs: they get transpiled to Java source code 
(you can save that code and inspect it vis-a-vis your NetRexx source code) 
which then gets compiled to Java byte code. The resulting compiled NetRexx 
program in form of the Java bytecode can be used as if it was created by the 
Java compiler (which it did :) ).

>> 
>> Poor you! ;)
>> (You got stuck in one of the most up-to-date and maintained languages and 
>> environments that sets you free from being locked-in in a specific platform.)
>> 
> I use Java every day. I'm happy to use it. But I disagree that it's on of the 
> most up-to-date languages. There differences between Java 8 and Java 16 are 
> so insignificant it's worth upgrading.
> 
> 
>> 
>>> Yes. But you need to use Open Source libraries for it to be easy to use. 
>>> The JRE doesn't cut it.
>> 
>> Hmm?
>> 
>> The JRE includes a wealth of functionality, a wealth of packages that in 
>> other languages are only available as add-ons.
>> 
> However, we still need libraries such as Google Guava, Apache Commons, Lombok 
> to plug the gaps.
> 
> 
>>> 
 
 Seeing the OpenJDK (open-source Java) community and how vigorously Java 
 gets developed further, continually updated in critical areas like 
 security, there is no end in 

Re: Java (Re: Some questions on SYSCALL

[David Crayford]

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.





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.




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 
).


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 

Re: BSF? [was: RE: Java (Re: Some questions on SYSCALL)]

[CM Poncelet]

"TSO/E Version 2 Procedures Language MVS/REXX, SC28-1883-1"
 
"Stop disingenuously picking on him." Is that so?
 
The "SYSCALL" in REXX is an ADDRESS SYSCALL under the covers - similar
to ADDRESS IPCS/MVS/TSO/ISREDIT or whatever other else. It is the
"ADDRESS" that belongs in REXX. "SYSCALL" is a CLIST
instruction/directive/function/command/call/enhancement/enterprise/whatever-else,
as per the example I gave of using it.
 
What matters is what SYSCALL does and how it does it - not what it is
called
(instruction/directive/function/command/call/enhancement/enterprise or
whatever-else waffle.)
 
Pardon me, but I am merely a retired systems programming consultant who
did not graduate to hifalutin systems poetry.
 
BTW The spelling "Rexx" applies to non-IBM versions (including Mike
Cowlishaw's.) In IBM's spelling, it is "REXX" (from "Restructed EXtended
eXecutor.")
  
HTH
 

On 08/07/2022 03:12, Paul Gilmartin wrote:
> On Fri, 8 Jul 2022 02:38:38 +0100, CM Poncelet wrote:
>
>> Without meaning to bump into what might be off topic, SYSCALL is
>> actually a CLIST instruction - not a REXX one (unless it's a case of
>> "nous avons changé tout ça")
>>    
> When Charles started this thread on June 28, he made it clear that he
> was discussing Rexx, despite a couple naive errors.  Stop disingenuously
> picking on him.
>
> SYSCALL belongs in Rexx, where it is not an instruction but a
> command environment.
> GIYF: 
> .
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Java (Re: Some questions on SYSCALL

[David Crayford]

On 8/07/2022 7:17 pm, Rony G. Flatscher wrote:

On 07.07.2022 17:45, David Crayford wrote:

On 7/07/2022 7:53 pm, Rony G. Flatscher wrote:

On 06.07.2022 11:03, Seymour J Metz wrote:

... cut ...


There is one ecosystem that beats Perl, Python and practically any 
others: Java. For every problem domain, for new emerging 
technologies there are Java class libraries which one can take 
advantage of. As Java classes get compiled to intermediate byte 
code, these Java class libraries can be deployed and used 
immediately on any hardware and any operating system for which a 
Java virtual machine exists.


That's debatable! I'm a full time Java programmer in the last few 
years and I like. We use Spring Boot which is a high quality 
framework that makes it pleasant to use. I would use SB even for a 
slightly complex command line interface. However, the build systems 
are a bit spotty compared to Node.js, Python etc. 

Eclipse, NetBeans, IntelliJ, ...


I build Java in IntelliJ using Maven. Also, we use a DevOps pipeline 
driven by Jenkins so using an IDE is out of the question.




Maven is creaking with it's ugly XML pom.xml and


Beauty lies in the eyes of the beholder ...

Maven is not Java and still an incredible boon!


I agree. I just don't like XML. I would rather use Gradle with it's nice 
Groovy DSL where I can drop down and write code for tricky configurations.






Gradle doesn't work very well on some systems.


What does not work for you?

Would you think that the Java multiplatform build system which is done 
with Gradle would be possible, if that were true what you say?


Gradle doesn't work properly on z/OS. First thing I tried was to nobble 
spawning the daemon. I used AOT -Xshareclasses so start up times were 
not a problem. However, Gradle was downloading lots of unwanted 
dependencies and filled up the file system cache. I abandoned it and 
stuck to Maven.





C# is a far better language then Java. 


Excuse me? 


Off the top of my header.

1. Generics done properly with reflection support, not puny type erasure.
2. No checked exceptions
3. Unsigned integer types
4. Value types
5. Better support for functional program, LINQ
6. Better enumeration support, with the yield|| statement

I could go on. I don't use C# but I spent a weekend learning it and it's 
a great language. Kotlin has similar features but is crippled by the 
JVM. For example, there is no byte code support for unsigned integers.



Kotlin meets 95% of the requirements but we dismissed it because it's 
not mainstream so we're stuck with Java.


Poor you! ;)
(You got stuck in one of the most up-to-date and maintained languages 
and environments that sets you free from being locked-in in a specific 
platform.)


I use Java every day. I'm happy to use it. But I disagree that it's on 
of the most up-to-date languages. There differences between Java 8 and 
Java 16 are so insignificant it's worth upgrading.





Yes. But you need to use Open Source libraries for it to be easy to 
use. The JRE doesn't cut it.


Hmm?

The JRE includes a wealth of functionality, a wealth of packages that 
in other languages are only available as add-ons.


However, we still need libraries such as Google Guava, Apache Commons, 
Lombok to plug the gaps.







Seeing the OpenJDK (open-source Java) community and how vigorously 
Java gets developed further, continually updated in critical areas 
like security, there is no end in sight for this great ecosystem. 
Witnessing also OpenJDK distributions (from Java 8 LTS to the latest 
Java 18) from IBM, Amazon, SAP, even Microsoft, and many, many more 
competent and leading IT-related companies, the support for Java is 
unique compared to any other software there is. 


One of the reasons for the surge in C++ is because Java is flabby. 


Flabby? 
ROTFL


I stand by my comment. It doesn't mean I dislike Java. I like it a lot.




It's uses a huge amount of memory and GC is costly in visualized 
environments. 


That is just not true as many of the other statements. You seem to not 
really have followed the huge work and improvements over the decades 
and the state.


Yes it is. I work on z/OS performance monitoring products. One of our 
monitors is for the z/OS JVM. I see the metrics every day. The JVM 
starts about 8 threads. 2 for JIT, 3 for GC, 3 for OMR and some others I 
can't remember. It will do that even if you run a hello world program. 
Some of our products are written
in Java and we have to write documentation on how to tune the heap so GC 
cycles don't go crazy. Memory requirements for Java is eye watering 
compared to native code. The equivalent product written in C++ would use 
a fraction of the resources. One of the big plus point for Java on z/OS 
is that it runs on zIIP processors.


We use Spring Boot and are keeping an eye on Spring Boot Native which 
compiles to native code using GraalVM. As containers become the dominant 
deployment environment this will make a big difference for Java 

Re: Java (Re: Some questions on SYSCALL

[Rony G. Flatscher]

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.



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.

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.

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").


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 
).


---rony


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Java (Re: Some questions on SYSCALL

[Rony G. Flatscher]

On 07.07.2022 17:45, David Crayford wrote:

On 7/07/2022 7:53 pm, Rony G. Flatscher wrote:

On 06.07.2022 11:03, Seymour J Metz wrote:

... cut ...


There is one ecosystem that beats Perl, Python and practically any others: Java. For every 
problem domain, for new emerging technologies there are Java class libraries which one can take 
advantage of. As Java classes get compiled to intermediate byte code, these Java class libraries 
can be deployed and used immediately on any hardware and any operating system for which a Java 
virtual machine exists.


That's debatable! I'm a full time Java programmer in the last few years and I like. We use Spring 
Boot which is a high quality framework that makes it pleasant to use. I would use SB even for a 
slightly complex command line interface. However, the build systems are a bit spotty compared to 
Node.js, Python etc. 

Eclipse, NetBeans, IntelliJ, ...

Maven is creaking with it's ugly XML pom.xml and


Beauty lies in the eyes of the beholder ...

Maven is not Java and still an incredible boon!


Gradle doesn't work very well on some systems.


What does not work for you?

Would you think that the Java multiplatform build system which is done with Gradle would be 
possible, if that were true what you say?


C# is a far better language then Java. 


Excuse me? 

When Microsoft lost their lawsuit against Sun about not adhering to the signed Java license 
(remember J#?) which stated among other things that Microsoft was not allowed to create Java classes 
such that they become dependent on the Microsoft operating system (a lock-in strategy and attempting 
to harm Java's "write once, run anywhere" goal), Microsoft started with an alternative to Java and 
eventually came up with .Net/CLR and C# (later F#, VB.Net and the like).


I don't use it because I because I'm not a Windows guy but I look on in envy. 


If you were to do that for no obvious reasons other that you personally "like it", it would be a 
move to get into a Microsoft lock-in without a need.


Java has been the break-free-from-lock-ins alternative for decades. Java allows you to run your 
applications on Windows, but also on MacOS or Linux or ...



Kotlin meets 95% of the requirements but we dismissed it because it's not mainstream so we're 
stuck with Java.


Poor you! ;)
(You got stuck in one of the most up-to-date and maintained languages and environments that sets you 
free from being locked-in in a specific platform.)



I was surprised to notice when I followed Timothy's link to the TIOBE index that C++ is about to 
leapfrog Java. https://www.tiobe.com/tiobe-index/.  The article cites rapid standard rollouts and 
ground breaking new features such as co-routines. As a Lua fan I can't for C++ co-routines. On 
TIOBE Lua has raced back into the top 20 which is due to the surging popularity of gaming 
frameworks such as Roblox.


So you follow the mainstream and when the set of currently reported popular languages changes, you 
change the language because of it and bad-mouth any other language?


You do not choose the language depending on the problem and 
environment/infrastructure at hand to solve?

... cut ...





The Java runtime environment (JRE) already comes with a wealth of professional and tested class 
libraries covering practically all aspects of modern programming, covering everything that any 
modern application may have a need to exploit and interact with.


Yes. But you need to use Open Source libraries for it to be easy to use. The 
JRE doesn't cut it.


Hmm?

The JRE includes a wealth of functionality, a wealth of packages that in other languages are only 
available as add-ons.






Seeing the OpenJDK (open-source Java) community and how vigorously Java gets developed further, 
continually updated in critical areas like security, there is no end in sight for this great 
ecosystem. Witnessing also OpenJDK distributions (from Java 8 LTS to the latest Java 18) from 
IBM, Amazon, SAP, even Microsoft, and many, many more competent and leading IT-related companies, 
the support for Java is unique compared to any other software there is. 


One of the reasons for the surge in C++ is because Java is flabby. 


Flabby? 
ROTFL


It's uses a huge amount of memory and GC is costly in visualized environments. 


That is just not true as many of the other statements. You seem to not really have followed the huge 
work and improvements over the decades and the state.


(Though your statement may be true for C# and .Net/CLR. ;) )

GraalVM is a valiant attempt to solve that problem. 


Nope. The scope is different and interesting (trying to have a common interface standard for 
various, specific languages among them C and C++, which you might faultily take as a weak sign of C 
and C++?).


Anyway, your statements at times seem to be directed ad bad mouthing technologies even if they are 
unsubstantiated, maybe for igniting flames or creating false - emotional - impressions? In any case 

Re: BSF? [was: RE: Java (Re: Some questions on SYSCALL)]

[Paul Gilmartin]

On Fri, 8 Jul 2022 02:38:38 +0100, CM Poncelet wrote:

>Without meaning to bump into what might be off topic, SYSCALL is
>actually a CLIST instruction - not a REXX one (unless it's a case of
>"nous avons changé tout ça")
>   
When Charles started this thread on June 28, he made it clear that he
was discussing Rexx, despite a couple naive errors.  Stop disingenuously
picking on him.

SYSCALL belongs in Rexx, where it is not an instruction but a
command environment.
GIYF: 
.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Java (Re: Some questions on SYSCALL

[David Crayford]

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


Node.js   2019534
Java       483102
Python  386118
Perl      18354

So the undisputed winner as far as ecosystem is JavaScript. And it's 
growing the fastest. 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.

https://www.npmjs.com/package/vsam.js?S_TACT=


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BSF? [was: RE: Java (Re: Some questions on SYSCALL)]

[CM Poncelet]

Without meaning to bump into what might be off topic, SYSCALL is
actually a CLIST instruction - not a REXX one (unless it's a case of
"nous avons changé tout ça")
 
E.g.
HELP_SELECT: +
 SELECT ()
   WHEN (UP) DO
 SET HPAN =  - 1
 *SYSCALL* MAXV HPAN HELPTOP
 ENDO
   WHEN (DOWN) DO
 SET HPAN =  + 1
 *SYSCALL* MINV HPAN HELPBOT
 ENDO
   OTHERWISE
   ENDO HELP_SELECT
 ISPEXEC DISPLAY PANEL(HELPANL)
 ENDO
<...>
/*---*/
/* SUB-PROCEDURE MINV    */
/*---*/
MINV: +
  PROC 0 +
    HPAN HELPBOT
  CONTROL END(ENDO)
  SYSREF +
    HPAN HELPBOT
  IF () > () THEN +
    SET HPAN = 
  ELSE
  RETURN
  ENDO MINV
/*---*/
/* SUB-PROCEDURE MAXV    */
/*---*/
MAXV: +
  PROC 0 +
    HPAN HELPTOP
  CONTROL END(ENDO)
  SYSREF +
    HPAN HELPTOP
  IF () < () THEN +
    SET HPAN = 
  ELSE
  RETURN
  ENDO MAXV
 


On 07/07/2022 19:01, Paul Gilmartin wrote:
> (This thread should move to comp.lang.advocacy.)
>
> On Thu, 7 Jul 2022 16:40:08 +, Farley, Peter x23353 wrote:
>
>> OK, I'll bite: What is BSF please?  I do know of PCRE (though I really do 
>> not like the Perl RE syntax, I prefer Posix/gawk RE syntax) but BSF is a new 
>> acronym to me.
>>
> I try to keep my skill set portable.  I avoid Bash-isms, {g|n}awk, ...  Now 
> that you say PCRE
> is different, my interest in it is diminished.
>
> It seems to me that many users of {g|n}awk learned a primitive awk lacking 
> many features
> such as tolowerr(), touppor(), the "in" operator, ... now assimilated in 
> POSIX awk.
>  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BSF? [was: RE: Java (Re: Some questions on SYSCALL)]

[Seymour J Metz]

I don't like any RE syntax that derives from Eunix, but it's too powerful to 
ignore, especially the flavors that have named captures. Unless I'm compelkled 
toi use something with POSIX syntax, I stick to more powerful versions.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, July 7, 2022 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSF? [was: RE: Java (Re: Some questions on SYSCALL)]

(This thread should move to comp.lang.advocacy.)

On Thu, 7 Jul 2022 16:40:08 +, Farley, Peter x23353 wrote:

>OK, I'll bite: What is BSF please?  I do know of PCRE (though I really do not 
>like the Perl RE syntax, I prefer Posix/gawk RE syntax) but BSF is a new 
>acronym to me.
>
I try to keep my skill set portable.  I avoid Bash-isms, {g|n}awk, ...  Now 
that you say PCRE
is different, my interest in it is diminished.

It seems to me that many users of {g|n}awk learned a primitive awk lacking many 
features
such as tolowerr(), touppor(), the "in" operator, ... now assimilated in POSIX 
awk.

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BSF? [was: RE: Java (Re: Some questions on SYSCALL)]

[Paul Gilmartin]

(This thread should move to comp.lang.advocacy.)

On Thu, 7 Jul 2022 16:40:08 +, Farley, Peter x23353 wrote:

>OK, I'll bite: What is BSF please?  I do know of PCRE (though I really do not 
>like the Perl RE syntax, I prefer Posix/gawk RE syntax) but BSF is a new 
>acronym to me.
> 
I try to keep my skill set portable.  I avoid Bash-isms, {g|n}awk, ...  Now 
that you say PCRE
is different, my interest in it is diminished.

It seems to me that many users of {g|n}awk learned a primitive awk lacking many 
features
such as tolowerr(), touppor(), the "in" operator, ... now assimilated in POSIX 
awk.
 
-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BSF? [was: RE: Java (Re: Some questions on SYSCALL)]

[Seymour J Metz]

bsf4oorexx is a bridge between oorexx and java; it lets an oorexx programmer 
use java classes and methods.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, July 7, 2022 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BSF? [was: RE: Java (Re: Some questions on SYSCALL)]

OK, I'll bite: What is BSF please?  I do know of PCRE (though I really do not 
like the Perl RE syntax, I prefer Posix/gawk RE syntax) but BSF is a new 
acronym to me.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, July 7, 2022 8:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Java (Re: Some questions on SYSCALL



BSF has been available for a long time; why doesn't every Rexx programmer know 
about it and PCRE? Thanks for putting in the work.
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

BSF? [was: RE: Java (Re: Some questions on SYSCALL)]

[Farley, Peter x23353]

OK, I'll bite: What is BSF please?  I do know of PCRE (though I really do not 
like the Perl RE syntax, I prefer Posix/gawk RE syntax) but BSF is a new 
acronym to me.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, July 7, 2022 8:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Java (Re: Some questions on SYSCALL



BSF has been available for a long time; why doesn't every Rexx programmer know 
about it and PCRE? Thanks for putting in the work.
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Java (Re: Some questions on SYSCALL

[David Crayford]

On 7/07/2022 7:53 pm, Rony G. Flatscher wrote:

On 06.07.2022 11:03, Seymour J Metz 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.


Perls moribund. It's fallen off a cliff since it's heyday. Same with 
Ruby. Poorly designed programming languages only last as long as there 
is nothing better to replace them.


https://trends.google.com/trends/explore?date=all=%2Fm%2F05zrn



There is one ecosystem that beats Perl, Python and practically any 
others: Java. For every problem domain, for new emerging technologies 
there are Java class libraries which one can take advantage of. As 
Java classes get compiled to intermediate byte code, these Java class 
libraries can be deployed and used immediately on any hardware and any 
operating system for which a Java virtual machine exists.


That's debatable! I'm a full time Java programmer in the last few years 
and I like. We use Spring Boot which is a high quality framework that 
makes it pleasant to use. I would use SB even for a slightly complex 
command line interface. However, the build systems are a bit spotty 
compared to Node.js, Python etc. Maven is creaking with it's ugly XML 
pom.xml and Gradle doesn't work very well on some systems. In 
particular, z/OS. C# is a far better language then Java. I don't use it 
because I because I'm not a Windows guy but I look on in envy. Kotlin 
meets 95% of the requirements but we dismissed it because it's not 
mainstream so we're stuck with Java.


I was surprised to notice when I followed Timothy's link to the TIOBE 
index that C++ is about to leapfrog Java. 
https://www.tiobe.com/tiobe-index/.  The article cites rapid standard 
rollouts and ground breaking new features such as co-routines. As a Lua 
fan I can't for C++ co-routines. On TIOBE Lua has raced back into the 
top 20 which is due to the surging popularity of gaming frameworks such 
as Roblox.


Since C++11 the language has evolved into a language that some experts 
have called Pythonic [1]. We're using the new z/OS Open XL C/C++ and 
it's a breath of fresh air. You need to be a good programmer to be 
proficient at C++ but IBM are delivering the goods on z/OS.


[1] https://preshing.com/20141202/cpp-has-become-more-pythonic/




The Java runtime environment (JRE) already comes with a wealth of 
professional and tested class libraries covering practically all 
aspects of modern programming, covering everything that any modern 
application may have a need to exploit and interact with.


Yes. But you need to use Open Source libraries for it to be easy to use. 
The JRE doesn't cut it.




Seeing the OpenJDK (open-source Java) community and how vigorously 
Java gets developed further, continually updated in critical areas 
like security, there is no end in sight for this great ecosystem. 
Witnessing also OpenJDK distributions (from Java 8 LTS to the latest 
Java 18) from IBM, Amazon, SAP, even Microsoft, and many, many more 
competent and leading IT-related companies, the support for Java is 
unique compared to any other software there is. 


One of the reasons for the surge in C++ is because Java is flabby. It's 
uses a huge amount of memory and GC is costly in visualized 
environments. GraalVM is a valiant attempt to solve that problem. 
Hopefully OpenJ9 will do something similar.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Java (Re: Some questions on SYSCALL

[Rony G. Flatscher]

On 07.07.2022 14:54, Seymour J Metz wrote:

Which of these has Java equivalents?

  use charnames qw(:short);
  use File::Spec;
  use Getopt::Long 2.3203 qw(:config auto_help auto_version);
  use IO::File;
  use Net::DNS;
  use MIME::Parser;
  use MIME::QuotedPrint;
  use MIME::Tools;
  use Regexp::Common qw /net URI/;
  use Regexp::Common::URI::RFC2396 qw /$host $port $path_segments $query/;
  use Socket;
  use URI::Escape;


These are Perl-specific libraries, which is fine of course.

There are Java equivalents for all of them, one would need to research them first before being able 
to put them to work.


An example for "use URI::Escape;": search on the Internet e.g. with "java encode url" and you would 
get many hits, here a few from the top hits:


 * Java tutorial: <https://www.baeldung.com/java-url-encoding-decoding>,
 * Stackoverflow:
   
<https://stackoverflow.com/questions/10786042/java-url-encoding-of-query-string-parameters>
 * the Javadoc (Java documentation) of the respective Java class:
   <https://docs.oracle.com/javase/7/docs/api/java/net/URLEncoder.html>; if you 
wanted the Javadoc
   of a specific Java version, let us say Java 8, then you could use the 
following search string:
   "javadoc 8 urlencoder"

You get the idea, I am sure. This way you are able to fish (research the Java equivalent) for 
yourself and are not dependent on others to fish for you! ;)



Java has the advantage of always being there, at least for z/OS. JIT doesn't 
hurt.

BSF has been available for a long time; why doesn't every Rexx programmer know 
about it and PCRE? Thanks for putting in the work.


You are welcome!

---rony




From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rony G. Flatscher [rony.flatsc...@wu.ac.at]
Sent: Thursday, July 7, 2022 7:53 AM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Java (Re: Some questions on SYSCALL

On 06.07.2022 11:03, Seymour J Metz 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. For every problem
domain, for new emerging technologies there are Java class libraries which one 
can take advantage
of. As Java classes get compiled to intermediate byte code, these Java class 
libraries can be
deployed and used immediately on any hardware and any operating system for 
which a Java virtual
machine exists.

The Java runtime environment (JRE) already comes with a wealth of professional 
and tested class
libraries covering practically all aspects of modern programming, covering 
everything that any
modern application may have a need to exploit and interact with.

Seeing the OpenJDK (open-source Java) community and how vigorously Java gets 
developed further,
continually updated in critical areas like security, there is no end in sight 
for this great
ecosystem. Witnessing also OpenJDK distributions (from Java 8 LTS to the latest 
Java 18) from IBM,
Amazon, SAP, even Microsoft, and many, many more competent and leading 
IT-related companies, the
support for Java is unique compared to any other software there is.

There is no other language and there is no other software infrastructure that 
can possibly beat Java
in this regard.

Therefore it is a good idea to use Java strategically in software projects.

Having said all that, you may see the motivation why I wrote an ooRexx [1] 
function/class library
that bridges ooRexx and Java, which is called BSF4ooRexx [2]. This ooRexx-Java 
bridge has two main
applications:

   * Allow ooRexx programmers to use Java classes and Java objects as if they 
were ooRexx classes and
 ooRexx objects to which one can send ooRexx messages and the Java objects 
will understand them
 conceptually. Here a small ooRexx example that demonstrates how to use the 
Java class
 "java.awt.Dimension" as if it was an ooRexx class:

 /* Java class, 
cf.<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fjavase%2F8%2Fdocs%2Fapi%2Fjava%2Fawt%2FDimension.htmldata=05%7C01%7Csmetz3%40gmu.edu%7C3c202325a69b418f044508da600f6e1f%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637927916636331741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=0Etc155I%2FyB6VDmsHqh%2FTkMftp4RSjkD3mttR9Ix%2BgQ%3Dreserved=0>
  */
 dim=.bsf~new("java.awt.Dimension", 111, 222)
 say "1)" dim~toString   /* every Java object understands "toString"  */

 dim~setSize(555,222)/* chang

Re: Java (Re: Some questions on SYSCALL

[Seymour J Metz]

Which of these has Java equivalents?

 use charnames qw(:short);
 use File::Spec;
 use Getopt::Long 2.3203 qw(:config auto_help auto_version);
 use IO::File;
 use Net::DNS;
 use MIME::Parser;
 use MIME::QuotedPrint;
 use MIME::Tools;
 use Regexp::Common qw /net URI/;
 use Regexp::Common::URI::RFC2396 qw /$host $port $path_segments $query/;
 use Socket;
 use URI::Escape;


Java has the advantage of always being there, at least for z/OS. JIT doesn't 
hurt.

BSF has been available for a long time; why doesn't every Rexx programmer know 
about it and PCRE? Thanks for putting in the work.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rony G. Flatscher [rony.flatsc...@wu.ac.at]
Sent: Thursday, July 7, 2022 7:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Java (Re: Some questions on SYSCALL

On 06.07.2022 11:03, Seymour J Metz 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. For every problem
domain, for new emerging technologies there are Java class libraries which one 
can take advantage
of. As Java classes get compiled to intermediate byte code, these Java class 
libraries can be
deployed and used immediately on any hardware and any operating system for 
which a Java virtual
machine exists.

The Java runtime environment (JRE) already comes with a wealth of professional 
and tested class
libraries covering practically all aspects of modern programming, covering 
everything that any
modern application may have a need to exploit and interact with.

Seeing the OpenJDK (open-source Java) community and how vigorously Java gets 
developed further,
continually updated in critical areas like security, there is no end in sight 
for this great
ecosystem. Witnessing also OpenJDK distributions (from Java 8 LTS to the latest 
Java 18) from IBM,
Amazon, SAP, even Microsoft, and many, many more competent and leading 
IT-related companies, the
support for Java is unique compared to any other software there is.

There is no other language and there is no other software infrastructure that 
can possibly beat Java
in this regard.

Therefore it is a good idea to use Java strategically in software projects.

Having said all that, you may see the motivation why I wrote an ooRexx [1] 
function/class library
that bridges ooRexx and Java, which is called BSF4ooRexx [2]. This ooRexx-Java 
bridge has two main
applications:

  * Allow ooRexx programmers to use Java classes and Java objects as if they 
were ooRexx classes and
ooRexx objects to which one can send ooRexx messages and the Java objects 
will understand them
conceptually. Here a small ooRexx example that demonstrates how to use the 
Java class
"java.awt.Dimension" as if it was an ooRexx class:

/* Java class, cf. 
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fjavase%2F8%2Fdocs%2Fapi%2Fjava%2Fawt%2FDimension.htmldata=05%7C01%7Csmetz3%40gmu.edu%7C3c202325a69b418f044508da600f6e1f%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637927916636331741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=0Etc155I%2FyB6VDmsHqh%2FTkMftp4RSjkD3mttR9Ix%2BgQ%3Dreserved=0>
 */
dim=.bsf~new("java.awt.Dimension", 111, 222)
say "1)" dim~toString   /* every Java object understands "toString"  */

dim~setSize(555,222)/* change width Java-like*/
say "2)" dim~toString

dim~width=999   /* change width ooRexx-like (attribute)  */
say "3)" dim~toString

::requires BSF.CLS  /* get ooRexx-Java bridge*/

Running the above ooRexx program yields:

1) java.awt.Dimension[width=111,height=222]
2) java.awt.Dimension[width=555,height=222]
3) java.awt.Dimension[width=999,height=222]


  * Allow Java programmers to easily run ooRexx scripts/macros, with the 
possibility to even supply
arguments that may be even Java objects with which the ooRexx program can 
readily interact with.
Here a small Java example that demonstrates how to run an ooRexx script 
from Java using the
standard Java scripting framework (cf.

<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fjavase%2F8%2Fdocs%2Fapi%2Findex.html%3Fjavax%2Fscript%2Fpackage-summary.htmldata=05%7C01%7Csmetz3%40g

Java (Re: Some questions on SYSCALL

[Rony G. Flatscher]

On 06.07.2022 11:03, Seymour J Metz 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. For every problem 
domain, for new emerging technologies there are Java class libraries which one can take advantage 
of. As Java classes get compiled to intermediate byte code, these Java class libraries can be 
deployed and used immediately on any hardware and any operating system for which a Java virtual 
machine exists.


The Java runtime environment (JRE) already comes with a wealth of professional and tested class 
libraries covering practically all aspects of modern programming, covering everything that any 
modern application may have a need to exploit and interact with.


Seeing the OpenJDK (open-source Java) community and how vigorously Java gets developed further, 
continually updated in critical areas like security, there is no end in sight for this great 
ecosystem. Witnessing also OpenJDK distributions (from Java 8 LTS to the latest Java 18) from IBM, 
Amazon, SAP, even Microsoft, and many, many more competent and leading IT-related companies, the 
support for Java is unique compared to any other software there is.


There is no other language and there is no other software infrastructure that can possibly beat Java 
in this regard.


Therefore it is a good idea to use Java strategically in software projects.

Having said all that, you may see the motivation why I wrote an ooRexx [1] function/class library 
that bridges ooRexx and Java, which is called BSF4ooRexx [2]. This ooRexx-Java bridge has two main 
applications:


 * Allow ooRexx programmers to use Java classes and Java objects as if they 
were ooRexx classes and
   ooRexx objects to which one can send ooRexx messages and the Java objects 
will understand them
   conceptually. Here a small ooRexx example that demonstrates how to use the 
Java class
   "java.awt.Dimension" as if it was an ooRexx class:

   /* Java class, cf. 
 */
   dim=.bsf~new("java.awt.Dimension", 111, 222)
   say "1)" dim~toString   /* every Java object understands "toString"  */

   dim~setSize(555,222)    /* change width Java-like    */
   say "2)" dim~toString

   dim~width=999   /* change width ooRexx-like (attribute)  */
   say "3)" dim~toString

   ::requires BSF.CLS  /* get ooRexx-Java bridge    */

   Running the above ooRexx program yields:

   1) java.awt.Dimension[width=111,height=222]
   2) java.awt.Dimension[width=555,height=222]
   3) java.awt.Dimension[width=999,height=222]


 * Allow Java programmers to easily run ooRexx scripts/macros, with the 
possibility to even supply
   arguments that may be even Java objects with which the ooRexx program can 
readily interact with.
   Here a small Java example that demonstrates how to run an ooRexx script from 
Java using the
   standard Java scripting framework (cf.
   
):

   import javax.script.*;

   public class TestRunRexx
   {
    public static void main (String args[])
    {
    String rexxCode = "say 'Hello, world, this is Rexx speaking ...' 
\n" +
  "say 'It is:' .dateTime~new  
" ;
    ScriptEngineManager manager = new ScriptEngineManager();
    ScriptEngine se = manager.getEngineByName("rexx");
    System.out.println("about to execute the Rexx program from 
Java...");
    try
    {
    se.eval(rexxCode);
    }
    catch (Throwable t)
    {
    System.err.println(t);
    System.exit(1);
    }
    System.out.println("about to end Java.");
    System.exit(0);
    }
   }

   Compiling the above Java program with "javac TestRunRexx.java" and running it 
with "java
   TestRunRexx" yields:

   about to execute the Rexx program from Java...
   REXXout>Hello, world, this is Rexx speaking ...
   REXXout>It is: 2022-07-07T13:43:42.67
   about to end Java.

---

So my advice would be, if you use ooRexx and have a need for functionality that is not available: 
install the ooRexx-Java bridge BSF4ooRexx and from that moment on you have access to *all* Java 
class libraries on *all* operating systems: this makes a wealth of libraries immediatley available 
to