61–70 of 153 posts
* IntelliJ
* Standard enterprise Java JEE 9.1 (JSP, JPA, EJB)
* Payara app server
* Twitter Bootstrap
* Maven
* Test driven development using TestNG + AssertJ
* Postgres + Liquibase for schema management
Code samples now come from https://www.baeldung.com/
* Use SDKMan for runtime and sdk management https://sdkman.io/ * Try to use Kotlin where allowed (Maybe unpopular and bad faith response given that you asked about Java, but I don't care -- kotlin's Java interop is way more seamless than Scala or Clojure to the point that its often not even noticable) https://kotlinlang.org/ * IntelliJ * Spring is pretty popular, I've seen a lot of people using Vertx * Square librari…
Okio is very nice, and Okhttp is quite ergonoic, but I can't recommend Okhttp if true async is on the table (it's just blocking and threadpools under the covers).
The stack I've seen, used and liked at many clients is: Spring Boot, Kotlin, IntelliJ. Which of course means all the old discussions: Jetty/Tomcat/JBoss/GlassFish, GSON/Jackson, Hikari/C3PO/etc, etc are now mostly moot, since most just use the Boot defaults until they need something else. Kinda nice, actually. Less bikeshedding, can get a project up and running without taking a stand on all these things. Most clients…
Yes. Perhaps to add to this, use a modern asynchronous IO framework. If you use Spring Boot, ignore some of the legacy stuff that still comes with it and make sure you use webflux with Kotlin co-routines. Also use Asynchronous IO for talking to your database, queues, etc. Kotlin makes all of this easy. Hibernate is something I tend to avoid for various reasons but apparently recent versions of that now also support a…
As for Hibernate, I've seen a trend of using ORMs less and less. And if it's used, it's in a simple dao layer so that the rest of the application doesn't have to deal with how data is fetched.
Earlier quoted context omitted.
Java is on thin ice? It's the most popular business language, for good reason. You seem to have some very odd opinions, but that's fine. Bit rude to call people other people their opinions a "vendetta", though.
The reason I'm being terse with you and perhaps a bit rude is that you started this reply thread by insulting my opinions for no reason and then continued to reply with what I believe to be both bad faith readings of my comments and naturally argumentative. I know HN values skepticism, but honestly it's tiresome. Anyways, here's my clarifying my previous comment. Please keep in mind that I fully expect you to read th…
For backend frameworks, I'd look at Quarkus [1] or Micronaut [2]. Both are geared towards configuration, async processing and native compilation, along with a ton of options to integrate with external systems. For something a bit lighter weight, Vert.x [3] is a good option (Quarkus is based on it). [1] - https://quarkus.io/ [2] - https://micronaut.io/ [3] - https://vertx.io/ You'll need Java 1.8+, and Maven or Gradle…
There's no reason to use 10 years old version of Java. Use 17.
IntelliJ idea is the best IDE. JDK8 incorporated a lot of great functional programming ideas (though the streams library is awful.). Up through JDK17 there are many improvements including a more scalable runtime. I haven’t been paid to work with Spring since 2013, every project I’ve worked on since has used Guice, maybe Dropwizard. JAX-RS is the dominant paradigm for web back ends these days, particularly if you are…
I think the Streams designers did an amazing job. One of my favorite things about modern Java. Yes, it's more verbose than Python list comprehensions, but it's both higher-performance (parallelism that just works) and more productive (static typing means it almost always works as intended the first time).
The work stealing mechanism used by streams doesn't really work. Frequently I've seen people get something like a 1.7x speedup on an 8 core machine and was able to get a 7.8x speedup on the same machine using a ThreadPoolExecutor.
For common "embarrassingly parallel" problems there are two parameters you need to set: (1) How many threads to use, and (2) How fine to subdivide the problem.
Often the basic work unit takes much less time to complete than the time it takes to switch between threads. For instance a raytracer can probably trace one ray in less than the time it takes to communicate between threads. If you try to parallelize a task with too fine a granularity you get a slowdown not a speedup. You might find you get a good speedup over a fairly wide range of granularities (you might do well with anywhere between 100 and 10,000 rays) but batching of some kind is essential.
As for the thread count it depends on if the job is CPU bound. A CPU bound job needs about as many threads as you have cores or SMT "threads". If the job is I/O bound you usually need many more threads to maximize performance, but it's tricky. A web crawler might be able to support 100's or 1000's of threads but if you point all those threads at one server you might crash it, get banned, or both.
If the awkward streams API bought you good performance and reliability (let's see... just about zero support for error handling) that would be one thing but it doesn't.
Static typing working so well is not a special feature of the streams API but rather one of the rather brilliant engineering that went into JDK 8. You can easily write your own "map()" functions and other higher-order functions that do many of the things the Stream API does.
It would really be nice to see a better third-party API.
Earlier quoted context omitted.
Okio is very nice, and Okhttp is quite ergonoic, but I can't recommend Okhttp if true async is on the table (it's just blocking and threadpools under the covers).
Admittedly it's been awhile since I've written Java, so most of this is what I remember and what I've seen successful teams using -- got any links to a "true async" in Java? I was under the impression that all Java async work was backed by thread pools.
https://openjdk.java.net/jeps/321
https://github.com/AsyncHttpClient/async-http-client
https://hc.apache.org/httpcomponents-client-5.1.x/examples-a...
IDE: IntelliJ IDEA https://www.jetbrains.com/idea/ Nothing else seems to come close, they have a Community version, nowadays Eclipse and NetBeans both feel slow but Visual Studio Code with Java plugins lacks refactoring abilities one might expect in an IDE for non-trivial projects. Also, if you get the Ultimate package of their tools, you get all sorts of other useful tools, personally i also enjoy WebStorm and DataG…
> Nothing else seems to come close, they have a Community version, nowadays Eclipse and NetBeans both feel slow After not using Eclipse for 10 years, I had to use it again last month for a very large existing project. I was pleasantly surprised. It felt faster than IntelliJ.
Earlier quoted context omitted.
I am using it now because the team is using it, but cant figure out in which way it is supposed to be better then Eclipse. It looks somehow better, but it seems strictly inferior in terms of what it does for me.
I'm very curious to hear what Eclipse does that IntelliJ does not match.
Intellij does that a little bit of incremental compilation. They half integrated the eclipse Java compiler at some point but they never really made using it a thing. Most projects just hand off compilatio to Gradle or maven, which means you lose a lot of time waiting for that and dealing with various caches in intellij and gradle/maven getting out of sync with each other. The process for fixing that generally involves boiling the oceans and running the CPU at 400% for a few minutes.
Eclipse compiles two orders of magnitudes faster when you have it properly setup. I'm not exaggerating. It's really good at this. Intellij users have never seen this level of performance. I've tried to explain it a few times to users that insisted they had intellij configured just right. The minimum execution for a unit test after a 1 character code change is the key benchmark for this. Run a test, change something trivial, run it again. If that takes more than half a second and has a noticeable delay, it's not fast. Eclipse user to be closer to 50-100ms. Even on a (now) ten year old laptop. With intellij, it's closer to 3-5 seconds. They have improved things over the years but it never got even close to that level of performance.