12 ms·

The Reason Java Is Still Popular

54 points by saikatsg 4y ago

deleted 4y ago
[deleted]
drdec 4y ago
Unfortunately one of the examples used in the article introduces an SQL injection attack vector. Don't build parametrized SQL out of Strings.
- invalidname 4y ago
  That's from here: https://openjdk.org/jeps/8273943 https://openjdk.org/jeps/8273943 It doesn't. That's not a plain string replacement...
- littlestymaar 4y ago
  And email validation is done with a regex… This low-effort post really doesn't deserve the front page…
  - invalidname 4y ago
    This was copied from the original article linked by this article...
  - edp 4y ago
    This was code from another article, linked in the introduction.
  - ipaddr 4y ago
    How would you do it
    - papercrane 4y ago
      Check that its a string containing '@' with at least one character before and after the @ symbol is usually the only sensible thing to do. The format for emails is surprisingly complex, and while you can use a regex to catch 99% of the right values, it's very difficult to get it 100% right. Often the best thing to do is just to try and send an email to the address a validation link.
      - __ryan__ 4y ago
        Check that its a string containing '@' with at least one character before and after the @ symbol is usually the only sensible thing to do. This is exactly what the regex in the example is doing.
        papercrane 4y ago
        The regex is ^[^@\s]+@\S+$ This would reject valid email addresses using quoted parts like john."@".doe@valid.example. Edit: Looking at it closely it looks like the attempt is to reject anything with an '@' in the user part, which would be an error (e.g. john."@".doe@valid.example). Except since "\S+" also includes '@' this regex will still work, but by accident. It would reject the valid email john."\ ".doe@valid.example
        __ryan__ 4y ago
        I don't think that's true. In JS: /^[^@\s]+@\S+$/.test("john.\"@\".doe@valid.example") == true Edit: Hmm, I see what you mean. At first glance I thought it was just checking that it didn't start with @ or whitespace.
        papercrane 4y ago
        Sorry, I edited my comment and then noticed you replied already. It's working by accident since the '\S+' will match the second '@', but if you had a quoted space in the user it would not work e.g. john."\ ".doe@valid.example, but would work with john.@.doe@invalid.example which I believe the regex is author meant to be caught as invalid.
    - littlestymaar 4y ago
      Two options: - use a library that implements RFC 5322 properly. - don't validate the email address (that is, don't try to reject most invalid addresses) and just check that the field contains at least one `@` to be sure the user didn't enter something else than his email address by accident. Tying to perform email address validation with regex you're writing yourself is the best way to reject perfectly acceptable email address and get frustrated users.
    - mrkeen 4y ago
      Parse, don't validate. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
- jerven 4y ago
  I think you are talking about this example: ResultSet rs = DB."SELECT * FROM Person p WHERE p.last_name = \{name}"; This when it becomes valid java will not allow an SQL injection attack. The name part would be properly passed as a parameter. Not a string concatenation. Per https://openjdk.org/jeps/430 https://openjdk.org/jeps/430 If that was not the example you where thinking about, sorry :) Otherwise yes don't build parameterized SQL out of strings !
  - drdec 4y ago
    Thanks for the correction
  - jhhh 4y ago
    My main complaint about this new feature is that it has such poor conceptual clarity that people already familiar with Java will almost always misinterpret what is happening in exactly the same way. I've seen people post similar comments to the one you're correcting on reddit as well.
- __ryan__ 4y ago
  You are thinking of string interpolation. The idea behind string templates, the feature the example is showcasing, is effectively a way to define a function that can be called with similar syntax to string interpolation. So DB."SELECT * FROM Person p WHERE p.last_name = \{name}" would basically be a function call like DB("SELECT * FROM Person p WHERE p.last_name = ", name), which would do the right thing to parameterize the SQL.
- jbverschoor 4y ago
  So you're talking about a preview/beta/new feature (TemplatedString), and use that as the reason it's "still" popular?
  - __ryan__ 4y ago
    First of all, yes, new features alone can make something maintain popularity. Why would that not be the case? Second, the author was using that as an example of Java showing a pattern of adding syntax improvements, which again might be something that maintains popularity. Finally, from the article: But let's talk about the Java we have today, not the one coming in 6 months. It was just one talking point. Did you even read the article?
phaedryx 4y ago
It's interesting what "popular" can mean. Chances are the "popular" kids in your high school weren't necessarily well liked, they just had social clout. Where I work now the the "Java" devs code about 80% Kotlin and 20% Java. At my previous job we were mostly Ruby except for a service that relied on a Java library that connected to some obscure systems that no other language had a library for. Yeah, we used Java, but it was because that was our only option.
- tester756 4y ago
  >Where I work now the the "Java" devs code about 80% Kotlin and 20% Java. That reflects my experience Java devs seem to be moving to Kotlin, or as some would say JetBrain's C# hehe
- LennyWhiteJr 4y ago
  Yup, I work at Amazon and my team along with many surrounding teams are only coding in Kotlin from this point on. The JVM and its ecosystem brings insane value to the table, and Kotlin lets you take all the benefits while removing most of the downsides of Java.
  - gorjusborg 4y ago
    I agree with you, but I haven't had good ling term experiences with hosted languages. I hope it works out for you.
    - Kwpolska 4y ago
      Can you clarify? What didn't work out, which languages were involved?
  - sandGorgon 4y ago
    why is this ? i have worked on kotlin in the android ecosystem. But something like kotlin with spring is no better than java right ? you still have to deal with all the controllers, etc. on reddit, one of the arguments was interesting - the biggest value of kotlin in backend is using var/val instead of types and making everything public (instead of getters/setters). would that be correct ? Lombok doesnt fix this ?
rad_gruchalski 4y ago
The post is missing to mention the ecosystem.
etchalon 4y ago
"Popular" and "still used a lot" are two very different ideas.
- avmich 4y ago
  I think terminology of the author is such that they are synonyms.
ravirajx7 4y ago
The main reason behind Java's success has always been the community and it's ecosystem. Once you learn basics you literally can code very good things with ease using a huge number of examples/solutions present on web. The user base kind of helps the developers find the fixes way too easily compared to any other language. I doubt it is ever going to lose it's popularity as Java is very good to accept good changes(although slowly). The best thing about java is it provides code stability and backward compatibility and this is the reason it will thrive even more.
- adam_arthur 4y ago
  Java can get the job done, but the language is certainly dated in a way that's impossible to fix without breaking changes. Similar to C++ getting replaced by go and rust everywhere, Java's time has gone. It's just running on momentum at this point. The JVM will likely continue on though
  - qsort 4y ago
    Java is still 95%+ of the marketshare of the JVM. Also "C++ being replaced by go and rust everywhere" is very much hyperbolic. You are either wildly exaggerating or living in a bubble.
    - adam_arthur 4y ago
      C++ still exists because existing projects were written in it... that's it. There's no value in using it for future projects other than a wider pool of developers to source from... a network effect that will diminish with time. Java is objectively dated in so many ways, it's not really defensible to say otherwise. Tons of unnecessarily verbose and boilerplate aspects of the language.
      - toxik 4y ago
        That is a very bold claim from basically zero evidence, on both accounts but especially C++ being a zombie language.
sandGorgon 4y ago
I have a question for those of you who have worked on java..or considered working on java ..and ultimately did golang or something. what would make you choose java : 1. is it a better framework than spring boot 2. is it a better tooling like heroku or something for java 3. is it better community & programming paradigms ? I once asked a question "can i write a java api using all variables as public" and got flamed pretty badly. Do people want an alternative to the MVC/DAO/DTO structure ...where the community doesnt flame them ? 4. is it something else ? Because based on docker pulls, java still is probably just as popular as nodejs or something. what would make java sexy again ?
- zaphar 4y ago
  I'm excited about value types. I'm less than enthused by the spring ecosystem. It does help you start quicker than you would without it but while running it in production over time I think it has costs I'd rather not pay so I suppose a better framework would excite me too. Java as a language is fine and I have no real complaints there.
  - sandGorgon 4y ago
    >while running it in production over time I think it has costs I'd rather not pay so I suppose a better framework would excite me too. can you elaborate on this ? really have been considering spring boot, etc. But coming from the python world ...i feel it cognitively very hard to get through. But im super keen to know what issues come in production. Most of us were under the impression that Spring in production just works. >so I suppose a better framework would excite me too especially from this perspective. What would you want ?
    - zaphar 4y ago
      My complaint about spring is the same complaint I have about almost every runtime dependency injection framework. In the happy path everything just works. But when you get off that happy path which happens all the time in production for any system older than a month you get exceptions and those exceptions list stuff in the stack trace that you've never seen and didn't even know were being used. For those issues every once in a while when you try to dig into the error you find yourself deep into runtime reflection code somewhere trying to figure out how this particular configuration happened. How your code got glued together is a mass of difficult to read code buried deep in the spring framework. We have a saying about these types of frameworks: They are a great way to turn compile errors into runtime errors. When you are just starting out on a project it's great. You get up and running fast and as long as stuff doesn't change too much you are probably fine. But when your codebase reaches 5+ years of age it's highly likely to see a spike in "runtime errors" that potentially could have been compile time errors every time you release and releases get nerve wracking for a bit until eventually the codebase get's frozen in stone and someone starts suggesting we rewrite it.
deleted 4y ago
[deleted]
mrkeen 4y ago
Pretty disingenuous comparison in the Annotation section. The annotated version is more terse because he's showing its usage. For the non-annotation version he's showing the implementation. edit (because I forgot to quote the article directly): The syntax is more terse
- invalidname 4y ago
  The point wasn't that it's terse. The point was that the other version was inefficient and the system couldn't optimize the cost away or move it.
avmich 4y ago
> Maven central is MASSIVE with 27 terabytes of jars I think this is a bad approach. Developer should know his components, and adding one shouldn't be a frequent event.
- Supermancho 4y ago
  I'm not sure why the size of a shared code library is important. Adding components is about reusing code while replacing them is about having to track security issues (which is very good now, via maven) and new functionality being added (which you may or may not want). Same as NPM or any other package manager that existed.
  - avmich 4y ago
    If you consider 27 TB a good thing, you to some degree invite code bloat. Libraries should be small and carefully designed.
    - invalidname 4y ago
      I would say they should be the "right size". 27TB isn't one library. It's the amount of libraries there are. In the NPM world there are too many small libraries that create a dependency graph that's impossible to parse mentally. No one knows your true dependencies and that created many problems. In Maven libraries are sometimes too big. That's true. But most of them are closer to the size that gives a library a bit of "meat". Obviously YMMV.
    - kaba0 4y ago
      27 TB is about the vast amount of choice in the ecosystem. Try to delete the node_modules folder vs the .m2 one on windows — only one of these chokes out a high-end laptop. In my experience Java dependency trees are not as absurdly deep as JS’s. Sure, frameworks do add quite a few nodes to the tree, but libs don’t have as many transitive deps as they do in JS, perhaps due to the better standard lib.
noelwelsh 4y ago
I don't care much for Java. However, if you want a performant GCed language with a top tier ecosystem JVM languages must be in contention and there aren't many other viable choices. WASM might shake this up in a few years. We'll see.
naranha 4y ago
Maven is a pretty horrible dependency manager. I would take NPM over it any day, because it is so much simpler. There is much less that can go wrong, while with maven you're fighting with the tooling all the time. pom.xml files are much larger than package.json files. While I can read and understand a package.json no problemo in a couple of seconds, with pom.xml files I'm completely lost for hours on end, even when I wrote them myself a while ago.
- TedDoesntTalk 4y ago
  maven predates NPM by probably 20 years. We've learned a lot about dependency managers collectively in that time. I'm sure if maven were rewritten today, it would be different.
  - yesbabyyes 4y ago
    Six years; 2004 vs 2010.
  - kaba0 4y ago
    NPM changed its model (more like fixed) several times during the few years it existed. They hardly learn anything.
- Supermancho 4y ago
  Why did I include this package B? Oh it addresses a security concern from a dependency of this other package A. Hope you put a comment there. Wait, there's a security issue with B also? Add another package C to deal with the security issue in B. That's just 1 aspect. Now let's munge in plugins and plugins of packages and it gets messy real fast. Outside of the outdated XML, is there a way to deal with these problems cleanly?
- lordnacho 4y ago
  The problem is also that there's several dependency managers in the ecosystem. You end up learning them all badly because some piece is only available in one or the other.
- 4y ago
yardstick 4y ago
> Java has been around for nearly 30 years and is still mostly compatible to Java 1.0. That is fantastic and unrivaled! I’ve been writing java code since about 2001 and up until Java 8 this was fairly true, and definitely a fantastic thing. However the leap from 8 to 11 or 17 (all LTS releases) is a painful process. We are moving from 8 to 17 at work, but the number of issues we run into with incompatible libraries is a right royal pain. Especially when it’s down to the (imo) silly decision to rename the java EE packages to jakarta. A pointless exercise (imo) that has held back a lot of organisations from upgrading sooner.
stickfigure 4y ago
There's some good, some bad here. Stuff he gets right: * Getters/setters is a nonissue * Operator overloading is a nonissue. I did like how Ceylon handled it (operators are aliases for normal spelled-out methods) but honestly overloading is not something I ever miss. And it was a minefield back in my C++ days. * Dependency management in Java is decent. It's worse in every other ecosystem I've encountered. Stuff he gets wrong: * Checked exceptions are horrid. The people who hate them aren't driven by laziness, they're driven by the desire to use standard interfaces - especially now that we have lambdas. You can use `Runnable`! Unless your code throws a checked exception... in which case you have to go through the ceremony of wrapping it. This is stupid. You can have standard interfaces, or you can have checked exceptions, and standard interfaces are vastly more useful.
- sandGorgon 4y ago
  genuine non flamy question here. why getters/setters. Most frameworks (and not languages) use everything public. Rails, React, golang's frameworks, flask/fastapi. Code has generally not suffered from being public. Would you not accept a Java framework with everything public ? i asked this question on /r/java some time back and got badly flamed. So im trying to understand this. This seems to very philosophical...but then most other frameworks in other languages dont carry this philosophy.
  - courgette 4y ago
    I would not bad an eye. But at this point with records... I don't care. I declare a Integer 'bla' and a 'getBla()' is made available by the IDE right way. Sometimes the records fields end-up being accessible without the getter. ( declaring the record in another class for instance...). But that is also a moot point : all the data they are holding is final and I know what can be null or not.
  - stickfigure 4y ago
    I'm currently working in a Java codebase without Lombok and the habit is to make all fields public for record-like objects. It's fine 99% of the time. Every so often I want to change the behavior of something, and it's a big PITA. For example, maybe I'd like to ensure there's a default value for something that is sometimes null. If access was via getter method, I can just override the getter: class Foo { private final String name; public String getName() { return name == null ? "Default" : name; } } No need to change the hundreds of places that call .name or .getName(). This kind of thing happens often enough that it really should be baked into the language. Lo and behold, most post-Java languages support it, including C# and (modern) Javascript. Java is a bit stubborn in this regard, but Lombok solves the problem in a way that is almost language-native.
mmsimanga 4y ago
On a tangent from the article which discusses the Java the languae. I write SQL for a living and the one thing I like about Java based SQL clients like DBeaver [0], SQL Workbench/J[1] and SQuirreL SQL [2] is that they tend to support most databases that have a JDBC driver. Turns out most databases do have a JDBC driver. So if you want to connect to "new" database like DuckDb to Oracle, SQL Server and even CSV files using one client JDBC client is one way to do it. The steps to connect to a JDBC database tend to be very simple and the same for all databases. Get the driver jar file, put it in the classpath and then use the documented connection string to connect to the database. If you only work with SQL Server then it is probably best you use SQL Server Management Studio. If you use different databases you will need a different client and I find with JDBC based clients you can use one client for to connect to many databases. I have seen many here complain that the Java tools are slow and bloated and look ancient. From a looks perspective you can use FlatLaf themes which look good to me. There are some nice dark themes to chose from. [0] https://dbeaver.io/ https://dbeaver.io/ [1] https://www.sql-workbench.eu/ https://www.sql-workbench.eu/ [2] https://github.com/squirrel-sql-client https://github.com/squirrel-sql-client
- ithrow 4y ago
  It's also very nice that the postresql project maintains a high quality JDBC driver https://jdbc.postgresql.org/ https://jdbc.postgresql.org/ Working with pg in nodejs was frustrating in comparison.
DogLover_ 4y ago
Started my career with Java and I will never work with it again. It is mostly the culture around Java. Most Java code is verbose to an extreme but the devs themself will say it makes the code readable. They will say the language is functional because of lambdas but anyone that has used a functional programming language will know that it feels nothing like it, again because of its verbosity. It is so complex that you can't really work with it without having to use an IDE.
- sandGorgon 4y ago
  i totally hear you. i have faced this issue on /r/java a lot. Especially the conceptual overhead of DAO/DTO, etc seems very religious in nature.
  - seer-zig 4y ago
    How do you suggest getting rid of DAO/DTO? This has nothing to do with Java, but with the domain at hand. I worked on several golang projects where protobuf was used, and the same dichotomy showed up in the code. There were three types even, protobuf types, internal types, and DB types, with manual mappers and validators having to be written between them. Quite a bad, verbose, and error prone experience, especially that golang itself is quite verbose.
    - sandGorgon 4y ago
      here's my thought - and ill be the first to admit that i may not be correct. its the front loading of a huge number of patterns which ends up being the barrier. An argument is made for "future proofing". Its not unlike Python whitespace indentation or golang's unused variables restriction. But the design pattern complexity is far more harder than all these things. There is a certain degree of complexity when all of this starts making sense. Or maybe do what Redux did ... and abstract everything out to somewhere else.
  - vips7L 4y ago
    Currently working on a project that doesn't use DAO's or DTO's it's horrendous, I wouldn't give up proper view models for anything now.
Supermancho 4y ago
Problems I still have with Java: "new" keyword is basically introducing side effects, everywhere, making Java more difficult to test and confusing generations about how to do testing. The primitive/object combination of int/Integer, et al is noise. The reliance on annotations for modern development and the reluctance to put syntax in the language to codify obvious things. Basically requiring a pre-processing language (Spring) to do basic tasks, making development slower and more error prone. The final keyword. The idea that you should sometimes take away developer agency, because you know the future, better than anyone. Classy. The combination of Class Access Modifiers (which are for mixin property selection) with interface definition (what's this object's interface?). The much acclaimed "java ecosystem" reinforces bad practices. 10 years later, PHP is derided for bad language choices but bad Java is handwaved as a series of missteps that has been corrected.
- mrkeen 4y ago
  "new" keyword is basically introducing side effects, everywhere, I don't think that's what it does. Unless you're talking about putting side effects into the constructor? confusing generations about how to do testing. Doesn't follow from the first part. The primitive/object combination of int/Integer, et al is noise. Somewhat agree. The reliance on annotations for modern development Sure, the Spring ones are horrible, but the Lombok and Jackson ones are pretty decent. put syntax in the language to codify obvious things What new syntax would you want? I guess I'd want to clean up the flatMap mess with some nice do-notation and <- arrows. The final keyword. The idea that you should sometimes take away developer agency, because you know the future, better than anyone. Classy. Final as a method keyword? Fair enough, but I don't think I've ever come across a method that I wanted to override but couldn't (I hate inheritance).. Final is also to try to make things immutable, but making things immutable in Java also takes more care than it should. The combination of Class Access Modifiers (which are for mixin property selection) with interface definition (what's this object's interface?). I don't get this at all. The much acclaimed "java ecosystem" reinforces bad practices. 10 years later, PHP is derided for bad language choices but bad Java is handwaved as a series of missteps that has been corrected. Maybe the language, not the ecosystem?
LennyWhiteJr 4y ago
> Checked exceptions are optional. But they're one of the BEST features in Java. No > So much code fails unexpectedly. When you want to build a professional application you need to handle every error. Yes > Checked exceptions help you avoid that nonsense. Wrong > People hate checked exceptions because of laziness. Java guards you against yourself. Wrong Java checked exceptions are almost universally regarded as being a mistake because they don't actually solve the problem they were meant to solve, and they make the code extremely hard to work with. See this post from Roman Elizarov: https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07 https://elizarov.medium.com/kotlin-and-exceptions-8062f589d0...
deleted 4y ago
[deleted]
cletus 4y ago
I couldn't disagree more with the point about checked exceptions. Pretty much everyone else has essentially agreed that checked exceptions were a mistake. They leak implementation details and/or pollute your interface. Practically speaking, they don't force you to deal with exceptions. They force you to catch them. Anyone who has done Java in the real world has encountered: try { // do stuff } catch (SomeException e) { // do nothing, maybe log it } I strongly agree the verbosity is a non-issue. Any modern IDE just fills this in for you. Yes more verbose syntax for getters/setters would be nice but it's not a big deal. But there's one point I wanted to highlight. Every language that comes after Java should've learned Java's lessons and some didn't. C# quite famously did. C# really is Java 2.0. No checked exceptions, reified generics (rather than type erasure) and some cool stuff too (eg LINQ, partial classes). Other languages (eg Go, Rust) largely moved away from exceptions entirely. Personally I agree with this. Exceptions are a false economy that devolve into control flow that's hard to follow (eg Java has a parse number from string that throws a ParseException if the parsing fails and that's just not an exception). But the big one is dependencies. Every external dependency system that came after Mavaen should be at least as good and many aren't. I'm looking at you, Go. This was a shocking omission for something aimed at being a better systems programming language (which it never would be as a GC language but that's another story). But Java is proven, mature and sufficient. That's why it's still used.
- ars 4y ago
  Yah, I've always felt that the "checked" should not have been part of the exception type, rather it should have been part of the throw: throw checked new Exception(); Then the caller knows there is a special reason to handle this exception, and it's also easy to write a tiny wrapper to neutralize the check, if needed. For example: failure to open a file could be nothing major in one case (just return null), needs to be handled in another, or should cause the entire application to exit. This depends on what file was opened - but it does NOT depend on the type of error.
- shlurpy 4y ago
  Rusts error handling is almost identical to checked exceptions in practice. The reason it works is because there is no real equivalent to easily handle-able unchecked exceptions, and because macros and sum types make it very easy to wrap a lower level error in your higher level error and rethrow. Basically, checked exceptions could have worked, if they were the only type, and had better ergonomics of use, and a language culture that emphasized correctness more. Checked exceptions were wrong for Java, but that does not mean they are wrong universally.
binkHN 4y ago
> The nice thing is that the JVM is a big tent. If you aren't a fan of Java, Kotlin or Scala might suit your taste. This is his conclusion, and I, well, agree. While I was well versed in Java, once I started playing around with Kotlin (which was around the time Java was stagnating), I never really looked back.
- sandGorgon 4y ago
  are u happy with the state of frameworks (like spring, etc). not necessarily the language java or kotlin. Because coming from the flask, go, jsapi ecosystem...it was very hard for me to be productive in the jvm world (kotlin or java), cos of the frameworks.
  - binkHN 4y ago
    This is not an area I work with much. That said, I feel this area is still in its infancy and I’ve only played around with the very simple Ktor. But from a language aspect alone, I’m just so much more productive when cranking out code in Kotlin compared to Java.
seer-zig 4y ago
The JVM is really a marvel of engineering. I have yet to see another system that offers what it does in terms of performance, GC tunability, observability, monitoring, profiling, etc. .NET is the only thing that comes close, but it has a ways to go in terms of what the JVM is capable of. Java the language is really coming along nicely. With records, pattern matching, string templates, virtual threads, value types (in the work), and more, it's shaping up to be a top notch development language.
someweirdperson 4y ago
> the difference between get() and [] is literally three characters x.get(y) x[y] I'm counting 4 charcters.
bArray 4y ago
These are not the reasons I like Java at all (I still use Java 8). My reasons are: 1. C-like language - Flip between C, C++, Java and JS with minimal thinking about syntax. 2. Build once - I can build locally and deploy the byte code straight to production. I don't need to worry about the production server having the right packages as long as everything is bundled in my JAR. 3. Libraries just work (mostly) - It doesn't matter if the library was written yesterday or 10 years ago, as long as it was written sanely, it should just work. 4. Garbage collector - Really in top class. I can create and throw away huge amounts of RAM and not have to worry about leaks and have it dealt with realitively little performance impact. 5. Memory safety - Never having to worry about pointers, segmentation faults, etc. 6. Exception handling - And if all else fails, Java will ultimately give you the opportunity to recover from many different scenarios. This may seem like lazy programming, but actually it's for the edge cases you can't think of. If your program does happen to crash, you get a very good stack trace. Java may be cumbersome and repetitive is some areas (and perhaps the newer additions to the language deal with this), but I would take them every day of the week. The only thing that has really left me wanting is C-like performance and networking capabilities. Most other things I want to use are very well implemented.
- kaba0 4y ago
  > The only thing that has really left me wanting is C-like performance Well, it is basically there in hot loops. Not necessarily with idiomatic Java, you do have to use primitives but it is absolutely achievable. Also, what do you lack with regards to networking?
  - bArray 4y ago
    > Well, it is basically there in hot loops. Not necessarily with idiomatic Java, you do have to use primitives but it is absolutely achievable. Not quite in my opinion. Not bad, but it can be half performance at times. > Well, it is basically there in hot loops. Not necessarily with idiomatic Java, you do have to use primitives but it is absolutely achievable. Setting more intricate TCP settings, or sending ICMP, or essentially anything advanced.
deepsun 4y ago
One thing I still miss in JVM is bundling the app into one executable binary, like others do (Go, Nim, Rust). I don't mean AOT compilation like GraalVM does, just either bundling needed JVM modules like jlink does (aka static) or depend on local pre-installed JVM (aka dynamic). Yes, there's been jlink for a long time, but it still generates a folder, not a single file. There is jpackage, but it generates installers for various platforms, not an executable binary.
- ivanche 4y ago
  I know it's a 3rd-party tool, but maybe JBang[0] can help you? [0] https://www.jbang.dev/ https://www.jbang.dev/
  - deepsun 4y ago
    Thanks, but it seems to run .java files, doesn't produce any binary either. I mean it's cool, just not what I meant (executable binary).
lamontcg 4y ago
> The fact that operators can't be overloaded is a HUGE benefit. Not if you're trying to work with other algebraic data types. > If I see a + b I know that this is either a string or a number not some hidden method. Great if your world only consists of numbers and strings. And really in this day and age with strongly typed languages your IDE should be able to easily tell you if someone is doing something totally insane with any given operator. In most cases, they won't be and it'll be easy to decipher exactly what they mean. Stop trying to prevent everyone from being able to do useful things just because some people write crappy code that abuses language features.
smitty1e 4y ago
Scalability, portability, and consistency. Doing more work at scale these days and running into Elasticsearch, NiFi, and so forth. I don't have to like the fact that java has to have its own keystore, and that the elasticsearch.service invocation has 35 (!) arguments by the time it reaches its launch. But these enterprise tools provide a methodology for getting granular when it makes sense.

54 points by saikatsg 4y ago

deleted 4y ago

[deleted]

Unfortunately one of the examples used in the article introduces an SQL injection attack vector. Don't build parametrized SQL out of Strings.

invalidname 4y ago
That's from here: https://openjdk.org/jeps/8273943 https://openjdk.org/jeps/8273943 It doesn't. That's not a plain string replacement...
littlestymaar 4y ago
And email validation is done with a regex… This low-effort post really doesn't deserve the front page…
- invalidname 4y ago
  This was copied from the original article linked by this article...
- edp 4y ago
  This was code from another article, linked in the introduction.
- ipaddr 4y ago
  How would you do it
  - papercrane 4y ago
    Check that its a string containing '@' with at least one character before and after the @ symbol is usually the only sensible thing to do. The format for emails is surprisingly complex, and while you can use a regex to catch 99% of the right values, it's very difficult to get it 100% right. Often the best thing to do is just to try and send an email to the address a validation link.
    - __ryan__ 4y ago
      Check that its a string containing '@' with at least one character before and after the @ symbol is usually the only sensible thing to do. This is exactly what the regex in the example is doing.
      - papercrane 4y ago
        The regex is ^[^@\s]+@\S+$ This would reject valid email addresses using quoted parts like john."@".doe@valid.example. Edit: Looking at it closely it looks like the attempt is to reject anything with an '@' in the user part, which would be an error (e.g. john."@".doe@valid.example). Except since "\S+" also includes '@' this regex will still work, but by accident. It would reject the valid email john."\ ".doe@valid.example
        __ryan__ 4y ago
        I don't think that's true. In JS: /^[^@\s]+@\S+$/.test("john.\"@\".doe@valid.example") == true Edit: Hmm, I see what you mean. At first glance I thought it was just checking that it didn't start with @ or whitespace.
        papercrane 4y ago
        Sorry, I edited my comment and then noticed you replied already. It's working by accident since the '\S+' will match the second '@', but if you had a quoted space in the user it would not work e.g. john."\ ".doe@valid.example, but would work with john.@.doe@invalid.example which I believe the regex is author meant to be caught as invalid.
  - littlestymaar 4y ago
    Two options: - use a library that implements RFC 5322 properly. - don't validate the email address (that is, don't try to reject most invalid addresses) and just check that the field contains at least one `@` to be sure the user didn't enter something else than his email address by accident. Tying to perform email address validation with regex you're writing yourself is the best way to reject perfectly acceptable email address and get frustrated users.
  - mrkeen 4y ago
    Parse, don't validate. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
jerven 4y ago
I think you are talking about this example: ResultSet rs = DB."SELECT * FROM Person p WHERE p.last_name = \{name}"; This when it becomes valid java will not allow an SQL injection attack. The name part would be properly passed as a parameter. Not a string concatenation. Per https://openjdk.org/jeps/430 https://openjdk.org/jeps/430 If that was not the example you where thinking about, sorry :) Otherwise yes don't build parameterized SQL out of strings !
- drdec 4y ago
  Thanks for the correction
- jhhh 4y ago
  My main complaint about this new feature is that it has such poor conceptual clarity that people already familiar with Java will almost always misinterpret what is happening in exactly the same way. I've seen people post similar comments to the one you're correcting on reddit as well.
__ryan__ 4y ago
You are thinking of string interpolation. The idea behind string templates, the feature the example is showcasing, is effectively a way to define a function that can be called with similar syntax to string interpolation. So DB."SELECT * FROM Person p WHERE p.last_name = \{name}" would basically be a function call like DB("SELECT * FROM Person p WHERE p.last_name = ", name), which would do the right thing to parameterize the SQL.
jbverschoor 4y ago
So you're talking about a preview/beta/new feature (TemplatedString), and use that as the reason it's "still" popular?
- __ryan__ 4y ago
  First of all, yes, new features alone can make something maintain popularity. Why would that not be the case? Second, the author was using that as an example of Java showing a pattern of adding syntax improvements, which again might be something that maintains popularity. Finally, from the article: But let's talk about the Java we have today, not the one coming in 6 months. It was just one talking point. Did you even read the article?

phaedryx 4y ago

It's interesting what "popular" can mean. Chances are the "popular" kids in your high school weren't necessarily well liked, they just had social clout. Where I work now the the "Java" devs code about 80% Kotlin and 20% Java. At my previous job we were mostly Ruby except for a service that relied on a Java library that connected to some obscure systems that no other language had a library for. Yeah, we used Java, but it was because that was our only option.

tester756 4y ago
>Where I work now the the "Java" devs code about 80% Kotlin and 20% Java. That reflects my experience Java devs seem to be moving to Kotlin, or as some would say JetBrain's C# hehe
LennyWhiteJr 4y ago
Yup, I work at Amazon and my team along with many surrounding teams are only coding in Kotlin from this point on. The JVM and its ecosystem brings insane value to the table, and Kotlin lets you take all the benefits while removing most of the downsides of Java.
- gorjusborg 4y ago
  I agree with you, but I haven't had good ling term experiences with hosted languages. I hope it works out for you.
  - Kwpolska 4y ago
    Can you clarify? What didn't work out, which languages were involved?
- sandGorgon 4y ago
  why is this ? i have worked on kotlin in the android ecosystem. But something like kotlin with spring is no better than java right ? you still have to deal with all the controllers, etc. on reddit, one of the arguments was interesting - the biggest value of kotlin in backend is using var/val instead of types and making everything public (instead of getters/setters). would that be correct ? Lombok doesnt fix this ?

rad_gruchalski 4y ago

The post is missing to mention the ecosystem.

etchalon 4y ago

"Popular" and "still used a lot" are two very different ideas.

avmich 4y ago
I think terminology of the author is such that they are synonyms.

ravirajx7 4y ago

The main reason behind Java's success has always been the community and it's ecosystem. Once you learn basics you literally can code very good things with ease using a huge number of examples/solutions present on web. The user base kind of helps the developers find the fixes way too easily compared to any other language. I doubt it is ever going to lose it's popularity as Java is very good to accept good changes(although slowly). The best thing about java is it provides code stability and backward compatibility and this is the reason it will thrive even more.

adam_arthur 4y ago
Java can get the job done, but the language is certainly dated in a way that's impossible to fix without breaking changes. Similar to C++ getting replaced by go and rust everywhere, Java's time has gone. It's just running on momentum at this point. The JVM will likely continue on though
- qsort 4y ago
  Java is still 95%+ of the marketshare of the JVM. Also "C++ being replaced by go and rust everywhere" is very much hyperbolic. You are either wildly exaggerating or living in a bubble.
  - adam_arthur 4y ago
    C++ still exists because existing projects were written in it... that's it. There's no value in using it for future projects other than a wider pool of developers to source from... a network effect that will diminish with time. Java is objectively dated in so many ways, it's not really defensible to say otherwise. Tons of unnecessarily verbose and boilerplate aspects of the language.
    - toxik 4y ago
      That is a very bold claim from basically zero evidence, on both accounts but especially C++ being a zombie language.

sandGorgon 4y ago

I have a question for those of you who have worked on java..or considered working on java ..and ultimately did golang or something. what would make you choose java : 1. is it a better framework than spring boot 2. is it a better tooling like heroku or something for java 3. is it better community & programming paradigms ? I once asked a question "can i write a java api using all variables as public" and got flamed pretty badly. Do people want an alternative to the MVC/DAO/DTO structure ...where the community doesnt flame them ? 4. is it something else ? Because based on docker pulls, java still is probably just as popular as nodejs or something. what would make java sexy again ?

zaphar 4y ago
I'm excited about value types. I'm less than enthused by the spring ecosystem. It does help you start quicker than you would without it but while running it in production over time I think it has costs I'd rather not pay so I suppose a better framework would excite me too. Java as a language is fine and I have no real complaints there.
- sandGorgon 4y ago
  >while running it in production over time I think it has costs I'd rather not pay so I suppose a better framework would excite me too. can you elaborate on this ? really have been considering spring boot, etc. But coming from the python world ...i feel it cognitively very hard to get through. But im super keen to know what issues come in production. Most of us were under the impression that Spring in production just works. >so I suppose a better framework would excite me too especially from this perspective. What would you want ?
  - zaphar 4y ago
    My complaint about spring is the same complaint I have about almost every runtime dependency injection framework. In the happy path everything just works. But when you get off that happy path which happens all the time in production for any system older than a month you get exceptions and those exceptions list stuff in the stack trace that you've never seen and didn't even know were being used. For those issues every once in a while when you try to dig into the error you find yourself deep into runtime reflection code somewhere trying to figure out how this particular configuration happened. How your code got glued together is a mass of difficult to read code buried deep in the spring framework. We have a saying about these types of frameworks: They are a great way to turn compile errors into runtime errors. When you are just starting out on a project it's great. You get up and running fast and as long as stuff doesn't change too much you are probably fine. But when your codebase reaches 5+ years of age it's highly likely to see a spike in "runtime errors" that potentially could have been compile time errors every time you release and releases get nerve wracking for a bit until eventually the codebase get's frozen in stone and someone starts suggesting we rewrite it.

deleted 4y ago

[deleted]

mrkeen 4y ago

Pretty disingenuous comparison in the Annotation section. The annotated version is more terse because he's showing its usage. For the non-annotation version he's showing the implementation. edit (because I forgot to quote the article directly): The syntax is more terse

invalidname 4y ago
The point wasn't that it's terse. The point was that the other version was inefficient and the system couldn't optimize the cost away or move it.

avmich 4y ago

> Maven central is MASSIVE with 27 terabytes of jars I think this is a bad approach. Developer should know his components, and adding one shouldn't be a frequent event.

Supermancho 4y ago
I'm not sure why the size of a shared code library is important. Adding components is about reusing code while replacing them is about having to track security issues (which is very good now, via maven) and new functionality being added (which you may or may not want). Same as NPM or any other package manager that existed.
- avmich 4y ago
  If you consider 27 TB a good thing, you to some degree invite code bloat. Libraries should be small and carefully designed.
  - invalidname 4y ago
    I would say they should be the "right size". 27TB isn't one library. It's the amount of libraries there are. In the NPM world there are too many small libraries that create a dependency graph that's impossible to parse mentally. No one knows your true dependencies and that created many problems. In Maven libraries are sometimes too big. That's true. But most of them are closer to the size that gives a library a bit of "meat". Obviously YMMV.
  - kaba0 4y ago
    27 TB is about the vast amount of choice in the ecosystem. Try to delete the node_modules folder vs the .m2 one on windows — only one of these chokes out a high-end laptop. In my experience Java dependency trees are not as absurdly deep as JS’s. Sure, frameworks do add quite a few nodes to the tree, but libs don’t have as many transitive deps as they do in JS, perhaps due to the better standard lib.

noelwelsh 4y ago

I don't care much for Java. However, if you want a performant GCed language with a top tier ecosystem JVM languages must be in contention and there aren't many other viable choices. WASM might shake this up in a few years. We'll see.

naranha 4y ago

Maven is a pretty horrible dependency manager. I would take NPM over it any day, because it is so much simpler. There is much less that can go wrong, while with maven you're fighting with the tooling all the time. pom.xml files are much larger than package.json files. While I can read and understand a package.json no problemo in a couple of seconds, with pom.xml files I'm completely lost for hours on end, even when I wrote them myself a while ago.

TedDoesntTalk 4y ago
maven predates NPM by probably 20 years. We've learned a lot about dependency managers collectively in that time. I'm sure if maven were rewritten today, it would be different.
- yesbabyyes 4y ago
  Six years; 2004 vs 2010.
- kaba0 4y ago
  NPM changed its model (more like fixed) several times during the few years it existed. They hardly learn anything.
Supermancho 4y ago
Why did I include this package B? Oh it addresses a security concern from a dependency of this other package A. Hope you put a comment there. Wait, there's a security issue with B also? Add another package C to deal with the security issue in B. That's just 1 aspect. Now let's munge in plugins and plugins of packages and it gets messy real fast. Outside of the outdated XML, is there a way to deal with these problems cleanly?
lordnacho 4y ago
The problem is also that there's several dependency managers in the ecosystem. You end up learning them all badly because some piece is only available in one or the other.
4y ago

yardstick 4y ago

> Java has been around for nearly 30 years and is still mostly compatible to Java 1.0. That is fantastic and unrivaled! I’ve been writing java code since about 2001 and up until Java 8 this was fairly true, and definitely a fantastic thing. However the leap from 8 to 11 or 17 (all LTS releases) is a painful process. We are moving from 8 to 17 at work, but the number of issues we run into with incompatible libraries is a right royal pain. Especially when it’s down to the (imo) silly decision to rename the java EE packages to jakarta. A pointless exercise (imo) that has held back a lot of organisations from upgrading sooner.

stickfigure 4y ago

There's some good, some bad here. Stuff he gets right: * Getters/setters is a nonissue * Operator overloading is a nonissue. I did like how Ceylon handled it (operators are aliases for normal spelled-out methods) but honestly overloading is not something I ever miss. And it was a minefield back in my C++ days. * Dependency management in Java is decent. It's worse in every other ecosystem I've encountered. Stuff he gets wrong: * Checked exceptions are horrid. The people who hate them aren't driven by laziness, they're driven by the desire to use standard interfaces - especially now that we have lambdas. You can use `Runnable`! Unless your code throws a checked exception... in which case you have to go through the ceremony of wrapping it. This is stupid. You can have standard interfaces, or you can have checked exceptions, and standard interfaces are vastly more useful.

sandGorgon 4y ago
genuine non flamy question here. why getters/setters. Most frameworks (and not languages) use everything public. Rails, React, golang's frameworks, flask/fastapi. Code has generally not suffered from being public. Would you not accept a Java framework with everything public ? i asked this question on /r/java some time back and got badly flamed. So im trying to understand this. This seems to very philosophical...but then most other frameworks in other languages dont carry this philosophy.
- courgette 4y ago
  I would not bad an eye. But at this point with records... I don't care. I declare a Integer 'bla' and a 'getBla()' is made available by the IDE right way. Sometimes the records fields end-up being accessible without the getter. ( declaring the record in another class for instance...). But that is also a moot point : all the data they are holding is final and I know what can be null or not.
- stickfigure 4y ago
  I'm currently working in a Java codebase without Lombok and the habit is to make all fields public for record-like objects. It's fine 99% of the time. Every so often I want to change the behavior of something, and it's a big PITA. For example, maybe I'd like to ensure there's a default value for something that is sometimes null. If access was via getter method, I can just override the getter: class Foo { private final String name; public String getName() { return name == null ? "Default" : name; } } No need to change the hundreds of places that call .name or .getName(). This kind of thing happens often enough that it really should be baked into the language. Lo and behold, most post-Java languages support it, including C# and (modern) Javascript. Java is a bit stubborn in this regard, but Lombok solves the problem in a way that is almost language-native.

mmsimanga 4y ago

On a tangent from the article which discusses the Java the languae. I write SQL for a living and the one thing I like about Java based SQL clients like DBeaver [0], SQL Workbench/J[1] and SQuirreL SQL [2] is that they tend to support most databases that have a JDBC driver. Turns out most databases do have a JDBC driver. So if you want to connect to "new" database like DuckDb to Oracle, SQL Server and even CSV files using one client JDBC client is one way to do it. The steps to connect to a JDBC database tend to be very simple and the same for all databases. Get the driver jar file, put it in the classpath and then use the documented connection string to connect to the database. If you only work with SQL Server then it is probably best you use SQL Server Management Studio. If you use different databases you will need a different client and I find with JDBC based clients you can use one client for to connect to many databases. I have seen many here complain that the Java tools are slow and bloated and look ancient. From a looks perspective you can use FlatLaf themes which look good to me. There are some nice dark themes to chose from. [0] https://dbeaver.io/ https://dbeaver.io/ [1] https://www.sql-workbench.eu/ https://www.sql-workbench.eu/ [2] https://github.com/squirrel-sql-client https://github.com/squirrel-sql-client

ithrow 4y ago
It's also very nice that the postresql project maintains a high quality JDBC driver https://jdbc.postgresql.org/ https://jdbc.postgresql.org/ Working with pg in nodejs was frustrating in comparison.

DogLover_ 4y ago

Started my career with Java and I will never work with it again. It is mostly the culture around Java. Most Java code is verbose to an extreme but the devs themself will say it makes the code readable. They will say the language is functional because of lambdas but anyone that has used a functional programming language will know that it feels nothing like it, again because of its verbosity. It is so complex that you can't really work with it without having to use an IDE.

sandGorgon 4y ago
i totally hear you. i have faced this issue on /r/java a lot. Especially the conceptual overhead of DAO/DTO, etc seems very religious in nature.
- seer-zig 4y ago
  How do you suggest getting rid of DAO/DTO? This has nothing to do with Java, but with the domain at hand. I worked on several golang projects where protobuf was used, and the same dichotomy showed up in the code. There were three types even, protobuf types, internal types, and DB types, with manual mappers and validators having to be written between them. Quite a bad, verbose, and error prone experience, especially that golang itself is quite verbose.
  - sandGorgon 4y ago
    here's my thought - and ill be the first to admit that i may not be correct. its the front loading of a huge number of patterns which ends up being the barrier. An argument is made for "future proofing". Its not unlike Python whitespace indentation or golang's unused variables restriction. But the design pattern complexity is far more harder than all these things. There is a certain degree of complexity when all of this starts making sense. Or maybe do what Redux did ... and abstract everything out to somewhere else.
- vips7L 4y ago
  Currently working on a project that doesn't use DAO's or DTO's it's horrendous, I wouldn't give up proper view models for anything now.

Supermancho 4y ago

Problems I still have with Java: "new" keyword is basically introducing side effects, everywhere, making Java more difficult to test and confusing generations about how to do testing. The primitive/object combination of int/Integer, et al is noise. The reliance on annotations for modern development and the reluctance to put syntax in the language to codify obvious things. Basically requiring a pre-processing language (Spring) to do basic tasks, making development slower and more error prone. The final keyword. The idea that you should sometimes take away developer agency, because you know the future, better than anyone. Classy. The combination of Class Access Modifiers (which are for mixin property selection) with interface definition (what's this object's interface?). The much acclaimed "java ecosystem" reinforces bad practices. 10 years later, PHP is derided for bad language choices but bad Java is handwaved as a series of missteps that has been corrected.

mrkeen 4y ago
"new" keyword is basically introducing side effects, everywhere, I don't think that's what it does. Unless you're talking about putting side effects into the constructor? confusing generations about how to do testing. Doesn't follow from the first part. The primitive/object combination of int/Integer, et al is noise. Somewhat agree. The reliance on annotations for modern development Sure, the Spring ones are horrible, but the Lombok and Jackson ones are pretty decent. put syntax in the language to codify obvious things What new syntax would you want? I guess I'd want to clean up the flatMap mess with some nice do-notation and <- arrows. The final keyword. The idea that you should sometimes take away developer agency, because you know the future, better than anyone. Classy. Final as a method keyword? Fair enough, but I don't think I've ever come across a method that I wanted to override but couldn't (I hate inheritance).. Final is also to try to make things immutable, but making things immutable in Java also takes more care than it should. The combination of Class Access Modifiers (which are for mixin property selection) with interface definition (what's this object's interface?). I don't get this at all. The much acclaimed "java ecosystem" reinforces bad practices. 10 years later, PHP is derided for bad language choices but bad Java is handwaved as a series of missteps that has been corrected. Maybe the language, not the ecosystem?

LennyWhiteJr 4y ago

> Checked exceptions are optional. But they're one of the BEST features in Java. No > So much code fails unexpectedly. When you want to build a professional application you need to handle every error. Yes > Checked exceptions help you avoid that nonsense. Wrong > People hate checked exceptions because of laziness. Java guards you against yourself. Wrong Java checked exceptions are almost universally regarded as being a mistake because they don't actually solve the problem they were meant to solve, and they make the code extremely hard to work with. See this post from Roman Elizarov: https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07 https://elizarov.medium.com/kotlin-and-exceptions-8062f589d0...

deleted 4y ago

[deleted]

cletus 4y ago

I couldn't disagree more with the point about checked exceptions. Pretty much everyone else has essentially agreed that checked exceptions were a mistake. They leak implementation details and/or pollute your interface. Practically speaking, they don't force you to deal with exceptions. They force you to catch them. Anyone who has done Java in the real world has encountered: try { // do stuff } catch (SomeException e) { // do nothing, maybe log it } I strongly agree the verbosity is a non-issue. Any modern IDE just fills this in for you. Yes more verbose syntax for getters/setters would be nice but it's not a big deal. But there's one point I wanted to highlight. Every language that comes after Java should've learned Java's lessons and some didn't. C# quite famously did. C# really is Java 2.0. No checked exceptions, reified generics (rather than type erasure) and some cool stuff too (eg LINQ, partial classes). Other languages (eg Go, Rust) largely moved away from exceptions entirely. Personally I agree with this. Exceptions are a false economy that devolve into control flow that's hard to follow (eg Java has a parse number from string that throws a ParseException if the parsing fails and that's just not an exception). But the big one is dependencies. Every external dependency system that came after Mavaen should be at least as good and many aren't. I'm looking at you, Go. This was a shocking omission for something aimed at being a better systems programming language (which it never would be as a GC language but that's another story). But Java is proven, mature and sufficient. That's why it's still used.

ars 4y ago
Yah, I've always felt that the "checked" should not have been part of the exception type, rather it should have been part of the throw: throw checked new Exception(); Then the caller knows there is a special reason to handle this exception, and it's also easy to write a tiny wrapper to neutralize the check, if needed. For example: failure to open a file could be nothing major in one case (just return null), needs to be handled in another, or should cause the entire application to exit. This depends on what file was opened - but it does NOT depend on the type of error.
shlurpy 4y ago
Rusts error handling is almost identical to checked exceptions in practice. The reason it works is because there is no real equivalent to easily handle-able unchecked exceptions, and because macros and sum types make it very easy to wrap a lower level error in your higher level error and rethrow. Basically, checked exceptions could have worked, if they were the only type, and had better ergonomics of use, and a language culture that emphasized correctness more. Checked exceptions were wrong for Java, but that does not mean they are wrong universally.

binkHN 4y ago

> The nice thing is that the JVM is a big tent. If you aren't a fan of Java, Kotlin or Scala might suit your taste. This is his conclusion, and I, well, agree. While I was well versed in Java, once I started playing around with Kotlin (which was around the time Java was stagnating), I never really looked back.

sandGorgon 4y ago
are u happy with the state of frameworks (like spring, etc). not necessarily the language java or kotlin. Because coming from the flask, go, jsapi ecosystem...it was very hard for me to be productive in the jvm world (kotlin or java), cos of the frameworks.
- binkHN 4y ago
  This is not an area I work with much. That said, I feel this area is still in its infancy and I’ve only played around with the very simple Ktor. But from a language aspect alone, I’m just so much more productive when cranking out code in Kotlin compared to Java.

seer-zig 4y ago

The JVM is really a marvel of engineering. I have yet to see another system that offers what it does in terms of performance, GC tunability, observability, monitoring, profiling, etc. .NET is the only thing that comes close, but it has a ways to go in terms of what the JVM is capable of. Java the language is really coming along nicely. With records, pattern matching, string templates, virtual threads, value types (in the work), and more, it's shaping up to be a top notch development language.

someweirdperson 4y ago

> the difference between get() and [] is literally three characters x.get(y) x[y] I'm counting 4 charcters.

bArray 4y ago

These are not the reasons I like Java at all (I still use Java 8). My reasons are: 1. C-like language - Flip between C, C++, Java and JS with minimal thinking about syntax. 2. Build once - I can build locally and deploy the byte code straight to production. I don't need to worry about the production server having the right packages as long as everything is bundled in my JAR. 3. Libraries just work (mostly) - It doesn't matter if the library was written yesterday or 10 years ago, as long as it was written sanely, it should just work. 4. Garbage collector - Really in top class. I can create and throw away huge amounts of RAM and not have to worry about leaks and have it dealt with realitively little performance impact. 5. Memory safety - Never having to worry about pointers, segmentation faults, etc. 6. Exception handling - And if all else fails, Java will ultimately give you the opportunity to recover from many different scenarios. This may seem like lazy programming, but actually it's for the edge cases you can't think of. If your program does happen to crash, you get a very good stack trace. Java may be cumbersome and repetitive is some areas (and perhaps the newer additions to the language deal with this), but I would take them every day of the week. The only thing that has really left me wanting is C-like performance and networking capabilities. Most other things I want to use are very well implemented.

kaba0 4y ago
> The only thing that has really left me wanting is C-like performance Well, it is basically there in hot loops. Not necessarily with idiomatic Java, you do have to use primitives but it is absolutely achievable. Also, what do you lack with regards to networking?
- bArray 4y ago
  > Well, it is basically there in hot loops. Not necessarily with idiomatic Java, you do have to use primitives but it is absolutely achievable. Not quite in my opinion. Not bad, but it can be half performance at times. > Well, it is basically there in hot loops. Not necessarily with idiomatic Java, you do have to use primitives but it is absolutely achievable. Setting more intricate TCP settings, or sending ICMP, or essentially anything advanced.

deepsun 4y ago

One thing I still miss in JVM is bundling the app into one executable binary, like others do (Go, Nim, Rust). I don't mean AOT compilation like GraalVM does, just either bundling needed JVM modules like jlink does (aka static) or depend on local pre-installed JVM (aka dynamic). Yes, there's been jlink for a long time, but it still generates a folder, not a single file. There is jpackage, but it generates installers for various platforms, not an executable binary.

ivanche 4y ago
I know it's a 3rd-party tool, but maybe JBang[0] can help you? [0] https://www.jbang.dev/ https://www.jbang.dev/
- deepsun 4y ago
  Thanks, but it seems to run .java files, doesn't produce any binary either. I mean it's cool, just not what I meant (executable binary).

lamontcg 4y ago

> The fact that operators can't be overloaded is a HUGE benefit. Not if you're trying to work with other algebraic data types. > If I see a + b I know that this is either a string or a number not some hidden method. Great if your world only consists of numbers and strings. And really in this day and age with strongly typed languages your IDE should be able to easily tell you if someone is doing something totally insane with any given operator. In most cases, they won't be and it'll be easy to decipher exactly what they mean. Stop trying to prevent everyone from being able to do useful things just because some people write crappy code that abuses language features.

smitty1e 4y ago

Scalability, portability, and consistency. Doing more work at scale these days and running into Elasticsearch, NiFi, and so forth. I don't have to like the fact that java has to have its own keystore, and that the elasticsearch.service invocation has 35 (!) arguments by the time it reaches its launch. But these enterprise tools provide a methodology for getting granular when it makes sense.