Ah that explains why I haven't hit that issue yet! I avoid using @export for loading levels specifically!
exported custom property that accepts a PackedScene that represents the next scene of your game level
Behind the scenes the @export decorator functions similarly to a preload call. Meaning that when you load a scene that contains an @export anywhere in it, that exported property will be preloaded, aka loaded from disk into memory. If you have a Level1 scene, with an export to Level2 anywhere in it, and then Level2 has an export to Level3... you see where this is going. If you do it this way you load your entire game as soon as Level1 is loaded! This isn't necessarily that bad for a very small game, it even will reduce load times! But generally I prefer to use a system that will "lazy load" my levels only when they're being switched to! This preloading is also what causes the circular dependency!
You saying "Java" made me guesstimate your age
I'm only 25! lol.
I worked with C a lot too for fundamental classes involving low level concepts like OS, Multithreading, etc, but one of my professors who focused more on the development of actual software was a Java guy! So when I would take classes with him he wanted us to work in Java! He usually allowed us, or even asked us to make video games for the class because they're just more fun! I ended up developing custom particle systems, video players for cutscenes, "shaders" (we couldn't access the GPU, so really just forcing the CPU to run processes on pixel arrays and then using the array as an image, which required a lot of optimization!) I could go on and on, but I really enjoyed hacking together a game "framework" from the ground up! I still find graphics programming my favorite!
Anyways, more rambling! Thanks for giving me a chance to reminisce!