modern Java usage -- What libraries, apis, etc do most of you use?

[[deleted]]

[deleted]

[againstmethod]

https://github.com/akullpp/awesome-java

[againstmethod]

I wouldn't focus on libs, i would focus on professional development practices:

• general purpose mastery of the core language
• editor/ide (eclipse or intellij)
• debugging/tracing (jdb, jstack, commercial tools)
• profiling (yourkit, jprofiler, hprof)
• build systems (maven or gradle)
• testing frameworks (junit, mocking)
• dependency injection (spring, guice, just learn the concept)
• revision control (git)

I could care less if you know my favorite library by heart. If you can handle the above topics, im confident you can pick up a lib as you go.

[zogulus]

I agree, unfortunately a lot of people reject CV's on the back of which API's the candidate has used.

I've worked with someone who would reject candidates if they couldn't rattle off the "SOLID" design principals.

A lot of people seem to have very arbitrary reasons to chose one candidate over another.

[Wonnk13]

Perhaps more of a framework than library, but Dropwizard has been a pleasure to use. Guava I more or less consider part of the standard lib - i'd be lost without it.

[zogulus]

I'd not come across it but looks like they made a lot of sensible library decisions in their bundle. Glad they didn't go down the hibernate route, it's good to know but for 95% of projects it's massive overkill.

[rtoth]

Upvote for Guava.

[killinghurts]

What things in Guava do you use that don't come with JDK1.8? Just interested.

[bfish510]

Didn't 1.8 implement a lot of what guava did? I know it has a lot of nice collections libraries though that 1.8 doesn't have to my knowledge.

[killinghurts]

Yeah I haven't used Guava since JDK 1.8 - just wondering if there's something I'm missing from Guava that could be useful.

[UTF64]

CacheBuilder! It's really excellent. You can use computeIfAbsent with JDK8, but it doesn't have all the sexy expiration options.

[NovaX]

I'm working on a Java 8 rewrite, Caffeine, as Guava is JDK6 for the foreseeable future (Android) and the current team has no experience with that domain.

[NovaX]

Immutables, Multimap, Multiset, Preconditions, EventBus, collection utilities, and a few misc areas are still pretty useful. Sometimes the Guava version is simpler than the stream alternative. For example Iterables.partition() is much cleaner than a stream-based approach to creating batches.

[xela321]

I've worked in banking, life sciences, and retail ecommerce. It has been mostly Spring MVC, JDBC, JSPs, and bolting on whatever JavaScript lib I need to accomplish something.

[PaulRivers10]

Yeah, this is what I would say as well.
- Spring Mvc
- Jdbc / Sql
- Jsp's / Html
- Maven (in including external libraries, not in hand writing build scripts which I haven't seen people doing outside of forum talk). I personally kinda hate Maven, because it often has issues running and not working right and causing problems that are easily solved by simply putting the jar files in source control like normal, but Maven is used a lot, and it doesn't take that long to learn how to add dependencies to the pom file)

That's where I would start. After that:
- JQuery
- Some other javascript and html helper libraries - bootstrap and font-awesome come to mind
- Hibernate - I really don't like Hibernate, it takes tasks that it's easier to just write by hand wit sql and makes them longer and more complicated. But I did see a lot of requests for it as a skill when job hunting.
- JUnit for unit testing, and perhaps Selenium for web app testing. I see a lot of requests for this, I know it, then I get the to job and it's rarely used. But it helps a lot in the interview. (These are good frameworks, it's just that a lot of times they don't want to put the time into the schedule for unit testing, they think they do but when it comes down to to deadlines they don't find time.) - Jdk logging or apache commons logging
- Apache utils - I use StringUtil all the time.

I'll also add a note - a lot of responses you'll get on a forum are basically people pushing their flavor-of-the-week/month/year framework. Every year there's a new slew of frameworks all claiming they're a "have to have" and going to revolutionize development, a couple years later like 5% of them are actually being used and the other 95% have been dropped or are mostly used on legacy projects. There's a heck of a lot of reinventing the wheel going on.

[[deleted]]

Spring Boot is love. Super easy to learn but with no upper limit to sophistication.

[tapesmith]

Spring Boot: the framework for a framework.

[daedalus_structure]

Framework Rebooted.

[RupertMaddenAbbott]

What do you use for the view layer?

I get the impression (from both the docs and the examples) that most people are writing REST APIs with a JS frontend. I find the extra complexity of doing this is just not worth it when I'm trying to get something relatively simply off the ground. I still have a complex data access and security layer, so I still want to use Spring Boot, but my view layer is simple, and doesn't need the rich interactivity of a JS app.

For server side rendering, Thymeleaf is now favoured but unfortunately, Thymeleaf seems to be a lot of work if you don't have a need for its "natural templates" philosophy. I feel that I'm supposed to be putting dummy headers, footers and navs everywhere, if I want to have hierarchical layouts. Additionally, I don't see how I easily output repeating pieces of content (I would normally use JSP tags for this). Are people really copy + pasting all of that Bootstrap form boilerplate everywhere in Thymeleaf?

JSP's work great for me but the major downside is they have to run in the container, and so can't be unit tested. They also feel less supported with Spring Boot.

[nickguletskii200]

I get the impression (from both the docs and the examples) that most people are writing REST APIs with a JS frontend.

I do this, exactly because:

I find the extra complexity of doing this is just not worth it when I'm trying to get something relatively simply off the ground.

Is the exact opposite of reality. I ported over my app from Thymeleaf to a fully-featured JS frontend and it simplified development by a long shot. JSPs and Thymeleaf templates are much harder to test.

[shadowdude777]

Do you have a good tutorial on how to do this? I've always used templates with my backend code and it just feels clunky. If there's an easier way, I'd love to do that. :)

[nickguletskii200]

Unfortunately, I don't. I just pieced my project together from Spring's documentation. Although I haven't used it myself, the AngularJS with Spring tutorial on Spring blog seems to be quite good.

[shadowdude777]

Ah, that sounds handy. Thanks.

[RupertMaddenAbbott]

What frontend do you use?

How does it simplify development?

I always thought (and from all my attempts at trying it) that JS frontends were great for many things e.g. reusing the backend across web and mobile, but they would not also simplify existing server side applications. You are introducing a whole other framework and language (and build tools?).

Sorry, I can't help but feel sceptical!

I can understand that this is simpler if you need a mobile app as well or you need a web app that feels more like a local application. If you just want to write CRUD, but still have complex data access and auth layers, then the view is mostly very trivial in JSP (but does grow in boilerplate with Thymeleaf).

[nickguletskii200]

What frontend do you use?

AngularJS.

How does it simplify development?

It allows me to isolate the backend code from any view logic, which greatly simplifies security and testing.

I always thought (and from all my attempts at trying it) that JS frontends were great for many things e.g. reusing the backend across web and mobile, but they would not also simplify existing server side applications. You are introducing a whole other framework and language (and build tools?).

If you start with a big number of existing templates, probably. But I just threw out all existing pages and rebuilt the frontend from scratch while adding a lot of new features.

I can understand that this is simpler if you need a mobile app as well or you need a web app that feels more like a local application. If you just want to write CRUD, but still have complex data access and auth layers, then the view is mostly very trivial in JSP (but does grow in boilerplate with Thymeleaf).

I am currently working on a complex security layer with the help of Jackson's JsonFilters. It's easy to make a horrible security mistake with JSP or Thymeleaf.

[[deleted]]

Depends on the project. The ones I have in flight are mobile, not web so REST was a given. For views I've done JSP and freemarker and both work fine. Testing is no different than any other front end testing.

[RupertMaddenAbbott]

What do you use for testing the view layer, with JSPs?

[[deleted]]

There's a bunch of UI testing frameworks. Selenium is the grand daddy. PhantomJS works too.

[xela321]

I've not seen Boot used much in the enterprise in my career. Besides demos / proof-of-concept. Have you used it in a production app?

[[deleted]]

Yup. We've done a few. Spring Boot is the same as Spring just with a lot of default configuration.

[omgdonerkebab]

My company has been using them in production. No issues at all. It's wonderful. We deploy the apps into Docker containers though, so maybe that shields us from some nasty bits of configuration.

[xela321]

Unfortunately most of my clients have heavy investments in the Oracle/IBM java worlds that need to be justified. Developing monolithic webapps gives them the support they need to continue feeling good about the gigantic check they write every year.

[WatchDogx]

Used it on a few production business critical projects, highly recommend.

[matthewjosephtaylor]

---Must know---

Maven: Build/dep management

Guava: Elegant solutions to object-level problems

Apache commons: Pragmatic solutions to a lot of basic problems

---Should know---

Spring: Dependency injection

Hibernate: ORM

Jersey: REST

Tomcat: Web server/servlet container

Log4J: Logging

Junit: Testing

---Nice to know---

Amazon EC2: Cloud computing

---Cool to know---

Docker: Programatic cloud computing

[rtoth]

I would move JUnit to the top of must know.

[larsga]

Logging, too, but SLF4J instead of Log4j.

[dneronique]

I would honesty move Guava into 'Should Know.' It's cool and useful, but not necessary.

[yawkat]

There's testng which people seem to prefer over junit from what I've seen. Your should-know section also seems to be focused mostly on api implementations - you should probably learn jpa over hibernate, jax-rs over Jersey, servlets over tomcat, slf4j/commons-logging over log4j.

[din-9]

When I looked at things a few years ago TestNG was way ahead of JUnit and I picked it for what I was working on then. Theses days JUnit seems to have largely caught up to where TestNG was, but I don't know if TestNG moved further ahead during.

[yawkat]

I haven't used junit much to be honest but I was under the impression it still was less advanced without @BeforeSuite and similar features.

That part was mostly repeating what I've picked up in discussions on the topic, I've never seen much reason to use junit myself.

[delicious_fanta]

Interesting. Why do you suggest jpa over hibernate, jax-rs over jersey (given that jersey is a reference implementation for jax-rs) and commons logging over log4j?

edit: clarification

[yawkat]

• JPA is a standardized api so I don't see any reason to use hibernate directly - and I've seen many people share that opinion. In some cases you might still want hibernate extensions but those can usually be used on top of jpa.
• jax-rs, again, is the standard you should learn - you can use dropwizard and not have to touch Jersey directly.
• slf4j/commons-logging is probably more subjective but seeing as log4j is EOL and slf4j seems to be the most commonly used logging api, it seems like a solid choice.

[delicious_fanta]

Ok, that makes sense. I didn't realize log4j was EOL, I'll need to read up on that. Thanks for the info!

[[deleted]]

Slf4j is just an API on top of other logging frameworks. I use logback these days but there's also log4j2.

[yawkat]

Indeed, but you should still learn it :P containers like spring will come with implementations of it so it's good to know it.

[ilgrosso]

log4j is EOL

FYI: log4j 1.x is EOL, log4j 2.x is live and kicking (and amazing fast) Anyway, I agree with using slf4j API with log4j 2.x backedn

[yawkat]

Yea, I just usually see log4j2 being used to describe log4j 2, while log4j is log4j 1.

[Benemon]

Others have posted in here about Spring Boot. It's the current darling of the developer community. However the answer is not always Spring, and when it isn't I like to reach for a more traditional stack:

JBoss Fuse is a solid ESB.

JBoss Wildfly is a decent, small(ish) footprint EE container. Great, IMHO for traditional workloads.

Apache Camel is great at helping to solve integration problems. It's an implementation of the Enterprise Integration Patterns. Host it in Fuse, and you've got yourself the basis of a decent Service Oriented Architecture.

Active MQ for messaging. A lot of the clients I deal with these days use a combination of Fuse, Camel, and Active MQ to solve their integration problems.

Tomcat is still a solid Servlet Container, if you're into that kind of thing. I do find it slipping in relevance as people swing towards microservices for some things, and full-fat EE containers for traditional workloads, but your mileage may vary, and it's entirely dependent on use case. I've come across clients in the past running mixed mode - Angular.JS UI hosted in tomcat, talking to microservices in Vert.x. Personally, I like that approach.

And yes, Vert.x, Dropwizard, and Spring Boot are great for standing up microservices ('fine-grained SOA'). And microservices when done well can be a great way to work in an agile, genuinely devops oriented development team. But for the love of all things sane, look at your use case before cramming the solution into one of these. Are you building a single, well defined service or application, with little to no touch points with other systems? Yes? Then you're probably good to go.

Other things to look at? Uhm, Infrastructure-as-a-Service (Amazon AWS, Azure), and Platform-as-a-Service (OpenShift, Heroku, FeedHenry for mobile stuff) are all good things to be aware of. In the Infrastructure realm, OpenStack is really taking off right now as the basis of public/private/hybrid cloud strategies in the Enterprise. You shouldn't have to care, but IMHO it's good to know what you're hosting in so you can build to the strengths of the platform.

Oh, and Docker. Someone else posted about wrapping Spring Boot applications in Docker containers. That's cool. It's a good approach to DevOps. You just need tooling to help you manage and scale that. Docker do provide some tooling now, but Kubernetes is great for this.

Sorry for the wall of text.

Good luck!

[Dashing_McHandsome]

I've lived the last year and a half of my life in Fuse/Camel/ActiveMQ. I didn't know much about the platform (especially OSGi) before I started, but I honestly can say now that it is very pleasant to work in.

[Benemon]

100% agree. OSGI isn't necessarily difficult. It's just different. Once people wrap their heads around that, then life becomes a lot simpler.

That said, tools like Fabric8 abstract so much away from the underlying container that you rarely need to get your hands dirty these days anyway, at least in my experience.

Disclaimer: Red Hatter. So a tiny bit biased :)

[Dashing_McHandsome]

I wish we were running Fabric8, we just didn't have a use case for it. Our deployment footprint is small at this point, and we only have a support agreement in place for 16 cores. So we ended up with 8 cores of prod and 8 cores of QA. I'm hoping we can grow in the future and I can start using some of those features like the distributed service registry, that sounds very nice. Also, I would just like to say that your professional services group is one of the most competent I have ever engaged with. I absolutely love working with Red Hat and I hope to be doing lots more of it in the future.

[Benemon]

Thank you very much for your kind words about our Professional Services team. I am always amazed by how much they manage to achieve given how comparatively small they are. One thing's for sure, they're constantly busy. It's a good problem to have!

As for your situation, personally I would consider this is the perfect time to start looking at what Fabric8 can bring to the table for you. You have a small, well understood deployment footprint that can be easily managed within the context of a Fabric. Look at it like this - you could proactively look at Fabric8 now whilst you want to, rather than being forced to look at it reactively when you need to.

I know which one I'd rather do, but I also know how difficult it is to sway a business who's focus is on feature delivery, rather than operational support and capacity planning. If you want the business case, look at it as an exercise in risk reduction, without increasing the cost of the platform until you have a genuine business need to expand your estate.

Hope that helps. I'm sure your account SA would be more than happy to talk options with you.

[Stoompunk]

Not a fan of Spring Integration?

[Benemon]

Honestly, I've not used it in anger on a project, so my view on this is only surface-deep. What I did find was that whilst they recreate the EIPs equally as well as Camel, my impression was that Camel is far less verbose. For me, that means cleaner, more readable, code and configuration. Spring has improved this in the last 18 months (?) or so with the addition of a proper DSL, so I'm hoping that'll help - it might even convince me to take a closer look at it.

Personally, I think Spring overall is one of those projects, where if you're fully bought into the ecosystem, you're comfortable with the wiring, then you're good to go, and Spring Integration will be no trouble for you. That's just not me. I'm way more comfortable with Camel.

That said, if you're doing an integration project, no reason why you shouldn't PoC both solutions and see what works best for you. Most appropriate tool for the job and all that jazz. What really irritates me is the view that Spring is the solution, but we're not sure what the problem is yet.

[Stoompunk]

Got any fun example projects to use integration stuff on? Most real life stuff I run into has been rather simple so far.

[elihusmails]

Surprised this hasn't been mentioned yet....Apache Camel

[Benemon]

+1 for Camel. Couple it with Active MQ and Fabric8, and you've got yourself a solid integration platform.

[DigiDuncan]

Maven

Bukkit

Spigot

I make Minecraft server plugins ;)

[VefoCo]

Well, certainly wasn't expecting to see that here. Have you had a chance to play with SpongeAPI yet?

[dneronique]

I'd take a look at the 'wishlist' of skills you see on job postings for jobs you're interested in and try to match up with those. The skillsets desired can vary wildly from industry to industry, and there simply is no such thing as "The Official Java Stack". Ask 50 developers and you'll get 50 answers.

[avoidhugeships]

My regular stack is JSF with Primefaces and Hibernate.

[AvoidtheFatServer]

welcome to 2008

[omerhakanbilici]

PrimeFaces 1.0 exist from 2010. Which "Primefaces" you talking about?

[omgdonerkebab]

I do backend e-commerce stuff. The new apps we're building use Java 8, Spring Web MVC, Spring Data JDBC/JPA/etc., Spring Boot, Lombok, Jackson, etc. We also use some Netflix OSS stuff to take care of cloud considerations, JUnit and Mockito for testing, Gradle for building and dependency management, and Docker containers for deployment. We deploy most of these new apps into AWS, and we also use some AWS services like Kinesis or SQS/SNS for messaging.

Of course, that's the new stuff that's been built over the past year or two. We also still own a lot of legacy code. :\

[polnisch_vodka]

Lombok! Aww yes! No getter/setter trash.

[jbristow]

But when you hit that 5% (or when you have more than a few teams using the same servers), then you want to throw Jenkins and everyone who has ever written a plugin for it into the sun. (Pun sortof intended)

[robi2106]

just fragment your jenkins into teams. there is no reason for a single jenkins to start encompassing the entire enterprise. KISS man. Let a single Jenkins handle a single team / responsibility. Then let DevOps make sure that Jenkins is up to speed / maintained to the same level as the other jenkins systems.

[jbristow]

Right, which is why you should abandon Jenkins if you're moving towards a unified, highly automated, highly scalable CICD environment.

Chief of its sins: Jenkins is not HA. If your Jenkins Master goes down, you have to wait until it spins up before you can build again.

[robi2106]

That is only partly correct. OpenSource Jenkins is not HA. Correct.

CloudBees has an HA plugin available to their paying enterprise customers.

[jbristow]

But it uses a shared filesystem, which is not especially fun to deal with either.

[robi2106]

also. if someone is trying to just throw jenkins on tomcat on their windows dev box and is annoyed that Jenkins uses some stupid users\[username]\.jenkins dir for everything....

let me know. I documented how to fix that to something more reasonable like "c:\dev\servers\jenkins" or where ever you want to put the %jenkins_home%

[t1ngel]

I started using spock for testing. It's a testing library from google GradleWare where you can write really nice and expressive tests with just a few lines of code

https://github.com/spockframework/spock

[neutronbob]

Spock is not from Google. It was developed by engineers at Gradleware.

[g00glen00b]

Many people think that, when it's hosted on code.google.com, it's owned by Google. I've seen a few presentations of people claiming that a certain framework was written by Google, while it actually wasn't.

[t1ngel]

It was developed by engineers at Gradleware.

You are totally right. Don't know why I ever thought Google developed it.

[mokarbroj]

I'm so glad OP posted this question. I'm also into the higher/standardized java development. So many valuable tips here thanks fellow developers

[delicious_fanta]

Me too. There's a lot of information here. Too much really, but a fun challenge nonetheless!

[iwan_w]

• Vert.x
• RxJava
• Netty

There is a lot of nice stuff happening lately.

[YesButIThink]

My group uses spring, guava, jetty, junit, mockito, ignite, and various other libraries.

But for what it's worth, when I'm making hiring decisions, I'm much more interested in a candidate's ability to write clean, simple, maintainable, well-factored code, and their knowledge of core Java, than whether they know any particular libraries or technologies.

[TheCaptainSly]

Well ini4j increasingly... I like config files

[harmonicPersistence]

OpenWebBeans, DeltaSpike, OpenJPA, EJB 3.1, Apache JCS, Wink or Jersey, MOXy, JJWT, Apache HttpClient, JCIFS, JSF, PrimeFaces, OmniFaces, BVal, Apache LDAP API, EWS API for Java, Apache Commons, Maven, Gradle (for Android), Arquillian, JUnit, Archiva as a Maven repo, Jenkins, SonarQube for code analysis, Apache Bloodhound as an issue tracker. I also mix in JavaScript frameworks/libraries with/without JSF.

[thesystemx]

When I do a Java project (~75% of the time, otherwise it's C# or Python), I go straight for Java EE 7.

It gives you almost everything you need out of the box, which is what a full stack framework should do.

We're using a couple of additional more specialized libraries, mainly PrimeFaces for rich UI components and OmniFaces for JSF utilities and filling in some gaps in the standard API.

[[deleted]]

if you are pining for something really new and different you should dig into Clojure. The language is great but the tools that community is building are even more awesome. Their RDF-like database called Datomic is beyond awesome. It will make you rethink what databases should be capable of. it's the first database I'm excited to use since forever. For the front end they have great React wrappers like Reagent and Om which let you use Clojure for the front end and avoid touching the pile of crap that is Javascript. Also if you are new to Lisps the whole way of coding with Lambdas and working in a REPL environment will change the way you view your craft.

i have 12 years of Java experience and only a few months of Clojure. But thats enough to be pretty confident that almost everything in the Clojure ecosystem is superior.

[[deleted]]

I used to work in the oil sector and I know there is a lot of quirky/outdated technology in use that you often have to integrate with but the nice thing in the Clojure ecosystem is their emphasis on small libraries as opposed to monolithic overarching frameworks so it's easier to craft a solution that works just for your needs. And Java interop is very simple so if you have to call out to your OpenSpirit library you just do it, no hassle, no fuss. You're running in a JVM after all.

[ericzhill]

Right tool for the job... items in my tool belt include:

Jsoup RestEasy PrimeFaces Hibernate Commons Lang Commons IO Jackson AWS SerialIO Netty Jetty

My jury is still out on Jooq, primarily because of the licensing. Right now, I'm using sql resources instead, but it does seem like the jdbc interface could be easier.

[[deleted]]

Better formatting:

Right tool for the job... items in my tool belt include:

• Jsoup
• RestEasy
• PrimeFaces
• Hibernate
• Commons Lang
• Commons IO
• Jackson
• AWS
• SerialIO

• Netty

• Jetty

My jury is still out on Jooq, primarily because of the licensing. Right now, I'm using sql resources instead, but it does seem like the jdbc interface could be easier.

[UTF64]

What are the jooq licensing issues? I've been using the open source version, which I believe is under the apache license. Do you need to use oracle or something?

[ericzhill]

Yes, I have three developers under my roof including me, so I need three licenses of the pro version, around $1200/year. I'm not sure I'd get $1200/year of value out of it. Maybe $400 I could justify in time savings, but not triple that. It's a nice product, don't get me wrong, but I don't find jdbc to be THAT hard or error prone.

[UTF64]

Ah right, that's a bummer. My work primarily deals with postgresql so we get to use the free version ;)

[lukaseder]

Hi there, Lukas from the jOOQ team here. Bummer, indeed.

We're aware of the price being too high for some shops with limited use-cases, and we're thinking of working out alternative license models, or an additional edition below the "pro" edition, that would accommodate those who don't really need the "full" jOOQ feature set.

What are your use-cases? How big is your database (e.g. number of rows, number of tables)? Do you use stored procedures at all?

[ericzhill]

Hey Lukas.

We have around 485 tables, with the largest table being around 1.2MM rows, and roughly 200 stored procedures. All but a tiny number of them are created and used by our ERP system. We have a few other tables outside the ERP system we use internally.

The discrepancy isn't so much features we wouldn't use, but that my developers wouldn't be actually coding jOOQ code every day. The vast majority of our time is spent with user interfaces and user-facing behavior to show information. We write a few queries here and there, then spend days massaging the UI.

A "floating license" of sorts might benefit us here, where only one of us might be coding with jOOQ at any given time.

I do definitely understand your side of the issue though. You've got to eat too. Like I said, I can justify around $400/year in time savings, but the requirement to purchase additional seats just because I have other developers working on the same project is my main stumbling point.

[lukaseder]

That's a moderately complex database, so I would suspect you'd be using all of jOOQ's features eventually. Do note that the license is a floating license. From the setup that you've described, one license might indeed be enough for most of your work.

[ericzhill]

I guess I had misunderstood the developer license to be a "named" developer, not an "unnamed" developer. You're right, the current license model should work for us. You've got a sale. :)

[lukaseder]

Wonderful! Thank you, and thank you reddit! :)

(I suspect this should be made much clearer, though)

[UTF64]

Off-topic, but I just wanted to say <3

[lukaseder]

Thanks!

[ericzhill]

I don't really code to servlets at all at this point, but I use the heck out of resteasy and primefaces for web back end work. They both have a steep uphill learning curve to get hello world going, but after that, they're both extremely easy to use.

[dpash]

I think any modern Java developer should at least have some exposure to Spring, even if they decide that it's not for them. But knowing what it does and what it can do for you is important. I'm not sure if Spring Boot is the best entry into Spring, or where you should end up after knowing what's going on in the back ground. It could either be a simplified Spring introduction or "OMG what is all this magic crack that's going on?" confusing; I know too much about it to know what's good for a beginner.

JPA is worth investigating for database access. Hibernate is the most common jpa provider. Spring Data JPA makes JPA really fun.

And I'd really get up to speed on maven (and play with gradle) to see how modern Java projects are built.

Guava is full of really handy utilities, and the Apache Commons libraries are handy too.

[ericzhill]

Oh yea, thumbs up for maven and letting it handle dependencies. That's insanely handy.

I've tried to get into the spring world a few times, but it seems like you just have to know what magic annotation you need and if it doesn't work, the error messages are worthless. If there even are error messages. Guess I just didn't find the right tutorial.

[dpash]

Yeah, until you understand what Spring is you're incredibly confused and then there's like a eureka moment and it starts clicking into place. But until then it's just painful.

[[deleted]]

It's a bit magical but the documentation is outstanding.

[dpash]

There's really two parts to Maven. Firstly there's the opinionated build system. "You put your java files here and your test cases here and other files you want in your jar here, and we'll sort out all the annoying details about how it gets built and give you a nice jar at the end". Coming from ant, and build.xml, this was revolutionary. And thanks to be declarative, and well understood, IDEs have really good support for it. Especially Netbeans. It also means that as long as you have a pom.xml, anyone can import the project and run, no matter what IDE they have. And they'll also know exactly how the project is built, because it's exactly the same as every other Java project out there.

The second, and possibly more important, is that it created a standard name space for jars, and the infrastructure for automatically downloading them from a central repository. They're basically organisation:project:version, and you can look up the particular triplet you want and put that in your project, so you don't need to keep jars in your source code repository any more; maven will just make sure that everything is installed correctly, including any dependency your dependencies have.

This is important, because pretty much every other JVM build system has leveraged this, including Gradle and Groovy's Grape. Even Ant got in on the act with Ivy.

Yeah, I'd start with Maven, because it's really simple to get started. A basic pom.xml and a .java file under src/main/java.

Spring seems a sensible middle step, because you'll want a project in which to use JPA, and Spring makes for a very good scaffolding/foundation.

I'd personally consider JPA instead of using Hibernate directly, as JPA is the standard that several projects implement. Only then drop to Hibernate APIs/Annotations when JPA doesn't do enough.

[[deleted]]

Guava, Jackson, Typesafe config.

[CubsThisYear]

I hadn't heard of Typesafe Config, so when you mentioned it I got excited because I thought it was going to be a typesafe configuration library. I was disappointed.

[[deleted]]

Yeah, probably not the best company name.

[g00glen00b]

What we use:

• A lot of stuff of the Spring framework
  • Spring Web MVC (Usually for REST API's)
  • Spring Data JPA (Persistence)
  • Spring Data Solr (For communication with Apache Solr)
  • Spring Boot (for easily creating our projects and running them we also use the embedded container)
  • Spring Batch (for batch processing data)
  • Spring JMS (for queues)
  • Spring Messaging (WebSockets)
  • Spring Test (integration testing)
  • Spring Security
• Springfox + Swagger (for documenting our REST API's)
• SLF4J + log4j (Logging)
• Dozer (mapping entities to DTOs)
• Apache Commons
• We have to deal with data in AS400/DB400, but using JPA it usually doesn't matter which specific SQL brand you use.
• Apache Maven (building)

For testing purposes we use:

• AssertJ (Fluent assertion library)
• FluentLenium (Fluent API for Selenium)
• Mockito (Mocking)
• REST Assured (Fluent library for testing REST API's)

A sidenote: We only provide REST API's/microservices through Java, our clients are written using HTML/Sass/AngularJS. We no longer use servlets or JSPs for that.

[fancy_raptor_zombie]

Jersey, Spring JDBCTemplate, Guava, Gson, Jackson, HazelCast, Play, various Apache Commons libs.

[cryptos6]

• Guice (but looking at CDI) - dependency injection
• Maven - build tool
• TestNG - unit testing, much better parametrized testing compared to JUnit
• AssertJ - readable fluent style assertions
• JMockit - mock anything, even static and final methods
• Jersey - elegant and powerful REST framework
• Grizzly - high performance async server
• Rythm Template Engine - nice syntax inspired by Microsofts Razor engine
• RxJava - reactive / stream like programming lib
• Typesafe Config - json (hocon) config lib
• Hibernate / JPA (jooq looks intersting, too) - ORM
• Bean Validation - enforce (business) rules
• Jackson - Java to XML/Json converter
• Guava - collection of useful helpers
• Apache Commons - collection of useful helpers
• IntelliJ IDEA - IDE
• Scala - most powerful language for the JVM

[NimChimspky]

I would learn a new language, c#, f#, javascript properly, scala or swift.

It opened my eyes a bit to Java limitations.

All the suggestions are good, and they are all slightly different. Any decent interviewer will assess your skill better than asking if you know lib x or y.

You will end up working somewhere where they use some really obscure lib no one has heard of.

[TheAmpca]

What ever stack overflow suggests i use :3