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. > 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 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. > 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. :) —-rony ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
