I'm trying to install JDK & Java IDE, I have dual boot (Windows 10 + Ubuntu 18.04), can I make use of the same binary packages in both of my systems?
It depends what the "binary package" consists of.
If it consists of just .class files and other machine independent resources, then yes the same binary can be used on multiple operating systems and even different hardware architectures.
If it also includes native libraries, and the like, then those libraries will be operating system and hardware architecture specific.
If your application "package" is a self-contained JAR file, then it is possible to include native libraries compiled for multiple platforms in the JAR; see How to bundle a native library and a JNI library inside a JAR?
If the package is actually installable package as understood by the host system's package manager (e.g. a Linux RPM, DEB) or a native installer executable, then these are also platform specific.
It also depends on how you handle platform specific things in the application; e.g. running different external commands on different platforms, talking to the Windows Registry, LDAP vs Active Directory, different file system properties and behaviors, etc.
No you can't easily have a single package. I don't know about NetBeans but Eclipse and Java are specific to the operating system because they use many APIs which are different in each OS.
Related
As can be seen in the below screenshot, a Netbeans C/C++ project allows the addition of resource files. When I Google things along the lines of "Netbeans C/C++ 'Resource Files," nothing useful comes up. As such, I ask here: what are they and how can I use them? Is it just a logical folder that the application can use at runtime with regular fstreams, or does it allow the embedding of files in the final executable similar to Java's getClass().getResourceAsStream() mechanism?
NOTE: I am using g++ 5.4.0 on Ubuntu 16.04 LTS x64 if these are platform independent in any way (in which case I would like to know how to use them on Windows and other versions of Linux as well).
I followed the "JavaFX is going to replace Swing" advice mentioned in several places (SO, Wikipedia, Oracle) but that seems to be a white lie. When I run a JavaFX app with IBMs V9 (build 2.8, JRE 1.8.0), I get:
java.lang.ClassNotFoundException: javafx.application.Application
I couldn't find any resource which explains whether JavaFX is a cross-VM technology or whether this is just another vendor-lock-in "feature".
Where is JavaFX available? If it's not available in some VM, can I install it or bundle it with my application?
JavaFX is not available for every Java VM. For instance, Oracle Solaris Java distributions do not include JavaFX support.
JavaFX is available for many Java VMs. There are JavaFX runtimes available for (at least) the following platforms:
OS X, Windows, Linux, iOS, Android and various embedded architectures.
JavaFX download and source locations:
Binaries for some JavaFX runtimes (such as OS X, Windows and Linux) are provided by Oracle based upon Oracle JDK sources.
Binaries for some other runtimes (Android, iOS and embedded architectures) are provided by Gluon based upon Open JDK sources.
Binaries for Debian based Linux systems are in the Debian Package Tracker, based upon OpenJDK sources.
Open source code is available to build JavaFX for use with other platforms and Java VMs as part of the OpenJDK project.
For further information, see related questions and resources:
OpenJFX wiki site for open source JavaFX information.
What's the location of the JavaFX runtime JAR file, jfxrt.jar, on Linux?
JavaFXPorts: JavaFX to mobile and embedded hardware, including iPhone, iPad, Android devices, and the Raspberry Pi.
Java FX 2 on IBM jdk?
Certified configurations for JavaFX when running with Oracle Java 8 (Windows, OS X, Linux).
JavaFXPorts enables execution of JavaFX on the Android runtime natively and, currently via RoboVM, on the iOS runtime, for more info see: JavaFXPorts, how it works.
can I install it or bundle it with my application?
Yes.
Oracle JavaFX and OpenJFX distributions ship with tools for bundling JavaFX (and an appropriate Java runtime) with your application.
Gluon provides tools for packaging JavaFX applications for iOS and Android.
The JavaFX maven plugin supports bundling via a Maven based toolchain.
The JavaFX gradle plugin supports bundling via a Gradle based toolchain.
In terms of licensing for such distributions, I encourage you to do your own research.
Oracle Binary Code License (if you are bundling Oracle JRE).
OpenJDK Legal Documents (if you are basing the bundled components off of OpenJDK).
It became integrated partially in Java 7 and more tightly in Java 8 so it should be standard in newer VM's and is slowly opening up. However, I wouldn't consider migrating from Swing to FX as a move up as much as a lateral move as explained here.
IBM provides their own version of Java, and as far as I have ever seen, they do not seem to provide JavaFX in their runtimes for whatever reason. I have only seen JavaFX provided by the canonical Oracle releases.
I'm developing an Eclipse RCP application. The application should run on Windows and Linux.
There are several plugins in this application that contain native artifacts. To contain these artifacts in a binary build (jar), one should specify them in build.properties file.
Currently I include both Linux and Windows native artifacts in build.properties and then in runtime I choose which one to load. However, I don't like this approach as it causes unnecessary files to present in both Linux and Windows builds.
Is there a way to specify target platform in build.properties? So that for Linux build it would include Linux artifacts and for Windows build it would include Windows artifacts?
Alternatively, is there a way to maintain two copies of build.properties - one for Linux build and second for Windows build?
The usual way to do this is to have separate plugins (or plugin fragments) for each platform with a platform filter which restricts when the plugin is available:
For example, in the MANIFEST.MF
Eclipse-PlatformFilter: (& (osgi.ws=cocoa) (osgi.os=macosx) (osgi.arch=x86_64) )
restricts the plugin to only Mac OS X 64 bit, Cocoa.
This is what SWT does. There is a base org.eclipse.swt plugin which doesn't contain any code and then multiple plugin fragments extending that plugin (such as org.eclipse.swt.cocoa.macosx.x86_64). Each fragment contains the SWT code for a platform, all implementing the same classes.
Eclipse only loads the plugin for the current platform so you don't have to do any work choosing what to use.
I want to distribute an eclipse platform with pre-installed plugins to different users with different operation systems.
On the side http://www.eclipse.org/downloads/ I have to choose the target platform for eclipse, so I downloaded it for Linux 32 and 64 bit and for windows 32 and 64 bit.
I want to distribute an eclipse with some pre-installed and also self written plugins to other people. Can I simply install the plugins in one eclipse installation and then copy the files from the /plugins folder to every /plugins folder of the other eclipse versions for linux and windows or are the plugins (also the pre-existing default plugins) in the /plugin folder also platform dependend and must be installed seperatly on the target platform?
Some are, some aren't. Eclipse supports the inclusion of native code in OSGi bundles, and then unpacks it and accesses it via JNI. The native code can be in separate 'fragments', and Eclipse won't necessarily download all the fragments for other architectures.
Well, here's the way I see it: Eclipse is written in Java, which is platform-independent. Eclipse's plugins are, therefor, written in Java, and must be platform-independent. Also, I've yet to encounter a plugin that wasn't platform-independent. So yes, to the best of my knowledge.
I need to install several plugins to an eclipse that is running on a remote 64bit Linux machine.
I tried copying the neccesary plugins to the plugins and feature folder on the remote machine but it did not seem to work.
The approach I wanted to try out now was setting up a new Eclipse installation with all plugins and replacing the whole eclipse folder.
But as I am doing this I realized that I have to use a 32 bit Linux and Eclipse. Is it possible to install 32bit Eclipse and just move the plugins and features to the remote machine?
Do I need to consider other things?
Can you recommend any other approach that would help me?
UPDATE:
The problem is that I cannot just start eclipse on the remote machine. I can access it via ssh but not run eclipse and install plugins via the wizards.
I also have no 64bit linux to prepare a complete eclipse that I can simply copy.
So what I meant is that I have to prepare either an eclipse installation or maybe just plugin folder and move that from my 32bit architecture to the 64bit one.
I can download the current eclipse folder but I cannot run it. When I try to start it with ubuntu nothing happens. I believe it is because its a 64bit version and I got 32 bit architecture.
Don't do this. Not only are there are a number of plugins with native-compiled fragments (different for 32-bit vs 64-bit), but in recent versions, Eclipse will not even register features and plugins that are simply dropped in. You should install plugins explicitly unless you are moving the entire installation between machines with compatible architectures.
You can't run a 64bit binary on a 32bit system without some kind of virtualization software that does a complete CPU emulation. VMWare, VirtualPC, etc... don't do this. They virtualize the system, but not the CPU.
The other way around: a 32bit binary on a 64bit cpu, is generally possible, if the OS (and processor) supports such things.
I think this is feasible.
The architecture should not be the problem. Unless the plugins contain DLLs or .so libraries invoked through JNI but there are very few examples (swt is one example but there are very few of them).
As a matter of fact, the reason why you have OS/arch/GUI specific versions of eclipse is not the java code but the native launcher (eclipse.exe on windows and SWT), all the rest can go bck and forth from one machine to the other, regardless of the arch, the os or the wondows manager.
However, dropping jars in the plugin directory of eclipse is not the recommended way of installing plugins any more (since 3.3 ?). It might work but there is no guarantee.
To install the missing plugins you should download them from eclipse itself (help => install new software...). If you tell us the specific plugins you have problem with, we might be able to help you more precisely.
The best way to go forward is to list all the plugins on the source machine (either from eclipse (help => about) and look at names having specific hints at arch/os/gui. All these cannot be copied over. All the rest should be safe.
As I said, beware of swt. Subclipse has a JNI dependent configuration if you decide to use JavaHL. And there are also "false" plugins such as xmlSpy etc who are noting more than JNI adapters but these are not mainstream.