I would suggest not rushing into trying to contribute unless you have a very willing mentor: I suspect it's relatively unusual for people to contribute to packages/programs that they themselves don't use (indeed, I would be worried if this wasn't the case). That is, if you are not actually consuming any open-source Java packages/programs, then you probably are not well placed to contribute to them because you don't understand their purpose, design, and usage, so you'll have little hope understanding the context of the code you might see.
(Anecdote: I got into open-source by accident when a library I was using was missing a feature I wanted. It was a totally natural thing for me to report the missing feature, and then proceed to implement it: despite having never looked at the code-base before, I already knew my way around the APIs, I knew how I would actually use the feature (so it was already designed in my head), and I knew which other feature I would copy-and-paste to get myself going.)
As such, I would strongly suggest - if you are not already - working on some personal projects where you can use some open-source packages: you will naturally become familiar with their design, and either you'll find problems you want to fix (which is ideal), or you'll be able to understand the context of other people's issues which is often necessary to produce a useful contribution.
You should also use your own projects to teach yourself how to use the tools you'll need to make open-source contributions: version control (e.g. git), IDEs (e.g. IntelliJ), built-tools (e.g. Maven), testing (e.g. JUnit), etc. (it's unlikely that a high-school education has equipped you to use all of these tools well, though I could be wrong)
Finally, contributing to open-source is a great and noble goal, but I'd further suggest not rushing into it because your contributions may just create work for the maintainers if you're not up-to-scratch, and that can be a miserable experience for everyone. My experience has always been that maintainers and other contributors will want to help you make your contribution, but this doesn't mean they actually have time to help you. As said in the comments on your question, issues marked 'good-first-issue' or 'easy' or whatever probably signal good issues for someone contributing to the project for the first time, but that doesn't necessarily mean they are suitable for someone contributing to any project for the first time.
Some obligatory notes on how to put a contribution together, because there is a lot more than just writing code:
- Read all the documentation on how to contribute: you may need to agree to a license, or perform other 'house-work' the first time around
- Look at other contributions to see what they look like: read 'resolved' comments in code-reviews to see what the maintainers are saying so that you don't make the same mistakes
- Take time to configure your development environment: you must run style-checkers and automated tests yourself if possible, otherwise you waste CI and maintainer effort (which may translate into your contribution being rejected/ignored)
In sum: if you are looking at the source files without the necessary context, you're liable to get stuck: this is true for everyone, even when they have years of experience with the language, because there is so much more to building software software than just the choice of language. Instead, build your confidence and competence by making your own software, steadily introduce the tools you'll need to contribute to open-source projects, and find open-source packages that can help you with your own projects: you will inevitably find issues with them, and because you ran into this issues as a consumer, you will be in a much better position to report and deal with them.
Once you've got your hand in, then it'll be much easier to pick up other people's issues on the same (or similar) projects, because you'll understand the context, have some familiarity with the codebase and tooling, and you'll hopefully understand the (non-trivial) workflow of making a contribution. Also, there is a good chance that if you find a problem, that other people will run into it as well (or indeed it may already have been reported): there is nothing selfish about only fixing issues that affect you.