JSFML - Information

[pdinklag]

JSFML is the official Java binding to SFML, a Java library that provides Java applications with access to a wide range of the functionalities of SFML.

Java has been missing a simple, straightforward, but at the same time efficient multimedia library. It is the goal of JSFML to provide such a library for Java developers by taking advantage of the straightforward design and blazing performance of SFML.

What JSFML is and is not
JSFML is a Java binding to SFML. It is not Java re-implementation of SFML. This makes JSFML relatively easy to maintain and ensures that it can be updated to the latest SFML release, including all new features and bugfixes, in a minimal amount of time.

Features
JSFML focuses on bindings to the Graphics, Audio and Input features of SFML as well as all related helper and utility types. Features like multi-threading, networking and unicode support, which Java provides out of the box, are not considered.

Planned features include integration of SFML RenderWindows into AWT / Swing applications, which would also allow the use of SFML in browser applets.

JSFML works on Windows and Linux systems (Mac OS X is planned as well!). The "self-contained" package includes automatic extraction of the platform-specific binaries from the jar file into the user's home directory. This way, developers will not have to bother with packaging JSFML properly, but can simply redistribute the JSFML library as one single jar file.

Conventions
Since JSFML is a binding to SFML, the API will be layed out similarly. However, some things done in C++ are not possible in Java. This includes const references and operator overloading. JSFML follows the following principles:

• Overloaded operators for SFML objects are represented by appropriately named static methods within the class in question.
• Objects passed to JSFML methods are never modified by those unless it is explicitly mentioned in the documentation.
• Objects retrieved from SFML that should not be altered, such as the default font or a render texture's texture object, are of an invisible immutable subtype and reject any change attempts silently.
• A range of method parameters is marked as @NotNull. If null is passed for these parameters, JSFML will throw an IllegalArgumentException.
  

For a seamless Java integration, the following conventions intentionally differ from those of SFML:

• camelBack naming convention for methods, ALL_CAPS naming convention for enum values and constants.
• Instead of returning a success value (true or false) when resources are loaded, JSFML throws exceptions if something goes wrong.

Source code
JSFML's source code is available from its Github repository: https://github.com/pdinklag/JSFML
Please refer to the notes found there in case you want to build JSFML.

Requests, ideas, bugs and other issues
Feel free to post these in this forum, but also consider getting a Github account and post them in the Issue Tracker for better organization!

Tutorials
On the Github wiki: https://github.com/pdinklag/JSFML/wiki

Javadoc
A Javadoc for JSFML can be found at: http://jsfml.org/javadoc/

Releases
There are no releases of JSFML just yet, but stay tuned to this forum for test pre-releases!
JSFML is set for a first official release not long after the official release of SFML 2.0.

[Hiura]

Great! I'll have a look in a few days!  

[kidchameleon]

Looks interesting!

[Astrof]

Wow I didn't even know this existed until I scrolled down the forums and saw a new Binding! I remember when I first found SFML a few years back there were some arguments about whether or not to start a Java binding; what changed now?  Java was the first language I learned so I still feel a bit attached to it.  Back in high school when I was learning Java I tried to learn JOGL but gave up, but now there's JSFML! 

Though I don't program much in Java anymore if needed I can provide some tips, ideas, moral support, etc.  ^_^

[Groogy]

The bindings are more or less maintained by volunteers. Laurent only maintains the C and .NET bindings himself.

So what changed? Someone felt like it would be a fun thing to do

[pdinklag]

Wow I didn't even know this existed until I scrolled down the forums and saw a new Binding! I remember when I first found SFML a few years back there were some arguments about whether or not to start a Java binding; what changed now?  Java was the first language I learned so I still feel a bit attached to it.  Back in high school when I was learning Java I tried to learn JOGL but gave up, but now there's JSFML! 

Though I don't program much in Java anymore if needed I can provide some tips, ideas, moral support, etc.  ^_^

It's not really advertised yet, because there is no release yet. It will be launched after SFML2 has been released and a certain feature has been added (manually closeable audio device).
I'm sure Laurent will mention it on the main page once there is a release.

What changed? Well, Groogy nailed it. I was on the hunt for a good 2D OpenGL based game / multimedia engine for Java, only to find out there is none.  JOGL is dead for what I know. There is LWJGL, but much like JOGL, it's merely a binding to OpenGL. So without any good OpenGL knowledge, LWJGL doesn't help you a bit. So I had the idea to create a Java port to the best C++ library I could personally find, and that happened to be SFML after quite some evaluation of others.

Go ahead if you got any ideas for the future. The first release is going to be a "simple" binding to parts of the SFML API. Once that is running, the goal will be a seamless Java integration. I appreciate any support and ideas.

[pdinklag]

The lack of const in Java just made me do a rather drastic - but reasonable and common - design decision. "Primitive" type classes like vectors, rectangles, colors and time will be immutable, ie you cannot change an instance of them once created. This has several advantages, among them is the ability to have global constants (like Color.RED, which I protected using an invisible immutable type until now - bad coice) and inherent thread safety. The only drawback is that mathematical operations (like vector additions) or single component modifications will become a bit more verbose, because a new object needs to be created. Performance-wise, these things come nearly for free, so that's not an issue.

In other news, I started writing tutorials and will soon commence building a release candidate based on an SFML 2.0 RC snapshot. If all goes well, JSFML could be released very shortly after SFML 2, which would be a great thing.

[Laurent]

This looks like a good decision. As far as I remember, immutable types are quite common in Java, and it solves some design issues. I should probably do the same in the .Net binding.