Java Library written IN Java

Engines, Libraries and Tools
#1

The other day I was considering the fact that most of the Java libraries that the community uses - they all use native code. So I was thinking, - why doesn’t the community together write a rendering library, or something like that, and put it all together. So I realized that I could have an engine that has 3 components:

The rendering:
The math:
The physics:

But then again, this may take a long time to do. So I would really appreciate the community’s support for this!

Also at the same time, OpenGL is not community - based, and cannot be built upon freely.

https://github.com/RTEKGamesInc/MangoOrange

#2

JOML is already fairly complete for the math part.

#3

While it is not community based, it can be built upon freely.

#4

Java already has a built in software renderer called Java2D, (java.awt, java.awt.geom, java.awt.image) which doesn’t rely on native libraries.

If you’re talking about using hardware acceleration, even if you do write a rendering library it’s going to need some form of machine-code. Meaning natives for different system architectures and all. :persecutioncomplex:

I’m not bashing your project it’s always cool to see a new software renderer now and again! But the definition of software rendering means it’s all done on the JVM side, meaning no GPU! The performance will not compare to LWJGL.

If you write a good graphics library that’s decoupled from the AWT framework that’d be cool! (Assuming it can render to a AWT canvas). Think about it, we can render stuff on the CPU side and send it to the GPU later, and fix the TTF problem!

#5

Java actually has full hardware acceleration, using Buffer Strategies. https://docs.oracle.com/javase/tutorial/extra/fullscreen/bufferstrategy.html

#6

JavaFX

#7

Stop making engines. Make geimz!

#8

Hi

What is wrong with using “native code” under the hood? Java2D has some hardware accelerated pipelines (it has a software renderer too), OpenJFX / JavaFX too. Whatever you will create, you will rely on “native code”. JOGL has its own windowing toolkit, it’s mainly written in Java but it needs to communicate with the native windowing system somehow and it’s the same for Swing and even more for SWT. Moreover, there are already several excellent 2D and 3D software renderers, 3DzzD is the fastest that I know. Why not spending your precious time in writing a game instead of writing another tool that you’ll be mostly alone to use? What’s the point of creating yet another library / engine / framework?

#9

Here’s the thing.
As a programmer, I can’t fiddle around with the native code. I don’t understand how it works. And if there’s some bug in the native code, there’s nothing I can do about it. Nothing.

#10

You can report it to the respective library owners. They are sure to fix it, because it lies in their own interest that their own libraries are bug-free/usable.

So unless you want to drive a nuclear power plant with 100% mathematically-proven bug-free code, in which case you would not even use a Java Virtual Machine or not even off-the-shelves OS’es and PCs, then it is perfectly fine to use native libraries and their respective Java wrappers.

#11

If I follow your reasoning, then you can’t use the standard Java APIs. Moreover, if you’re able to understand Java, you’re probably able to understand a bit well written code written in C.

Do you know JavaOS and JNode? Both are operating systems mainly written in Java. The latter uses some code written in assembly language as writing a full Java stack is impossible.

Actually, it’s possible to minimize the recourse to Java libraries heavily relying on native code (especially bindings) but it’s impossible to use a 100% Java software stack to write a software.

#12

And how many times do you run into this in major graphics libraries? I’m going to guess very rarely as these libraries are tested extensively before being released. And if you do encounter a bug, it will most likely be fixed swiftly.

#13

I never walk on public roads… imagine there was a pothole… I cant fix that shit, why even bother. :smiley:

#14

Okay I understand you didn’t like native code, but why exactly? Your idea is completely wrong. I have a question for you on this regard.

Why develop in Java? The code is run on a JVM, which is written in C++, so IF THERE IS A BUG IN THE JVM, YOU CAN’T DO ANYTHING!!!

The answer is, there is native code under everything that you are using. Consider a basic swing application in Java. Here is what you will be having.

[] You create a frame, and frame requires native code.
[] The frame requires a window, and a handle to paint on, requires native code.

Now assume that you are writing an application in C++, and here is how you’ll be having native code.

[] The application is linked into a stub program which calls your main or WinMain, it’s native code.
[] You create a GUI application and start an event loop, the events comes from the OS, which are native code.

Finally assume that you are writing an OS itself, the OS depends on a bootloader to open, which is native code. The bootloader needs a kernel, which is native code.

As you see, you CANNOT avoid native code, and there is so many layers that help you run your program, what if the support for them was dropped or if the OS got security issues??

That’s none of our business, all we have to do is report them if we find any such bugs/issues, and I can guarantee that these issues will be fixed by the respective developers pretty quick, as they have large user base, and they don’t want their users to suffer.

I don’t want to offend you, but I doubt whether you’re having a Not Invented Here syndrome…

#15

Writing custom renderers just for fun is cool, you just need to realize that you only do it for fun and it will not be usable in any real world scenarios.

#16

For those that like writing everything from scratch in Java there is plenty of opportunity to and there is also plenty of opportunity to contribute to existing project written in Java. For those that like to use what ever is out there, which includes JNI projects then again there are plenty of choices.

Luckily for us there is enough to satisfy everyone :smiley:

The opening poster was merely suggesting, for those that are interested in writing some java only libraries that they could get together and do that. Saying Java is written in c++ does not really help, Java code can be written / compiled once and deployed to where ever the c++ JVM is. JNI code needs a per environment compile and that is what the opening poster is trying to avoid.

So staying on topic, good luck SirMathhman on your endeavour. It is not a bad one, I won’t have time to help out but would be interested in your physics engine if you get one going. JOML is already quite mature for a pure java solution in the math regards and for rendering opengl / vulcan is the way of the future so I will be sticking with that.

#17

Actually, there is a good use for software rendering: Occlusion Culling by Software Depth Testing.

Draw a bunch of occlusion bounding boxes with a software renderer into a depthbuffer, then check with another pass if the bounding boxes of any object are hidden by the pixels in the software depthbuffer. Its one of the fastest ways to do occlusion culling; the company Umbra is selling a library that uses this technique.

Someone should write a software renderer for occlusion culling in java…

#18

There are depth buffers in JavaFX. Doesn’t the 3D rendering in JavaFX include occlusion culling? Isn’t JavaFX 3D now a standard part of the JVM? I think the only limitation with it is whether or not the graphics cards support the functions being called.

What am I missing?

#19

Almost a standard part of the JVM… they’ve (very inconveniently) pulled it from the ARM builds.

Cas :slight_smile:

#20

I use JNA so I can get the access to native code, but don’t have to write any myself. I have an OpenGl library, use glfw3 for windowing…