@mt30 as I am not a Java expert I may have made a few mistakes in terminology.
But I do not think that your comments address the essential issues I raised.
If you like, we could select one point and discuss it in more depth.
I am open to retract my conclusions and others might benefit from the discussion too - but you say you do not have time for that.
Misunderstanding difference between standard library and language itself is beyond your issues with java.
I opened your post to learn some actual issues with java. I don't know, something about cold start, about size of "fat jars", about where java lies behind scala/kotlin/rust/erlang/lisp. Something about abuse of reflection, agents, ineffective practices of defensive programming, performance impact of Optional<> ... Instead you wrote that using guava might affect performance because it's not part of jdk... It's trivial to benchmark this. But checking it requires acting professional, being objective. Using such half baked claim against whole language is just unprofessional. Taking on the point that packages are useless, and final argument was that IntelliJ generates import statements for you - that's laughable. I don't even how to address this, where to start with explaining why you are wrong, except for treating you as a total beginner. I don't even know where to start and I feel helpless, that's where the laugh comes from. This is what made me feel offended.
In my understanding, you are disappointed that java is not c# (assumption: backed by dot net package appropriate for 2019) with it's main (?!) IDE not being copy of Visual Studio.
Not to mention, that NetBeans or Eclipse have more right to be called the main IDE for java, Eclipse for being older, NetBeans for being provided by Sun/Oracle.
Do you even know that for years the best refactoring toolkit for VS was made by JetBrains? The guys behind IntelliJ?
You wrote pretty huge document about where java falls short, but for the part I read - you focus on parts where you don't know how to use it, dont understand what you do, and regret that it's not c#. Understand my disappointment. I expected much more, given the fact you published the document on separate URL, as a word document, and you publish it using your real name. On the contrary I'm just an anon around the internet and can change the nickname whenever I want.
On the other hand I can add fair share of criticisms for c#, like I don't get why I can incre the performance by order of magnitude by marking blocks of code as unsafe, unrolling the loops and inlining getters/setters. Has Microsoft done something with that since 2014 when was the last time I done something with that ecosystem?
Don't get me wrong, if you take another approach to the subject, I'd be glad to read your article and respond to it.
@mt30
I find that anonymous writers are more likely to make personal comments and use offensive language.
As we are not making any progress I think we should just agree to disagree and end it here.
Don't get me wrong, if you take another approach to the subject I'd be glad to have this discussion with you.
To start making progress, acknowledge what I wrote, because I put few (or even a dozen) screens of text which you completely ignored, dismissed by calling it personal and offensive. Refer to what I wrote, not to your feelings. To illustrate up your zero level of attention on what I wrote, you can't write my nickname properly. :(
I acknowledge you made some good points - which I can refute.
But you also used the terms laughable, "total beginner", "unprofessional", "half baked claims" and the like.
So let's just agree to disagree.
Well, many "issues" are not issues but plain lack of knowledge. "Issues" listed as "language weakness":
There is a comprehensive time-date-calendar framework in JDK. It's part of standard library for many years. Once it was added, I never had any task which involved time or date manipulation which would require any external libraries.
You're mixing up two different things: Iterable and Stream. From the language standpoint Java arrays are Iterables, since you can use them in enhanced for loop (like for (Type value: iterable) {} ). And you can convert array into Stream using Arrays.stream(). And, well, Java is not a Microsoft thing, there is no point to expect that something will have performance impact just because it's not a part of standard library.
Every lambda type in Java corresponds to interface with single abstract method. This is the single, unified standard way to define lambda types. Functional interfaces already defined in standard library are for your convenience, but if you don't like them or don't want to search them, nothing prevents you to create your own. No point to complain and no "issue", just lack of knowledge.
Must admit that I'm happy that Java has no async/await as part of language. There are two significant reasons for that:
These keywords is a huge reverence to imperative style. They result to non-composable, hard to read and maintain code. In contrast, Promises/Futures enforce functional, composable code style and don't need language level support.
Presence of such keywords would mean that this feature is locked to single implementation which not necessarily is the best one or completely fits my needs.
There are more than one frameworks for describing time in Java and that is in itself a problem. I have not found one that provides the minimum I need easily. For instance, how do you construct a Date from its components, and how do you decompose it again. You need to start creating CALENDAR instances and so on. Of course it can be done, but it is verbose and messy. But even if I find the one and best, it is not easily compatible with the others. When you need to call other libraries that take Instant and you have Date or the library uses LocalDateTime and you have Calendar. Managing these conversions and the intricacies of each object are time consuming and shouldn't be.
I am not an expert, but I am pretty familiar with Streams by now. I recommend you take a look at IEnumerable in .Net. with LINQ. I think you will agree that Streams are a very poor imitation of what can be done in a modern language. LINQ provides a functional language over all IEnumerables in a more succint and unified way. Streams are bogged down by the fact there is no support for extension methods in Java and that there is no one interface to describe all collections.
Even creating a Stream is a big deal. To create a stream from an array you have to explicitly call Arrays.stream(). Collecting streams is a big hastle often requiring combinations of static Collectors methods instead of a simple toArray or toList.
Lambdas in Java are second class citizens. They are just replacements for interfaces. In order to use them you have to use a predefined interface type that matches your lambda signature. The most common ones exists, but you often need different ones (e.g. a lambda that takes 3 parameters, returns one and does not throw exceptions), and even if you have one that matches, you are forced to call its particular method (apply, supply or what not) which may not be intuitive in the context you are using it. In other languages, a lambda is a callable type and you call it with () just like a method.
Async/Await is extremely powerful and is missing in the language. The poor support for this kind of concurrency in the language has lead to a plethora of Future libraries springing up to try to fill the gap.
There is no disadvantage at all in locking you into a single implementation if that implementation is done well by the language developers. Implementing async await behavior is extremely difficult and I dont think you should be wishing you had the freedom to write it yourself. You might not do such a good job. (Maybe you will, but most people wont)
------
Since writing this post I have got to know Kotlin quite well and I can say that it does provide solutions for many of these issues over the JVM.
The fact that JetBrains saw the necessity to implement lambdas as other modern languages do, to add the concept of sequence and to add extension methods is testimony that the many of the weaknesses that I have outlined in my post are indeed great drawbacks in the Java language that needed to be addressed.
Unfortunately Kotlin still suffers from the terribly complicated dependency management issues that it inherits from the Java ecosystem, but as a language it is a great improvement.
Date class is an old-fashioned way to work with date and time. There is a new java.time framework designed after Joda Time, one of the best tools dedicated to this topic.
Java is not .Net and don't have to be.
Lambdas in Java are replacement for anonymous classes. And like classes lambdas are first class citizens. If you need lambda with 3 parameters - create appropriate interface. What's the problem?
As I told you, they harmful. And lack of them can't lead to any library since this is language level feature. As of asynchronous support, Java has CompletableFuture in standard library. This is, perhaps poorly named, but otherwise exceptionally good Promise implementation. So, there is no gap to fill. Nevertheless I'm happy that there is such a freedom since I wrote a replacement for CompletableFuture (and underlying scheduler). One of the reasons - my implementation uses Linux io_uring asynchronous I/O API which is only about a year old. Why should I wait for language developers if I can do that by myself?
As for Kotlin: it has couple of interesting ideas accompanied with pile of poorly thought out code size reduction hacks. Overall mix results to significant mental overhead which negativity impacts productivity, despite claims. By the way, it doesn't solve any real Java issues which Java unable to solve by itself. On the other hand, it might fit better to your expectations as it provides many useful tools to create mess in codebase, freedom to put any class in any file and extension methods are among them.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@mt30 as I am not a Java expert I may have made a few mistakes in terminology.
But I do not think that your comments address the essential issues I raised.
If you like, we could select one point and discuss it in more depth.
I am open to retract my conclusions and others might benefit from the discussion too - but you say you do not have time for that.
Misunderstanding difference between standard library and language itself is beyond your issues with java.
I opened your post to learn some actual issues with java. I don't know, something about cold start, about size of "fat jars", about where java lies behind scala/kotlin/rust/erlang/lisp. Something about abuse of reflection, agents, ineffective practices of defensive programming, performance impact of Optional<> ... Instead you wrote that using guava might affect performance because it's not part of jdk... It's trivial to benchmark this. But checking it requires acting professional, being objective. Using such half baked claim against whole language is just unprofessional. Taking on the point that packages are useless, and final argument was that IntelliJ generates import statements for you - that's laughable. I don't even how to address this, where to start with explaining why you are wrong, except for treating you as a total beginner. I don't even know where to start and I feel helpless, that's where the laugh comes from. This is what made me feel offended.
In my understanding, you are disappointed that java is not c# (assumption: backed by dot net package appropriate for 2019) with it's main (?!) IDE not being copy of Visual Studio.
Not to mention, that NetBeans or Eclipse have more right to be called the main IDE for java, Eclipse for being older, NetBeans for being provided by Sun/Oracle.
Do you even know that for years the best refactoring toolkit for VS was made by JetBrains? The guys behind IntelliJ?
You wrote pretty huge document about where java falls short, but for the part I read - you focus on parts where you don't know how to use it, dont understand what you do, and regret that it's not c#. Understand my disappointment. I expected much more, given the fact you published the document on separate URL, as a word document, and you publish it using your real name. On the contrary I'm just an anon around the internet and can change the nickname whenever I want.
On the other hand I can add fair share of criticisms for c#, like I don't get why I can incre the performance by order of magnitude by marking blocks of code as unsafe, unrolling the loops and inlining getters/setters. Has Microsoft done something with that since 2014 when was the last time I done something with that ecosystem?
Don't get me wrong, if you take another approach to the subject, I'd be glad to read your article and respond to it.
@mt30
I find that anonymous writers are more likely to make personal comments and use offensive language.
As we are not making any progress I think we should just agree to disagree and end it here.
Don't get me wrong, if you take another approach to the subject I'd be glad to have this discussion with you.
To start making progress, acknowledge what I wrote, because I put few (or even a dozen) screens of text which you completely ignored, dismissed by calling it personal and offensive. Refer to what I wrote, not to your feelings. To illustrate up your zero level of attention on what I wrote, you can't write my nickname properly. :(
I acknowledge you made some good points - which I can refute.
But you also used the terms laughable, "total beginner", "unprofessional", "half baked claims" and the like.
So let's just agree to disagree.
Well, many "issues" are not issues but plain lack of knowledge. "Issues" listed as "language weakness":
Remaining "issues" are of the same quality.
As for Kotlin: it has couple of interesting ideas accompanied with pile of poorly thought out code size reduction hacks. Overall mix results to significant mental overhead which negativity impacts productivity, despite claims. By the way, it doesn't solve any real Java issues which Java unable to solve by itself. On the other hand, it might fit better to your expectations as it provides many useful tools to create mess in codebase, freedom to put any class in any file and extension methods are among them.