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