FAQ (Frequently Asked Questions)
Do I need to run on Windows to create signed Windows exe's?
No, JWrapper can sign for Windows and MacOS on any platform, you just need to specify your certificate in the app XML.
No, JWrapper can sign for Windows and MacOS on any platform, you just need to specify your certificate in the app XML.
Do I need to run on a Mac to create signed Mac .apps?
No, JWrapper can sign for Windows and MacOS on any platform, you just need to specify your certificate in the app XML.
No, JWrapper can sign for Windows and MacOS on any platform, you just need to specify your certificate in the app XML.
Can I deploy anything other than Java using JWrapper?
Yes, JWrapper is an installer system which is well suited to Java and implemented in it but you can deploy anything using JWrapper. Python apps for example are another good match since they require a VM.
Yes, JWrapper is an installer system which is well suited to Java and implemented in it but you can deploy anything using JWrapper. Python apps for example are another good match since they require a VM.
Why do you produce a .tar on Linux? Why not .tar.gz?
The archived files are already compressed so GZIP doesn't add much. In addition (and more importantly) TAR files on Linux are automatically extracted all the way with just one double click, whereas TAR.GZ files in some cases require the user to go through two levels unnecessarily. So in short, there's no point gzipping and all it does it make the user's experience more complicated.
The archived files are already compressed so GZIP doesn't add much. In addition (and more importantly) TAR files on Linux are automatically extracted all the way with just one double click, whereas TAR.GZ files in some cases require the user to go through two levels unnecessarily. So in short, there's no point gzipping and all it does it make the user's experience more complicated.
Why can't I change the master folder?
The location of the installation is something that can't be set in JWrapper, this may sound odd but it was a conscious decision we made to do with the problems of allowing the user to pick a location and to do with expectations on modern desktop OSes and permissions. In the old days of Windows 2000 and XP you could pretty much assume the admin was running your program and that there were no restrictions based on the folder your program ran from. That is very much no longer the case and for just one example JWrapper supports multi-user installations and single-user installations, and also supports elevation for apps. The combination of those on Windows with UAC end up creating very complex and very specific restrictions about what folders you can and can't install to and you essentially end up having to follow what Microsoft says is best practice. If you don't you hit bizarre problems later down the road. Similarly OSX has well defined expectations in terms of where apps should go and how they should work. We could have allowed this as an option but the point of JWrapper is to simplify deployment both for end users and for developers and that means protecting both from having to know about corner cases like this that will trip them up unless they exhaustively test on Windows XP/Vista/7/8/MacOS/Linux etc, and to provide what people using a particular OS expect from a native application while also keeping as much as possible consistent across multiple OSes to make support easier. Not everyone will agree with this approach but it is the way modern OSes are going.
The location of the installation is something that can't be set in JWrapper, this may sound odd but it was a conscious decision we made to do with the problems of allowing the user to pick a location and to do with expectations on modern desktop OSes and permissions. In the old days of Windows 2000 and XP you could pretty much assume the admin was running your program and that there were no restrictions based on the folder your program ran from. That is very much no longer the case and for just one example JWrapper supports multi-user installations and single-user installations, and also supports elevation for apps. The combination of those on Windows with UAC end up creating very complex and very specific restrictions about what folders you can and can't install to and you essentially end up having to follow what Microsoft says is best practice. If you don't you hit bizarre problems later down the road. Similarly OSX has well defined expectations in terms of where apps should go and how they should work. We could have allowed this as an option but the point of JWrapper is to simplify deployment both for end users and for developers and that means protecting both from having to know about corner cases like this that will trip them up unless they exhaustively test on Windows XP/Vista/7/8/MacOS/Linux etc, and to provide what people using a particular OS expect from a native application while also keeping as much as possible consistent across multiple OSes to make support easier. Not everyone will agree with this approach but it is the way modern OSes are going.
Java is insecure, surely people shouldn't be using it?
Java Applets (bits that plug into a browser and can code from a remote website on your computer) have had security issues but Java is much more than just applets, its a whole language. JWrapper lets you use Java like a library, meaning its just as secure as all the other languages and libraries out there because only the bits that the app needs are used.
Java Applets (bits that plug into a browser and can code from a remote website on your computer) have had security issues but Java is much more than just applets, its a whole language. JWrapper lets you use Java like a library, meaning its just as secure as all the other languages and libraries out there because only the bits that the app needs are used.