So I want to develop a small game engine. This has the main engine classes like a Vector and Actor for the user to use. Since I only need the engine once, I want to make the games use the same engine, and to avoid having all games in the same jar, I intend to have them in separate folders, one with the engine, and then folders for each game. The engine should then be able to load the eg. Player class from the other folder and utilize it.
I thought one solution could be compiling the game folder at runtime. But then the problem would be that the files depend on each other and on compiled classes already loaded in the JVM. For this approach:
So as an example, we have three classes: An Actor from the engine, a Player extending the engines actor class written by the user, and a third class, the item, written by the user, spawned in Player, but again needs the Player to be compiled, meaning they can't be compiled one after the other.
To my understanding, the Actor will already be compiled in the JVM when we run the program. Now we know a folder with all the classes to compile, where the Player depends on the compiled class in the JVM and the uncompiled class in the folder, which depends on the Player.
Now I want to compile the Player class, whereby we must also compile the Item, and then instantiate the Player so we can move around and spawn items.
Here a basic example of what I mean:
// already compiled in eg. executing jar file
class MainStuff
{
public static void main(String args[])
{
String FolderOfUncompiledClasses = "Some/folder/to/src/";
Class<?>[] CompiledClasses = CompileFolderContents(FolderOfUncompiledClasses);
// iterating through compiled classes
for (Class<?> C : CompiledClasses)
{
// if we have an Actor class, we create a new instance
if (C.isAssignableFrom(Actor.class))
{
try
{
C.getDeclaredConstructor().newInstance();
} catch (InstantiationException | IllegalAccessException | IllegalArgumentException
| InvocationTargetException | NoSuchMethodException | SecurityException e)
{
e.printStackTrace();
}
}
}
}
// should compile all the files and returns the classes of the compiled java files
private static Class<?>[] CompileFolderContents(String Folder)
{
File[] JavaFiles = new File(Folder).listFiles();
Class<?>[] CompiledClasses = new Class<?>[JavaFiles.length];
for (int i = 0; i < JavaFiles.length; i++)
{
Class<?> CompiledClass = DoCompilationStuff(JavaFiles[i]);
CompiledClasses[i] = CompiledClass;
}
return CompiledClasses;
}
// this should effectively compile the class which it can both use non compiled
// java files in the folder and already compiled classes
private static Class<?> DoCompilationStuff(File ToCompile)
{
return null;
}
}
// already compiled in eg. executing jar file
class Actor
{
int X, Y;
}
In a folder somewhere on the drive:
// not compiled
class Player extends Actor
{
public Player()
{
// uses other non compiled class
new Item();
}
}
// not compiled
class Item
{
// Also uses Actor so we can't compile them in series
public Item(Player P)
{
}
}
I've tried using the javac command but I can't get it to work with an entire folder structure somehow.
I hope I explained it in a logical way and if this approach doesn't make sense. This was just an idea, if you have a better approach I would be very happy to hear it.
Thank you very much!
If you really have to use javac keep the classes in the same package and directory. This will simplify the build process, instead of having to use -cp argument to specify the class-path existing across multiple different directories.
I'd recommend that instead of compiling manually you should setup a project using a build system e.g. Gradle. If you look at Building Java Applications Gradle docs it should take around 10 minutes and you should have everything you need: build, tests and packaging.
Related
The gradle build of Gluon plugin (in Netbeans 8.0.2) for porting JavaFX to Android creates the following directory structures:
Source Packages [Java]
Android/Java Packages
Desktop/Java Packages
Ios/Java Packages
Each of these directories contain java packages inside them. Generally Gluon build would create the "main" class for us in one java package inside "Source Packages" directory [the name Packages with "Source Packages" might be misleading since it is not a Java package, its just a file system directory]. This main class extends Javafx Application class and thus is the entry point into our application.
The Android API is accessible only in Android/Java Packages directory for any java package created inside it. Say, the android.Vibrator class is only referr-able here.
The problem is, we cannot refer to a class created inside any Java package inside Android/Java directory to any java package created inside Source Packages [Java] directory!! If this is the case then how would we take the application forward from the start() method of javafx.Application into say android.Vibrator.
The gluon project structure has a snapshot at: How to reference android.jar in Gluon Project
As you know, JavaFXPorts project allows deploying JavaFX apps in Desktop, Android and iOS devices. When it's just pure JavaFX code, the project is added on the Main scope, and from there it will be visible in all those platforms.
Only in the case you need some platform specific code, you should add it on the corresponding package.
As you have mentioned, by default from the Main package you won't see the added code in a platform package, so you have to provide a way for that.
If you check the HelloPlatform sample on JavaFXPorts repository, you will find a PlatformService class to load the packages using ServiceLoader.
Another possibility is using Class.forName() to load dynamically the classes at runtime, once we know the platform where the app is running.
I suggest you have a look at the Gluon Down project, that manages for you several platform specific services, and provides you with uniform, platform-independent API.
For those services not available yet in Down (feel free to contribute), you can implement them like in this simple app created using Gluon Plugin.
Source Packages [Java]
First, create a getPlatform() method, and add the referred classes to each specific platform. For instance, add org.gluonoss.vibrator.GluonAndroidPlatform.java on Android package.
public class GluonPlatformFactory {
public static GluonPlatform getPlatform() {
try {
String platform = System.getProperty("javafx.platform", "desktop");
String path = "org.gluonoss.vibrator.GluonDesktopPlatform";
if(platform.equals("android")) {
path = "org.gluonoss.vibrator.GluonAndroidPlatform";
} else if(platform.equals("ios")) {
path = "org.gluonoss.vibrator.GluonIosPlatform";
}
return (GluonPlatform) Class.forName(path).newInstance();
} catch (ClassNotFoundException | InstantiationException | IllegalAccessException e) {
System.out.println("Platform Error "+e.getMessage());
}
return null;
}
}
Now, create an interface, with the method you want on all your platforms:
public interface GluonPlatform {
void vibrate();
}
Finally, on your main class retrieve the platform and call your method:
#Override
public void start(Stage stage) {
final Button button = new Button("Click me!");
button.setOnAction(e-> GluonPlatformFactory.getPlatform().vibrate());
StackPane root = new StackPane(button);
Rectangle2D visualBounds = Screen.getPrimary().getVisualBounds();
Scene scene = new Scene(root, visualBounds.getWidth(), visualBounds.getHeight());
stage.setScene(scene);
stage.show();
}
Desktop/Java Packages
Add the vibrate method. For now leave it empty, but you could add a Timeline to move the button, for instance.
public class GluonDesktopPlatform implements GluonPlatform {
#Override
public void vibrate() {
System.out.println("Vibrating!");
}
}
Android/Java Packages
Add the vibrate method. Notice that we have to use FXActivity, which is the bridge between the JavaFX thread and the Android activity.
public class GluonAndroidPlatform implements GluonPlatform {
#Override
public void vibrate() {
Vibrator v = (Vibrator) FXActivity.getInstance().getSystemService(Context.VIBRATOR_SERVICE);
v.vibrate(500);
}
}
Don't forget to add the required permission on your AndroidManifest file (you will find it under src/android/AndroidManifest.xml.
Now you can deploy the project and run it on Desktop (gradlew run) and it will work, and install it on Android (gradlew androidInstall), and it will work too.
I am making my first Android plugin by extending UnityPlayerNativeActivity. The package name is com.inno.myPlugin and that name is registered in Manifest.xml in Plugins/Android folder.
The class that extends "com.inno.myPlugin" is "MyClass".
The plugin is compiled as .jar file and it uses "AndroidJavaClass" and "AndroidJavaObject" on Unity side to call functions and is placed in Plugins/Android folder.
Each time I compile my example, on my android device, the app package name is always "com.inno.myPlugin". Even when I change the package name from Unity settings, the default package name is still the package name from the jar plugin which is "com.inno.myPlugin". The package name can only be renamed from the source code of the jar file...
I want to publish the plugin to Unity Asset store but I have a question that is bugging me.
If the package name "com.inno.myPlugin" is already used on the Android store, will this prevent the user of my plugin from uploading their app with this plugin?
How do I solve this problem of package naming?
This is one of the larger issues with Unity Android Plugins.
There's a few possibilities here. Use the below to get to the right answer
a) Does your plugin require that the Main Activity (i.e. Launcher activity) be "com.inno.myPlugin.MyClass"?
b) Do you override OnActivityResult in MyClass?
c) Neither of the above
If you answered yes to (a), then there's very little possibility that anyone but yourself can use this plugin, for a variety of reasons ranging from others being unable to tweak your code to conflicting packages.
If you answered yes to (b), then there's a decent possibility that others can use it, but they cannot use it if ANOTHER plugin requires that privilege as well
If you answered yes to (c) you should be good.
Easiest way to test it is to use your plugin in a fresh project, with a different package name, and check to see if it works.
Also, I'd advice that you stay away from extending UnityPlayerNativeActivity. The only reasons to extend UnityPlayerNativeActivity are
To get the currentActivity (i.e. UnityPlayer.currentActivity)
To use unitySendMessage
You can get both of these using reflection. currentActivity is a field, and unitySendMessage is a method. I won't go into detail here since it's not directly relevant to your question, but feel free to ping if you need some details.
Edit Adding some example code on request by the OP
Here's a sample plugin I made without extending UnityPlayerActivity or UnityPlayerNativeActivity. Note that I've just typed this straight in here, so there are probably errors in the code. One thing I know for sure is that the native code requires try-catch blocks, but any IDE should show up the error when you paste the code in.
Native Android Code
package com.myCompany.myProduct;
public class MyClass {
private Class<?> unityPlayerClass;
private Field unityCurrentActivity;
private Method unitySendMessage;
public void init () {
//Get the UnityPlayer class using Reflection
unityPlayerClass = Class.forName("com.unity3d.player.UnityPlayer");
//Get the currentActivity field
unityCurrentActivity= unityPlayerClass.getField("currentActivity");
//Get the UnitySendMessage method
unitySendMessage = unityPlayerClass.getMethod("UnitySendMessage", new Class [] { String.class, String.class, String.class } );
}
//Use this method to get UnityPlayer.currentActivity
public Activity currentActivity () {
Activity activity = (Activity) unityCurrentActivity.get(unityPlayerClass);
return activity;
}
public void unitySendMessageInvoke (String gameObject, String methodName, String param) {
//Invoke the UnitySendMessage Method
unitySendMessage.invoke(null, new Object[] { gameObject, methodName, param} );
}
public void makeToast (final String toastText, final int duration) {
currentActivity().runOnUiThread(new Runnable() {
#Override
public void run() {
Toast.makeText(getActivity(), toastText, duration).show();
}
});
}
}
Unity C# code
AndroidJavaObject myClass = null;
public void Init () {
if(myClass == null)
myClass = new AndroidJavaObject("com.myCompany.myProduct.MyClass");
if(myClass != null)
myClass.Call("init", new object[0]);
}
public void MakeToast (string toastText, int duration) {
if(myClass != null)
myClass.Call("makeToast", new object[] { toastText, duration } );
}
For the Manifest, change it to whatever you're calling the package name to be. Note that it DOES NOT have to match the package for the plugin! So, for example, here our plugin's package name is "com.myCompany.myProduct", you can use a package name like "com.someOtherCompany.someNewProduct"
How to test this plugin.
1. Add the native code above to "MyClass.java", and create a jar.
2. Copy this jar into Assets/Plugins/Android folder in your Unity Project.
3. Ensure that the package name is not the default package name in Unity
4. Copy the Unity C# code above into a new script
5. Put in some OnGUI code to call the "Init" & "MakeToast" methods in C#
Source - My expertise making plugins for Unity.
I am trying to use a library that uses JNI.
I've tried the sample app provided by the developers and it works. So I know it's not a bug in the library.
I assume I'm doing something wrong in the process of importing the library:
copy the .so file into my libs folder (its called libjniRTSP.so)
copy the the jniRTSP.java (summarized below) into my project:
public class jniRTSP {
private volatile static jniRTSP libRTSP = null;
public static jniRTSP getInstance() {
if(null == libRTSP) {
synchronized(jniRTSP.class) {
if(null == libRTSP) {
libRTSP = new jniRTSP();
libRTSP.InitProductList();
// DEBUG
libRTSP.SetDebugView(1);
}
}
}
return libRTSP;
}
static {
try {
System.loadLibrary("jniRTSP");
} catch (Exception e) {
e.printStackTrace();
}
}
public native int GetBrandEnableRecorder();
public native int GetBrandEnableLocal();
public native int GetBrandEnableRemote();
...
then in my onCreate() I try to call one of the methods:
jniRTSP.getInstance().Init(.....)
Which returns the error:
UnsatisfiedLinkError: Native method not found com.myuniquepackage.jniRTSP.InitProductList:()I
UPDATE (FIX): instead of just copying the jniRTSP java file, I copied the whole package that contained it, keeping the same package name. I'm not sure if this fixed it because the package name was the issue, or if because it needed one of the other java files that were in that package. Although I'm pretty sure if it was a missing file, it would complain at compile time.
Fairly certain the package declarations have to be the same inside the C code as the Java code.
So the class jniRTSP should be in the com.myuniquepackage package in Java and have the native method InitProductList declared and the C code should have method declared as Java_com_myuniquepackage_jniRTSP_InitProductList
By moving the class you are probably breaking the link, change the package declaration in Java to match the demo project and see if it works, if it does you can change it back and then change it in the C code which is a bit more time consuming but easy enough.
I encountered a compilation issue under Linux.
I'm compiling java programs on Linux; the target use is both Linux and Windows.
The code check if in there are platform specific classes (as shown in the code below).
So if the code is running under Linux, the specific Windows code will not be executed.
The issue arise on the use of a platform specific class Win32MediaTray
The compile error reported is
PrinterScanner.java:9: error: cannot find symbol
import sun.print.Win32MediaTray;
^
Is it possible to compile it under Linux? Or is it just impossible?
I can use some workaround (reflection?)
Needless to say that the compilation under Windows gives no errors.
Thankyou for your help.
For reference, the code behind this issue is the following:
private String getTrayName(Media media) {
String result = "id:" + media.getValue();
boolean isWin32 = media.getClass().getName().equals("sun.print.Win32MediaTray");
if (isWin32) {
Win32MediaTray w32 = (Win32MediaTray) media;
result = result + ",winId:" + w32.winID;
}
return result;
}
I believe that the class you are trying to use is sun.print.Win32MediaTray.
And the answer is that you cannot use it ... or compile a class that uses it ... on a Linux release of Java. That class is not included in the rt.jar file on a Linux release of Java.
Furthermore, you shouldn't be using it. The Java documentation makes it very clear that application code should not make use of classes in the sun.* package hierarchy.
If you have no choice but to do this, then your best bet is to use reflection to fetch the value of that w32Id field. You'll also need to deal with the case where the media object is not an instance of the Win32MediaTray class. Beware that you are relying on implementation details that Oracle says specifically that you shouldn't. There is a risk that they will change (without notice!) in some future Windows release.
The other alternatives are:
Implement your own platform adapter classes with a different one for each platform. These have to be compiled separately on each platform, and then dynamically loaded.
Implement separate codebases for each platform.
To make the compiler happy you could implement a dummy class named sun.print.Win32MediaTray and make it available both on the compile and runtime classpath. The class doesn't need to work, it only has to be API compatible (same signatures and return types, but in this case you only really need to extend Media and have a public int winID), so that you can satisfy both the compiler and the verifier.
At runtime, the version included in rt.jar should be loaded on Windows thanks to loading delegation. On Linux, the dummy version is the only one available, but you stated that the program checks for the platform and executes another branch of code, so it shouldn't cause your program to fail.
For example, with the following class on the classpath:
package sun.print;
import javax.print.attribute.standard.Media;
public class Win32MediaTray extends Media {
public int winID = 0xBADC0DE;
protected Win32MediaTray(int value) {
super(value);
}
static {
System.out.println("Won't see me on Windows");
}
}
I managed to run this program on Windows:
public class Main {
public static void main(String[] args) {
PrintService[] services = PrintServiceLookup.lookupPrintServices(null, null);
for (PrintService svc : services ) {
DocFlavor flavor = DocFlavor.SERVICE_FORMATTED.PAGEABLE;
Object o = svc.getSupportedAttributeValues(Media.class, flavor, null);
if (o != null && o.getClass().isArray()) {
for (Media media : (Media[]) o) {
if ( media instanceof Win32MediaTray )
System.out.println( ((Win32MediaTray) media).winID );
}
}
}
}
}
The message in the static initializer is not printed on Windows, because the definition that is actually loaded is the one from rt.jar. Obviously, the code can be compiled on any platform.
How about putting the code that uses windows-specific stuff into a separate jar; then you can compile and include that jar on windows, and leave it off systems otherwise.
One standard way to do this is to have one or more interfaces used by your application code; you can have a factory provide the implementing classes or inject them with Spring or whatever. But I think rather than "how can I compile this on Linux" your question should be "I have this Windows dependency in an app targeted at multiple operating systems, how do I handle it?"
I have a large desktop Java application and I want to allow other developers to develop plugins for. Plugins will be jars placed in a specified dir. They will not be on the classpath at startup. I will load and deploy them at runtime.
The complication is that some plugins will have dependencies on each other, as well as the core application. So I cannot load each plugin/jar in its own URLClassLoader. Therefore I want to load all plugins into 1 URLClassLoader. Furthermore, some plugins may fail to initialise for various reasons. And I only want a ClassLoader at the end of day that knows about the successfully loaded plugins. The reasons are quite bizarre and relate to some legacy stuff that is using reflection to instantiate classes. This needs to fail if the plugin doesn't initialise for classes defined inside the plugin jar that failed.
Without this requirement, the solution would be:
Collect the jar URLs and build a ClassLoader based on them
Try to initialise a plugin class from each jar (defined in config in the manifest)
Now the ClassLoader here would be passed to the legacy system for it to use for its reflection stuff. However, it's my understanding that it will still be able to instantiate classes from plugin jars whose plugin failed to initialise (since the jar will still in the URL[] of the ClassLoader). Hence this breaks my requirement above.
The only solution I have come up with so far is to create a custom URLClassLoader as follows (simply to allow access to findClass()):
public class CustomURLClassLoader extends URLClassLoader {
public CustomURLClassLoader(final URL[] urls, final ClassLoader parent) {
super(urls, parent);
}
#Override
protected Class<?> findClass(final String name) throws ClassNotFoundException {
return super.findClass(name);
}
}
And then I made another custom ClassLoader that essentially knows about multiple child ClassLoaders:
public class MultiURLClassLoader extends ClassLoader {
private Set<CustomURLClassLoader> loaders = new HashSet<CustomURLClassLoader>();
public MultiURLClassLoader(final ClassLoader parent) {
super(parent);
}
#Override
protected Class<?> findClass(final String name) throws ClassNotFoundException {
Iterator<CustomURLClassLoader> loadersIter = loaders.iterator();
boolean first = true;
while (first || loadersIter.hasNext()) {
try {
if (first) {
return super.findClass(name);
} else {
return loadersIter.next().findClass(name);
}
} catch (ClassNotFoundException e) {
first = false;
}
}
throw new ClassNotFoundException(name);
}
public void addClassLoader(final CustomURLClassLoader classLoader) {
loaders.add(classLoader);
}
public void removeClassLoader(final CustomURLClassLoader classLoader) {
loaders.remove(classLoader);
}
}
Then my loading plugin alogorithm will be something like
MultiURLClassLoader multiURLClassLoader = new MultiURLClassLoader(ClassLoader.getSystemClassLoader());
for (File pluginJar : new File("plugindir").listFiles()) {
CustomURLClassLoader classLoader = null;
try {
URL pluginURL = pluginJar.toURI().toURL();
final URL[] pluginJarUrl = new URL[] { pluginURL };
classLoader = new CustomURLClassLoader(pluginJarUrl, multiURLClassLoader);
multiURLClassLoader.addClassLoader(classLoader);
Class<?> clazz = Class.forName("some.PluginClass", false, multiURLClassLoader);
Constructor<?> ctor = clazz.getConstructor();
SomePluginInterface plugin = (SomePluginInterface)ctor1.newInstance();
plugin.initialise();
} catch (SomePluginInitialiseException e) {
multiURLClassLoader.removeClassLoader(classLoader);
}
}
Then I can pass the multiURLClassLoader instance onto the legacy system and it will only be able to find classes (via reflection) whose plugin successfully loaded.
I've done some basic testing and it seems to work as I'd like so far. But I would very much like someones opinion on whether this seems like a good idea or not? I have never played this much with ClassLoaders before and I am wanting to avoid getting myself in too deep before its too late.
Thanks!
The problem I see is that if you don't know in advance which plugin depends on which, it's very hard to do anything reasonable, to debug problems, to isolate non-functional or bad-behaving plugins, etc.
Therefore I'd suggest another option: Add another field into each plugin's manifest, which will say on what other plugins it depends. Perhaps just a list of other plugin JARs it needs to function. (The core application classes would be always available.) I believe this would make the design much more robust and simplify many things.
Then, you could choose from different designs, for example:
For each plugin you could create a separate ClassLoader that would load just the JARs it needs. Probably the most robust solution. But I see a drawback: plugins that act as dependencies for many other ones will be loaded repeatedly in different class-loaders. It depends on circumstances (plugin count, JARs size, ...) if this could be a problem or not, it could even be an advantage.
You could have one big ClassLoader for all plugins, as you suggest, but you could ask it for plugin classes in the order of their dependencies. The ones that don't depend on anything first, then the ones that depend on those first ones etc. If some plugin class fails to load/initialize, you could immediately discard all plugins that depend on it.
Are you looking for something like the OSGi approach?
You could do something like Petr Pudlák has said, however you should take in account the fact that one of the solutions you have can create cyclic dependencies...