it's funny i probably won't give that much actual tech advice here but will relate a little anecdote. I was once asking in a forum about moving from RoR to Clojure, trying to calm my nerves, and some Clojure dev straight up asked me "Out of curiosity.... why is it that a lot of web developers think that Clojure isn't an adequate solution for lightweight apps?" and I remember saying something like "Well.... I think because it's not like a full-fledged framework with built-in ORM and a prescribed workflow" etc. etc. and as I was saying it I had this epiphany -- a lot of the JVM guys are so used to figuring out tooling and library integration that while the rest of the world is looking in and saying "How do you start from scratch like that?" a lot of them are looking out and saying "How come you guys are trying to solve a variety of problems all using a single tool?". Code is code, and a lot of web programming is just accumulating strings.
So yeah I'd say I'm pretty early in my endeavors (I mean I code using a Java tool for a corporation but there is a pretty strict workflow for that) but as far as open source & my actual education is concerned, ok I'll give you tech advice --
1. Java has a number of MVC solutions. Pick one & study it, probably with a tutorial/guide. Don't focus on the amount of configuration available (the cruft), just follow a tutorial to get a few hello world kindof pages. You'll see that it's not nearly as difficult as one might imagine. I first studied JSF, then Spring MVC (in retrospect, Spring MVC is probably a better starting point. I think it is also really hot in the job market.)
2. Pay attention to the terminology (research every unknown acronym) and see how it is an analogue to something you're familiar with.
3. Make note of the features/points that are not available in the language/framework you currently use. For me, data-binding to a form was the first thing where I thought "woah thats so much simpler...". Look up PrimeFaces or something like that if you want to see an explicit/obvious example of this, though personally I'm not sure I'd use it in practice (Spring itself offers data-binding stuff).
4. Research some JVM framework that is similar to one you are already familiar with (Play is a good start here or again Spring MVC if you're not afraid of Java syntax) and figure out how to make some basic pages, then add some logic.
5. Study the relationships between servlets/classes/beans/etc, figure out how they are scoped. A lot of it is pretty much free-form code and frameworks like Spring will let you do pretty transparent things before you get deeper into more nuanced app-flows.
6. Protocol is usually pretty easily determined by app needs. I like to default to json since I do a lot of javascript and it seems to fit better with REST, but internally lots of java apps & web services use XML. This hasn't really hurt my brain at any point yet.
7. And finally, when in doubt, try a pure Java solution until you realize that you need a tool. I think this has really been key for me. I could build apps on a similar level to what I was doing in RoR without many fancy libraries, and now I'm learning enough of each that I can make a more educated decision when the application actually demands it. I think all the choices can be daunting but the power of the minimal tools is enough that the entire chain isn't necessary for every application.
8. Oh, plus one more! If you like some other language (for me it's Clojure) study the language in it's pure form plus throw in a little study of Java interoperability in case you'd like to use it sparsely within one of the tried & true Java frameworks. This may not be possible without some meditation on it...
There are lots of templating languages available so as always you'll often just be injecting stuff into html. Many frameworks are just turning into a home base to shove fancy javascript frameworks into so depending on your app, you may not even need much server-side code (in fact I think this is why some of the simplistic monolith frameworks are surviving so long).
And of course, I don't know everything.... so maybe the JVM isn't the answer. I'm just having a lot of fun learning it, and I was once a Rails guy.
So yeah I'd say I'm pretty early in my endeavors (I mean I code using a Java tool for a corporation but there is a pretty strict workflow for that) but as far as open source & my actual education is concerned, ok I'll give you tech advice --
short answer: https://spring.io/guides
1. Java has a number of MVC solutions. Pick one & study it, probably with a tutorial/guide. Don't focus on the amount of configuration available (the cruft), just follow a tutorial to get a few hello world kindof pages. You'll see that it's not nearly as difficult as one might imagine. I first studied JSF, then Spring MVC (in retrospect, Spring MVC is probably a better starting point. I think it is also really hot in the job market.)
2. Pay attention to the terminology (research every unknown acronym) and see how it is an analogue to something you're familiar with.
3. Make note of the features/points that are not available in the language/framework you currently use. For me, data-binding to a form was the first thing where I thought "woah thats so much simpler...". Look up PrimeFaces or something like that if you want to see an explicit/obvious example of this, though personally I'm not sure I'd use it in practice (Spring itself offers data-binding stuff).
4. Research some JVM framework that is similar to one you are already familiar with (Play is a good start here or again Spring MVC if you're not afraid of Java syntax) and figure out how to make some basic pages, then add some logic.
5. Study the relationships between servlets/classes/beans/etc, figure out how they are scoped. A lot of it is pretty much free-form code and frameworks like Spring will let you do pretty transparent things before you get deeper into more nuanced app-flows.
6. Protocol is usually pretty easily determined by app needs. I like to default to json since I do a lot of javascript and it seems to fit better with REST, but internally lots of java apps & web services use XML. This hasn't really hurt my brain at any point yet.
7. And finally, when in doubt, try a pure Java solution until you realize that you need a tool. I think this has really been key for me. I could build apps on a similar level to what I was doing in RoR without many fancy libraries, and now I'm learning enough of each that I can make a more educated decision when the application actually demands it. I think all the choices can be daunting but the power of the minimal tools is enough that the entire chain isn't necessary for every application.
8. Oh, plus one more! If you like some other language (for me it's Clojure) study the language in it's pure form plus throw in a little study of Java interoperability in case you'd like to use it sparsely within one of the tried & true Java frameworks. This may not be possible without some meditation on it...
There are lots of templating languages available so as always you'll often just be injecting stuff into html. Many frameworks are just turning into a home base to shove fancy javascript frameworks into so depending on your app, you may not even need much server-side code (in fact I think this is why some of the simplistic monolith frameworks are surviving so long).
And of course, I don't know everything.... so maybe the JVM isn't the answer. I'm just having a lot of fun learning it, and I was once a Rails guy.