The typical project life cycle:
- build something that's useful, but buggy
- people start using your software because it is useful
- people are annoyed because your software is buggy, and is missing important features
- people are so annoyed that they just write you a pull request
- you now have a contributor
- the new contributor has the feature they wanted, and leave
There are various ways to increase the probability that these steps work.
Building something useful is more easy when it is actually useful for you. What problem are you having? Are you sure there's no existing solution to this problem? For potential users: Is using your software easier than just reimplementing the useful parts?
How can users find your software? When they research their problems, make sure they find your software as a potential solution. E.g. write a tutorial. Create a simple homepage with the documentation. Blog about it. Pick a non-silly name. Keep your project looking alive and maintained. Release your software in easy-to-use formats, e.g. by uploading your Java software to Maven and adding JAR download to the project homepage.
If people want to contribute, how difficult is this for them? Make contributions easy by making sure the code is reasonably tidy and well-structured. A test suite is very helpful to avoid regressions. Set up an automated build. Host your development on a public git service, preferably GitHub.
Even then, there is no guarantee that your project will attract contributors. And the above loop might very well take years, not weeks. To be blunt: most projects just aren't actually useful. I have written a lot of non-useful open source software. The useful stuff I've done was either PRs to other projects, doing maintenance on existing projects later in their lifecycle, or blogging about technical issues.
Especially for many open-source projects that start in an academic context, there isn't a strong problem in the first place. The software is often just a vehicle for papers and graduation projects, which is a problem that is not shared outside of a working group (I say this as someone who has written such software). Hugely successful projects from academia tend to be common infrastructure or unrelated tooling that can be spun off. E.g. consider TeX, Numpy, or Pandoc.