Autograding doesn't have to be all-or-nothing
How can I reduce the amount of grading for the assignments?
The term "autograding" implies end-to-end work taking a zip file of submissions all the way to posting the completed grades onto your LMS via the API. I don't see the situation as all-or-nothing, and it seems like you'll only get so far without some automation.
You can create small tools that automate the repetitive stuff, like downloading and organizing submissions and compiling them so they're all ready to go for hand-grading, if you don't already.
For simple auto-grading, the only prerequisite is ensuring students adhere to input and output format guidelines, which is probably already done to help students understand the concept of delivering software that implements a specification and mitigating "works on my computer" or "guidelines weren't clear" excuses.
If the project is command-line based, it shouldn't be hard to write a simple test suite, either one that uses the classes directly or works on I/O and runs subprocesses. It doesn't have to enforce everything and can assist spot checks to ensure usage of OOP concepts.
MySQL increases the complexity a bit and is likely prohibitive to automate fully for you. However, depending on the nature of the assignment, something indirect like tearing down and respawning the solution process and wiping files between runs could validate that the student used the database without as much hassle as validating it directly. If you can establish that the correct I/O was emitted as a black box, you can grep or spot check the code by hand for the approproiate database calls.
Assignments should be designed to avoid imposing artificial constraints such as prohibiting specific common language features. For example, in a database assignment, choose a task that's difficult to do with files and you won't need to waste time validating that students used a database. Tasks well-suited to a tool motivate the concept better.
GUI programs are likely to stay hand-graded based on your circumstance, but a script that unzips and compiles all of the submissions seems like it'd give a nice boost and weed out early failures. You can also separate presentation from logic (as should be done anyway) and unit test the logic, then do a quick spot check on the GUI. I'm not sure how dominant GUI is in the projects.
Many problems with student code can be found with smoke tests. My experience is most submissions are nearly totally successful, with a minor deduction or two, or totally crash and burn, with a handful of submissions in the middle. You can use your knowledge of the nature of your assignments to guide the amount and flavor of automation to pick the low-hanging fruit.
Offering simple harnesses as suggested in other answers is a great idea (essential, I'd say), but keep in mind that students don't need to understand all provided tools, they only need to be able to operate them as users. I've taken multiple classes where I never took the time to read or understand much of the provided test suite, some of which were prohibitively complex or came in a binary.
Consider pushing JUnit forward
my students aren't introduced to JUnit testing until one of the last modules
If your curriculum already covers JUnit, you might try to work that in as early as possible, then use it as a foundation for grading and validation through the rest of the course. If you provide the harnesses and boilerplate, these suites need not be that much more complex than Ben's plain file, and may even be simpler if you can arrange the boilerplate to be compilable out of the box and avoid potential syntax errors associated with commenting and uncommenting or otherwise messing with the test suite code.
Unit testing is about as practical a skill as it gets, and it's unfortunate it wasn't a part of my undergraduate education. I only wrote unit tests after I started professional programming, and (as a client) from a coding challenge site Codewars. If you check out the 7- and 8-kyu (easiest) kata (challenges) on Codewars, I think you'll find them on level for your students, yet they are driven by (mostly) understandable, simple test suites (the ones that aren't are generally sloppily written by the kata creator).
A graduate-level programming course I was a TA for permitted students to share test harnesses and test cases on the class discussion board. This increased collaboration and happiness in the class and made it easier for students to validate their work.
Students that sought feedback on why their submissions failed were typically met with "did you run your code against the student-curated test suite?" Almost inevitably, they hadn't, and doing so led them to see their failing test cases and the power of collective effort.
This doesn't seem as feasible for CS101B-level students who aren't accustomed to whipping up tests on a dime, though, but there could be a useful variant specific to your case that provides a win-win for students while cutting back on your work.
How can the assignments be improved?
Any other feedback to improve the assessments?
It's hard to say based on a high-level description alone, so these ideas might be wildly inapplicable.
You mention "There are currently 6 Java programming assignments (each worth ~2.5% for a total of 15% of their final grade". Assuming the traditional cutoffs of 70/80/90 C/B/C, a student can get a B in the class without doing any of the programming assignments? I had this arrangement in two graduate-level classes on algorithms and data analytics which were weighted heavily on exams, but for a CS101B-level class, this is surprising. It's been a few years since my last experience with such a class so maybe I'm out of the loop. I typically expect to see projects at about 50-60% and exams 30-50% with some occasional filler for participation and quizzes at 0-10%. It could be that written homework assignments are a decent chunk of the projects portion of the pie, but that should still leave projects 30% or so.
It's interesting that you're asking for guidance with something that's a small fraction of the class yet seems to consume a disproportionate amount of your time, and presumably your students' time as well. If your students are investing as much time on these projects as you seem to be, the weight should reflect that.
You mention you have 3 assignments that build in sequence: text file to random access file to MySQL. I'd probably skip the random access file and go straight to the database. It's much more practical, and I think students might tire of iterating on the same thing too much.
Although files and databases are related in that they persist data, they're also unrelated in that they solve fundamentally different problems. I'd caution against trying too hard to create an artificial narrative as series projects sometimes do.
As much as I like databases and files, they're a bit dry, more means to and end than anything, so I try to integrate them into fun projects like games or social apps when possible, sneaking vegetables into the pizza.
In general, serial or long-term projects seem potentially divisive. I love a semester-long or serial project if it's something I'm invested in (usually because I had some control in picking it), but if I'm not, it tends to have the opposite effect. I associate long-term projects with upper-level courses where students have more agency and cohorts are smaller.
Regarding autograders, "pushback/criticism from other educators" is an interesting remark. I'd be curious to hear more. A CS101B-level Python course I took at a community college in 2016 had a homebrew service that the instructor wrote which he used to grade assignments. Students submitted their assignment code after SSHing into the college server. I suspect the resistance and frustration expressed by some students was due to low technical sophistication, but also feeling like it was an alienating, robotic and inhumane way to run a class (oh, the irony) -- the professor didn't even look at my code before flunking it! One student called the instructor something to the effect of a pretentious geek before dropping the class.
In hindsight, the professor hadn't done anything particularly shocking to an experienced programmer, and making students use SSH and the command line should have been seen by them as part of the programming knowledge skillset they were there to learn, so maybe the problem was creating the correct narrative behind the tool. I can see fellow educators being resistant to tooling as well for various reasons, but I also suspect we're all more comfortable with automation in education than we were in 2016, for better or worse.