On 10/07/2022 6:49 pm, Rony wrote:
Am 09.07.2022 um 03:15 schrieb David Crayford <dcrayf...@gmail.com>:
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.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/
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'm not talking about enumerated types. I'm referring to C# Enumerables
which are co-routines
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/yield.
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 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
That is according to the JRE specs and merely exploiting modern architectures,
especially important for a garbage collected language.
Yes. But it's a heavy startup for running certain types of programs,
such as command line utilities or short running batch. IBM had
experimental code for multi-tenant JVMs. I don't know what happened to
that.
in Java and we have to write documentation on how to tune the heap so GC cycles
don't go crazy.
In case this matters the configuration abilities for the JVM are there.
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 applications and
micro-services which are not you would call light-weight
https://spring.io/blog/2021/03/11/announcing-spring-native-beta.
Other teams in my organization are using Quarkus https://quarkus.io/.
(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 bad-mouthing has been an
important part of FUD (fear, uncertainty, doubts) marketing in the past decades
(thinking e.g. of mainframes, COBOL, OS/2 and the like) and is something you
surely can do without I am sure.
I'm not bad mouthing anything. I'm opinionated but so are you.
Well, it would be possible to communicate the same content, opinions in a more
constructive way then. OTOH everyone is responsible for his own formulations
and there is probably no one who did not mis-communicate by chance or by
circumstances. :)
Yes. I'm a Brit, we offend people with our forthright approach (not as
much as scandanavians though) ;)
—-rony
----------------------------------------------------------------------
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
