In school you are typically taught making small projects. Make a small algorithm, or a small demonstration that you can display an information in an interactive user interface.
In real life (at least in my experience), the applications are typically big. Not too deep, but very wide. You don’t need complex algorithms; you just have dozens of dialogs, hundreds of variables and input boxes, and must create some structure to prevent all this falling apart (especially when the requirements keep changing while you code). Also you have a lot of supporting functionality in a project (for example: database connection, locking, transactions, user authentification, user roles and permissions, printing, backup, export to pdf, import from excel, etc.). Again, unless you have structure, it falls apart. And you must take good care of many things that may go wrong (such as: if the user’s web browser crashes, so the user cannot explicitly log out of the system, the edited item should not remain locked forever).
To be efficient at this, you also need to know some tools for managing projects. Some of those tools are Java-specific, so your knowledge of Java should include them; they are parts of the Java ecosystem. You should use javadoc syntax to write comments; JUnit to write unit tests; Maven to create and manage projects, some tools to check your code quality, and perhaps even Jenkins for continuous integration. Also the things you already have on your list (HTML, CSS, SQL, git) will be needed.
To understand creating web applications in Java, you should be able to write your own servlet, and perhaps even write your own JSP tag. Then all the frameworks are essentially libraries built on this, so you will be able to learn them as needed.
As an exercise, you could try to write a LessWrong-like forum in Java (with all its functionality; of course use third-party libraries where possible); with javadoc and unit tests. If you can do that, you are 100% ready for the industry (the next important skill you will need is leading a team of people who don’t have all of these skills yet, and then you are ready for the senior position). But that can take a few months of work.
There is another aspect of working on big projects that seems equally important. What you are talking about I’d call “design”, the skill of organizing the code (and more generally, the development process) so that it remains intelligible and easy to teach new tricks as the project grows. It’s the kind of thing reading SICP and writing big things from scratch would teach.
The other skill is “integration”, ability to open up an unfamiliar project that’s too big to understand well in a reasonable time, and figure out enough about it to change what you need, in a way that fits well into the existing system. This requires careful observation, acting against your habits, to conform to local customs, and calibration of the sense of how well you understand something, so that you can judge when you’ve learned just enough to do your thing right, but no less and not much more. Other than on a job, this could be learned by working a bit (not too much on each one, lest you become comfortable) on medium/large open source projects (implementing new features, not just fixing trivial bugs), possibly discarding the results of the first few exercises.
In school you are typically taught making small projects. Make a small algorithm, or a small demonstration that you can display an information in an interactive user interface.
In real life (at least in my experience), the applications are typically big. Not too deep, but very wide. You don’t need complex algorithms; you just have dozens of dialogs, hundreds of variables and input boxes, and must create some structure to prevent all this falling apart (especially when the requirements keep changing while you code). Also you have a lot of supporting functionality in a project (for example: database connection, locking, transactions, user authentification, user roles and permissions, printing, backup, export to pdf, import from excel, etc.). Again, unless you have structure, it falls apart. And you must take good care of many things that may go wrong (such as: if the user’s web browser crashes, so the user cannot explicitly log out of the system, the edited item should not remain locked forever).
To be efficient at this, you also need to know some tools for managing projects. Some of those tools are Java-specific, so your knowledge of Java should include them; they are parts of the Java ecosystem. You should use javadoc syntax to write comments; JUnit to write unit tests; Maven to create and manage projects, some tools to check your code quality, and perhaps even Jenkins for continuous integration. Also the things you already have on your list (HTML, CSS, SQL, git) will be needed.
To understand creating web applications in Java, you should be able to write your own servlet, and perhaps even write your own JSP tag. Then all the frameworks are essentially libraries built on this, so you will be able to learn them as needed.
As an exercise, you could try to write a LessWrong-like forum in Java (with all its functionality; of course use third-party libraries where possible); with javadoc and unit tests. If you can do that, you are 100% ready for the industry (the next important skill you will need is leading a team of people who don’t have all of these skills yet, and then you are ready for the senior position). But that can take a few months of work.
There is another aspect of working on big projects that seems equally important. What you are talking about I’d call “design”, the skill of organizing the code (and more generally, the development process) so that it remains intelligible and easy to teach new tricks as the project grows. It’s the kind of thing reading SICP and writing big things from scratch would teach.
The other skill is “integration”, ability to open up an unfamiliar project that’s too big to understand well in a reasonable time, and figure out enough about it to change what you need, in a way that fits well into the existing system. This requires careful observation, acting against your habits, to conform to local customs, and calibration of the sense of how well you understand something, so that you can judge when you’ve learned just enough to do your thing right, but no less and not much more. Other than on a job, this could be learned by working a bit (not too much on each one, lest you become comfortable) on medium/large open source projects (implementing new features, not just fixing trivial bugs), possibly discarding the results of the first few exercises.