A lot of employers who advertise for "2-3 years experience" are not necessarily looking for someone who can use a particular technology (You mention Java EE), but for somebody who has acquired the kinds of soft skills which can only really be gained from working on real projects with other engineers, with real pressures, meeting real deadlines.
As cliche as it may sound, you'd probably need a disproportionately higher wealth of technical knowledge in order to offset that. My guess would be that if you knew nothing about Java EE, but had several projects to your name of some other kind (Maybe even non-programming projects), accompanied by all the mistakes and realisations which you get from working on them, you'd have a better chance at those particular jobs because many employers tend to be more interested in taking on somebody who understands the pressures & priorities, and who will be capable of learning specific technologies along the way.
--
As an example, the first project I ever worked on put me in a position where I had to work with another junior engineer with supervision from the project manager; We both developed our respective parts with no problems. Later, we went through an integration stage with the existing system, whereby we had both assumed that everything would "just work" - as it turned out, the integration ended up being extremely painful, tedious, slow, difficult, and resulted in a huge number of defects and regression issues turning up.
We also fell foul of "team process" issues, where particular steps had been overlooked resulting in a breakdown of communication between engineers and other project stakeholders - The QA testers on the project had been out of the loop, and a whole bunch of issues didn't get elevated to the project manager in time for them to be dealt with. Finally, we landed ourselves in a steep learning curve with all of the company's tools and figuring out how the existing large code-base worked.
The end-result was delay to the project, and weeks of frustrating re-work while we trawled through tens-thousands of lines of code to understand where we'd gone wrong, and iron out the unforseen problems. These are the sorts of mistakes which shape you as an engineer, and make you much better at project work. Unfortunately, nobody can really be taught this kind of experience from a book or in a classroom, it can only be learned the hard way; and really the only opportunity to do something like that is to get yourself involved with real projects.
Also, the work involved getting dirty with build scripts, installers, project tracking tools, creating documentation, etc. The whole project probably involved less than 10% time actually "creating code", with the other 90% doing all of the supporting work to make sure everything is right. This is not uncommon, but is something else which most graduates tend not to be prepared for when they first start out (Every junior who walks into their first job expecting to spend 7.5 hours a day programming always has a shock when they're asked to sit down and solve their first "difficult" problem buried somewhere among a million lines of code)
There are certainly plenty of employers out there who will take on graduates/juniors, and those employers understand the necessity of learning through mistakes (they'll likely also be more than happy to take on an engineer at a significantly lower wage than the ones who already have had several years of continued "real world" learning). It's a matter of finding the right job, and getting into the right opportunity to learn all the hard lessons for yourself.
