3 ms·

I'd be surprised if you found any dramas with the language. What will keep you in the office to all hours is the ecosystem. Now the ecosystem is probably best

I'd be surprised if you found any dramas with the language. What will keep you in the office to all hours is the ecosystem. Now the ecosystem is probably best in class so don't mistake this as a slight, but it's huge and complex. Learning Gradle (or Maven), understanding how to make building java apps fast (because the default is slow package assembly times), learning some of the large frameworks (if you go down that route) can keep you occupied for years. If you're fresh to java, i'd probably encourage you to try avoiding the incumbents like Spring and see how you go? Without Spring, Java is actually pretty efficient. A hello-world rest service with spring results in around 6,000 classes being loaded. That said - spring, used idiomatically, is a productivity boosting powerhouse.

pm90 5y ago
You can’t avoid spring unless you’re in a small shop. It’s basically mandated/standardized at most places since “everyone knows it”.
- selfhoster11 5y ago
  Sadly, Java and Spring are basically a package deal these days. Enterprise shops are likely to run on Spring.
javajosh 5y ago
I forgot where I read this, but I think it's true: With Gradle to do anything you have to understand everything. (Not a fan of Gradle)
da39a3ee 5y ago
Thanks. I have to say, this sounds awful -- it sounds like it will be a huge time sink and an impediment to learning about areas of software engineering that transcend specific languages (say, service orchestration, distributed systems, system architecture patterns, workflows, etc)
- CraigJPerry 5y ago
  It is awful. However it’s not all accidental complexity. To pick a random example, there’s a reason typo squatting is a thing in npm or pypi but not in maven/gradle. The mitigation’s that prevent this are not free, they add complexity (e.g. signing before publication, dns records, immutable packages etc). But there’s definitely some areas of accidental complexity remain. While gradle CAN be used well (e.g. <3 min build on large code base), the default in large teams seems to resemble a kind of tragedy of the commons. Full of sharp edges and >45 min builds.

pm90 5y ago

You can’t avoid spring unless you’re in a small shop. It’s basically mandated/standardized at most places since “everyone knows it”.

selfhoster11 5y ago
Sadly, Java and Spring are basically a package deal these days. Enterprise shops are likely to run on Spring.

javajosh 5y ago

I forgot where I read this, but I think it's true: With Gradle to do anything you have to understand everything. (Not a fan of Gradle)

da39a3ee 5y ago

Thanks. I have to say, this sounds awful -- it sounds like it will be a huge time sink and an impediment to learning about areas of software engineering that transcend specific languages (say, service orchestration, distributed systems, system architecture patterns, workflows, etc)

CraigJPerry 5y ago
It is awful. However it’s not all accidental complexity. To pick a random example, there’s a reason typo squatting is a thing in npm or pypi but not in maven/gradle. The mitigation’s that prevent this are not free, they add complexity (e.g. signing before publication, dns records, immutable packages etc). But there’s definitely some areas of accidental complexity remain. While gradle CAN be used well (e.g. <3 min build on large code base), the default in large teams seems to resemble a kind of tragedy of the commons. Full of sharp edges and >45 min builds.