You can write a pretty trivial Java program to copy stdin to stdout but Java is still one of the enterprise languages and people writing enterprise applications don't tend to write this type of software (but they do tend to have log4j vulnerabilities). The strengths of Java are its mature dependency management system(s), its comprehensive standard library and the vast ecosystem of third-party libraries. A better test…
A better test of the language is whether you can write a complicated application in relatively fewer lines of code. To a point. In many situations, a better test is whether a coder unfamiliar with said complicated application can maintain it relatively easily.
Why I Like Java (2014)
101–110 of 152 posts
Re: Why I Like Java (2014)
#102Earlier quoted context omitted.
It is rather non-trivial to write a program to copy input to output if one requires proper handling of a termination signal when the code flushes the already read data without waiting for more and exits without loosing any buffered data. Knowing how to do that is a good sign that the person really knows the language and it’s libraries.
Can this be done with vanilla Java? If yes, can you share a snip of code? I would curious to learn! Using POSIX C, I think I know the solution.
As another comment has written one needs Runtime.getRuntime().addShutdownHook(). The hook then, for example, closes the input stream to ensure that it’s reader is woken up from a blocking read and then waits until the already read data is written. In turn this requires to know how synchronization works.
Re: Why I Like Java (2014)
#103You can write a pretty trivial Java program to copy stdin to stdout but Java is still one of the enterprise languages and people writing enterprise applications don't tend to write this type of software (but they do tend to have log4j vulnerabilities). The strengths of Java are its mature dependency management system(s), its comprehensive standard library and the vast ecosystem of third-party libraries. A better test…
I'm really not sure I would call Java's standard library comprehensive. I've only worked with it for a few months but needed many Apache commons libraries.
Which falls under the heading of "mature dependency management system". Apache Commons (or Google Guava) is pretty much considered part of the standard library at this point, as they are so easy to include in projects.
Re: Why I Like Java (2014)
#104You can write a pretty trivial Java program to copy stdin to stdout but Java is still one of the enterprise languages and people writing enterprise applications don't tend to write this type of software (but they do tend to have log4j vulnerabilities). The strengths of Java are its mature dependency management system(s), its comprehensive standard library and the vast ecosystem of third-party libraries. A better test…
I'm really not sure I would call Java's standard library comprehensive. I've only worked with it for a few months but needed many Apache commons libraries.
By the standards of the day, when Java was released it's standard library was pretty comprehensive: in addition to covering most of the c-ish stdlib, it had networking and web-aware apis.
It did set a new standard in a way that was very beneficial for the languages that came after it: you're not an ACTUAL language if you don't have a "good" standard library, and I can argue that "good" was defined by Java more than C++ or anything else at the time.
I also don't see any new languages, while more modernized, that have substantially pushed the envelope further to be the new gold standard of a minimum batteries included stdlib. All I could probably say is various threading/concurrency apis, but Java has added a lot of that too over the years.
Re: Why I Like Java (2014)
#105Obviously the right solution here is:
#!/bin/bash
cat -
This always riles people up, but I'll assert it again: An equivalent modern app that does something useful is shorter in Java than in Ruby or Python, largely because the type system enforces many of the things you would otherwise have to write explicit tests for.
Re: Why I Like Java (2014)
#106You can write a pretty trivial Java program to copy stdin to stdout but Java is still one of the enterprise languages and people writing enterprise applications don't tend to write this type of software (but they do tend to have log4j vulnerabilities). The strengths of Java are its mature dependency management system(s), its comprehensive standard library and the vast ecosystem of third-party libraries. A better test…
No isNullOrEmptyString method, no Set operations, Java didn't have a good HTTP library until Java 11, no lazy file reading, unless you use InputStream which is a pain. vast majority of mediocre libraries and one man libraries. We use Spring because it uses the best libraries, so the other ones are discarded. Java being around for so long doesn't have a lot of convenience methods like others do languages do, like the…
I think Kotlin has the utility methods you have in mind.
Im not saying C# is bad as I don‘t have experience with it, just that Kotlin is a more realistic replacement for most Java shops.
Re: Why I Like Java (2014)
#107Yeah, keep writing perl and spout cynicism about everything. I feel like they are chasing a aesthetic of conciseness, their perfect little haskell program, not recognizing that regularity and good api design are much more important. What is beautiful for a 100loc program becomes ugly and wrong for a 100kloc program. Other aspects become much more important. I'm not a huge fan of go, but it proved there is a necessity…
The notion that languages focused on writing large-scale programs must be "boring" seems a bit silly. What these languages need is lots of ways to define sensible modularity boundaries, and the "boring" aesthetic (or lack thereof, rather) can really get in the way of that.
> What these languages need is lots of ways to define sensible modularity boundarie
One of the most important modularity boundaries is dependencies on libraries written by others. So a good, easy to use dependency manager and a straight forward mechanism for creating and sharing libraries is crucial.
Java does really well in this regard.
Re: Why I Like Java (2014)
#108Modern Java is actually pretty good. It's taken great features from other JVM languages like Kotlin and Scala and is much better for it. The JVM is a wicked fast run time and its nice to have a mature ecosystem of libraries to work from and large pool of developers available who know it inside and out. You could do far worse when picking a language for your team to use.
Re: Why I Like Java (2014)
#109Earlier quoted context omitted.
> JS/Node has NPM If this isn't a joke, I'd suggest learning the Maven or Gradle build systems. NPM has such horrible dependency management that these Java systems will seem like magic!
OK, so I'm trying out maven central as people in this thread are recommending. As an example, I'm searching for a command line argument parser. The first thing I'm noticing is that there seems to be no way to judge the popularity of the libaries (an often-used proxy for quality, e.g. number of downloads, GitHub stars, etc). I enter "argparse" and the first hit isn't even Java! It seems to be a npm package?? https://s…
Maven Central is the place where the libraries are hosted, but not the place where they are found by users. Use Google/Stackoverflow/Reddit and simply search for what you want.
Searching for "command line argument parser java" immediately leads you to libraries and infact lists of libraries (see https://stackoverflow.com/a/7829772), of which most are going to be available on Maven Central.
Then you do your research that the library you are looking at looks valid and is trustable (!) by checking out the info available on it, maybe make another search to find opinions on it.
Then when you have decided to try it, look at its docs to find out where it s located on Maven Central and use it from there.
Re: Why I Like Java (2014)
#110Java: plentiful well paying jobs, good/great tools, good/great runtime. Personally, I like boring, predictable, "easy" (referring to low cognitive overhead of statically typed languages in general) for work, and save the fun stuff (lisp/scheme in my case) for personal projects.
This is how I feel about C# and .Net - they are relatively easy to hold in your head, the tools are excellent for the language, and there are plenty of decent paying jobs.
There is very little to trip you up in C#, for my first project in it I sat down and started churning out code and looking stuff up when I got stuck. Try doing that with C++ and you will end up with a hole lot of trouble.