Right now I only know of two:

http://jmonkeyengine.org/

https://www.lwjgl.org/

But these don't have a big GUI like Unity.

LWJGL isn't an engine. Its "just" provides bindings to OpenGL, OpenAL, and a couple of assorted libraries (jemalloc, nanovg, nuklear, etc). Fairly similar to starting from scratch in C++. The developer knows what he is doing, and its really nice stuff only if you want to start from scratch, and probably never finish anything.

jMonkeyEngine is a "proper" engine. With a GUI editor (last time I checked), and all systems (animations, ai, terrain, graphics, physics, etc) you need to make a game.

libGDX is more of a "framework", all the code, systems and infrastructure you need to start making a game, but code only. There are other projects that build editors on top of it.

As for something really on par with Unity but made in Java, nothing really. Big name engines are made in C++ with various scripting layers on top of it. I've seen Lua, C#, Python and C++ itself as "scripting" layers, but not Java (90% sure because native interop with Java is a PITA, and general distrust of Java as a language for doing anything making games).

There are possibly hundreds of mobile games made with libGDX, and a bunch made with jMonkeyEngine. LWJGL powers the rendering backends of both.

You misunderstand, there are very few products like Unity. Unity itself (C++ with C# sugar on top), UnrealEngine (C++ with more C++ on top) maybe CryEngine (C++, no idea what they use for scripting). And that's it.

By starting with Unity you just used probably one of the most well developed, inexpensive and friendly to use game engine you can find right now. You wont find something like that (popular, established, industry-proven, rich asset store, used by indies and big name studios, etc), except for a very few examples like I mentioned, and possibly other engines that are just stupid expensive (Adobe Stingray or maybe you could get EA to licence Frostbite to you if you got a million USD in your pocket).

I just said I've seen used it for scripting, like in Blender Game Engine, not that I've seen something "like Unity" in Python.

Maybe you could try out other scripting layers on top of Unity, IIRC they had a couple a while ago, maybe one in JavaScript, not sure.

You'll find tons of smaller projects like Godot engine (own scripting language), Paradox engine (C#), Love2D (Lua), rendering engines like bgfx, Ogre3D, Urho3D, but nothing with the same scale as Unity.

Anyway, I already gave you plenty of names to Google.

Java can work very well for game development. But while it is safe against crashes, it is not very "safe" for writing fast code. That said, just like you can avoid certain things in C++ and make your code safe ( use as little raw pointer code as possible), you can make your Java run very fast (cut back on garbage collection by using as few "new" and collections as possible). Java will then run blazing fast (faster than other languages which are not C** ).

That said, many game developers do not like java because it was originally not targeted at games. So you will find that you will need to write your own things even for basic stuff. For example: Performant code for in place linear algebra. That is the real problem with java. The game-related frameworks are under-developed and suck.

On the bright side though: C# is almost a copy of Java. In fact it's something purposefully rolled out after getting sued by "Sun" for infringing on their patents. With a good understanding of Java, it should not take you long to learn C#. The syntax is almost identical. The big advantage is that "XNA" used to be a big thing in game development, and as such there was a big community of people who like to write games, and use C#. So the ecosystem around C# for games is more mature. Also on windows you get to use Visual Studio which is awesome! The down-side is that C# sucks on Linux and Android (Mono historically is not good as pure "C#"). Also, good luck debugging cross-compiled C# code on native devices...

So if you want to make a game, go with Unity. C# should be a synch if you know Java.

That being said, lot's of people tell you not to write engines yourself because you won't finish your game.

While true that finishing your game is unlikely, you do learn a lot of stuff by writing your own low level code. Even if you do not finish your games it can be a very rewarding experience. As long as you are not doing this to earn money, then it is a terrible waste of time :P

Also, not less important then the engine is the Editor. One would argue that especially in the case of Unity, the editor is better than the engine. While Unity is not the "best" engine (not as performant, advanced, or flexible). It is by far one of the best editors (if not the best). A good editor saves you just as much work as a good engine. In Unity you can build your levels and set behaviours in a graphical environment. I like writing my own engines, and they achieve what I want them to. But when I need to collaborate with an artist, it becomes a nightmare. (Ex: Artist doesn't know how to work with the model-files that I support, Artist wants to try his art in a real level, etc...). So the biggest advantage of Unity's editor is that many "non-programers" on your team allready know how to use it. (artists, level designers, musicians, etc... )

I think basically the answer is... no, there isn't a "Unity for Java". But I'd say JMonkeyEngine is the closest thing you've got. libGDX is probably the main alternative (esp for 2D), but GDX scope isn't as broad and it's a little more centered towards multi-platform (mobile/web gaming crap I can't stand personally), which holds it back and distracts the developers somewhat. JME on the other hand, is a 3d engine. I don't know what Unity's toolset capabilities are, but JME does have custom IDE, pictured here: http://wiki.jmonkeyengine.org/sdk.html

If you're asking whether there's something like... GameMaker or whatever, I've never heard of anything based on Java like that. JME is still heavily Java code and shader dependent, but Unity doesn't eliminate that kind of thing either. I suggest giving JME a try.