I found some reference that says I can add #!/usr/bin/java --source 12 at the beginning of the file and run the file directly from the terminal.
I am able to run using this on my local machine, however, when I tried the same on Github action I'm getting the error error: invalid value for --source option: 12
I'm not really an expert in shell scripting or java, can someone help me understand what this --source means is it the java version, I tried setting up the same version (jdk18) on Github action but still did not work.
java (the runtime executable) can only run class files. Until, that is, java12, where a normal JDK distribution (and not the bizarro JREs that some packagers like Azul publish ^1) has a java.exe that can run java files straight up. It's simple sugar - the compiler is still involved, of course. It's just that java will execute it for you.
You don't need --source 12; just java MySourceFile.java is fine. Edit that comment at the top of your source file, it should just be #!/usr/bin/java. The thing you do need is that java on your command line PATH is a java v12 or higher, and it is not. There isn't anything your java source file can do about this, you're going to have to impose on your users to have at least java12 installed or this simply does not and can not be made to work. It looks like you're on some linux distro or other; apt or yum or snap or whatever package manager you have will tell you how to fix this: Install java17, and uninstall the rest or use java-alternatives or whatever mechanism your package manager has to set the default executable (the one /usr/bin/java links to). Read the documentation of the package supplying java17, possibly following some links to the generalized java infrastructure package, it should tell you.
Mostly this is a red herring, this just isn't how java files are distributed. It's virtually pointless because:
Java is not a language that tends to be used for quick shell script-esque things. Such things tend to be self-fulfilling prophecies: Because nobody does this, library authors aren't thinking about it when they develop their APIs and the users of their libraries won't file enhancement requests for this either. Because common libraries aren't convenient when used for quick off-the-cuff shell scripts, java isn't used for it, thus perpetuating the cycle.
Any serious java app would definitely involve packages, dependencies, and more - and such apps cannot be run like this.
Class files are as platform agnostic as source files are. There is no sane reason to distribute java-written shell-script-esque tooling as a source file instead of a jar, except for off-the-cuff editing off them, which gets you right back to point #1 and #4.
The java core APIs work on a model of lowest common denominator: If there is a major OS that cannot or doesn't work in a certain way, then java simply does not expose this at all. For example, on all posix systems (i.e. pretty much every major OS except windows), you have your usual TERM, KILL, HUP, etc signals. Java core libs don't let you interact with them (unless you dip into hidden sun.misc.* API which doesn't reliably work in the first place). This makes java extra unsuitable for quick command line scripting where you want a different model: If at least one OS can do it, the language should have a library for it, and that library should simply fast-crash if you attempt to use it on an OS that doesn't support it. One easy way around this is a third party library that adds support for OS-specific stuff, but your model of distribution (stick #!/usr/bin/java at the top and distribute a source file) cannot include dependencies.
Java as a runtime model is mostly focused on running things eventually very quickly, at the cost of starting off slowly. This is fantastic for web servers which need to run efficiently but will be running for quite some time. It's utterly unsuitable for shell scripting, though.
CONCLUSION: You don't want to stick #!/usr/bin/java at the top even if you could make it work.
[1] A JRE is a java distribution without compilers and other development tools like jstack. These cannot run java SomeSourceFile.java, obviously; they do not have a compiler. However, JREs died - there are no JREs anymore; JDK8 is the last one that shipped with an official JRE. The JRE serves as a distribution model: The end user installs a JRE, and you ship your jars to them. This model is obsolete (you are now responsible to get something that can run your class files on the deployment machine), and therefore JREs died. However, some packagers of OpenJDK builds, such as Azul, still publish them, confusing matters. Hence, 'bizarro'. Azul and co have relatively good reasons for doing it, but, you shouldn't be using these unless you really know what you are doing.
Related
I am not able to understand that after module system is introduced in our java language. Is java9 and above still platform independent or not ? I am asking this question because I have read that now every application will have its own jre inside it. So, how will this single jre run on all OS, like windows, Linux, or Mac OS.
You are conflating two different changes recently made to the Java platform:
Retiring of Java Web Start & Applet technologies
Modularization
Retiring desktop-technologies
Recently Oracle announced the phasing out of the Java Web Start technologies, in addition to the already-deprecated Applet technology. See item JDK-8184998 in Java 9 Release Notes:
Java Deployment Technologies are deprecated and will be removed in a future release
Java Applet and WebStart functionality, including the Applet API, The Java plug-in, the Java Applet Viewer, JNLP and Java Web Start including the javaws tool are all deprecated in JDK 9 and will be removed in a future release.
End-users will no longer be encouraged to install a JDK or JRE on their computer.
For more details, see the eight-page 2018-03 white paper from Oracle, Java Client Roadmap Update.
So then, how are developers of Swing or JavaFX apps to deliver their software to the end-user?
Oracle suggests packaging up your app along with a JVM & JRE for delivery as a single launch-ready applications on that appears on the client to be just another app alongside the native apps. Such “double-clickable” app-packaging has been commonly done on the Mac since the beginning of Java. But what was once an obscure art on other host environments (Linux, BSD, Windows, etc.) will now be the norm, as it is on macOS.
In yesteryear, bundling a Java runtime with your app required jumping over some licensing hurdles. The legalities have eased with arrival of the open-source OpenJDK project, and possibly with other implementations†.
You will need to prepare different releases of your app for each hosting environment. While your Java code runs independently of the host OS, the JVM is built of native code to interact with one specific kind of host. So you will need to build a Linux release with a Linux JVM, a macOS release with a macOS JVM, and so on. While that may seem like a downer, the upside is that you no longer need to worry about users having the wrong JVM version installed, or no JVM at all. Now the JVM’s presence and version are under your control. Your end-users and customers will no longer need to be aware that your app is Java-based.
Modularization
That need for app-packaging has nothing to do with the modularization of Java. As I said, it has been done for decades on the Mac.
What modularization brings to the party is that the JVM/JRE you bundle into your delivered app can be customized to contain only the Java Modules actually utilized by your particular app. This results in a smaller size, so your finished app is smaller, downloads are faster, less storage is used, and your app may load faster.
The open-source jlink “Java Linker” tool helps with the packaging work, so you can assemble and optimize a set of modules and their dependencies (only the ones actually called by your app) into a custom run-time image. This modular run-time image format is defined in JEP 220.
† On a related note, you may want to read the white paper Java Is Still Free to understand how and where to obtain a Java implementation for your app, and what support may or may not be offered in either free-of-cost or paid releases.
By the way, you may find helpful this Answer on a related Question, with a flowchart of choosing various sources of a Java implementation.
Is java9 and above still platform independent or not ?
Yes. It's as platform independent as it ever was. The module system has nothing to do with platform independence.
now every application will have its own jre inside it.
It doesn't have to, but it's more and more recommended as time goes on since fewer people have Java installed separately on their systems. This used to be a given, but that number has been declining for the last decade or so, and now (outside of Java developers) pretty much no-one has a standalone JRE installed.
how will this single jre run on all OS
It won't. You will bundle a separate JRE for each platform you want to distribute for. But JRE's for all platforms are still freely available, and the same Java code will still run on a JRE for any platform.
The module system doesn't influence the OS independency of java in general. Java applications that make use of the module system need to be run in a JRE. This can be either an OS specific pre-installed JRE as usual or a tailored runtime image (application embedded JRE) created with JLink.
The module systems main purpose is to provide you a managed way to split your application into different logical modules. E.g. into different .jar files that can be loaded at runtime - no matter on which operating system.
In summary, you have the following options:
Make sure that your client has the right JRE pre-installed. This could be dangerous, because (normally) you are not in control of his updating behavior.
Ship your application together with an official JRE.
Tailor your own, application and OS specific runtime image using JLink. Ship it bundled with your application.
But, suppose I do not know what OS my client would be running so how
the server will decide what image he should give to him. i.e., a Mac
Image, a Linux Image or a Windows exe.
You have to know the target OS and deliver the right runtime image.
While Java 9 makes it easier to ship a JRE which is more compact and specific to the needs of an individual application, you are not required to do so. If you were already planning to ship a JRE with your application it can be smaller with Java 9 than earlier versions.
It doesn't mean you have to ship a JRE, an application which wasn't shipped with a JRE is unlikely to start shipping with one now, and in fact Java 11 only ships as a JDK.
From this link on Java 9 features;
JLink allows you to create custom runtime images that only consist of your application modules and those JRE modules that your application requires. The result is likely a smaller runtime image, which uses fewer resources than a default JRE.
I am attempting to port an application that was written with a combination of c++ for the back end, and java for the front end. This application relies on the library opencv 2.4.13, which is outdated, as well as multiple other libraries. The concern i have is that i do not want the end user to need to install these dependant programs, as they have been proving challenging to install on any but a select few linux distributions. I believe the term i am looking for is statically linking, but i'm a bit unfamiliar with c++ compilation at the moment, so i am unsure the steps i need to take to make these files portable. The java application requires these files to be libraries, and while i have managed to get them to compile on one machine, the problem seems to be getting them to run on a different one after compilation.
Don't bother - this might also give you licensing problems, depending on what libraries you need.
Instead, just figure out what platforms your application is supposed to run on and package the libraries for each platform with your jar - or download them at startup, or provide them as a separate package. The exact mechanics you choose depend on your use case, the point is you don't need to rely on system wide installs.
We have a situation where our application embeds a JRE. The application, by mistake, ships with a mashup (7.x version of java.exe and 8.x version of the rest of JRE).
I can confirm that the process running the v. 1.7 java.exe uses the v. 1.8 java runtime using Process Explorer. I'm surprised that the runtime or the binary didn't detect the anomaly and abandon JVM creation!
What are the implications of the same ? Security issues ? Stability issues ? I haven't gone through the source code for java.exe. From my preliminary investigations of java.exe binary, I can see that it is more than a stub. It calls out to 100 different KERNEL32.DLL APIs apart from USER32.dll, ADVAPI32.dll, COMCTL32.dll.
Sure, we can(and we will) fix the mistake. But are there implications for the several current production systems that use the above anomaly ? if yes, what are they ?
What are the implications of the same ? Security issues ? Stability
issues ?
All of those.
The JVM binary (java.exe in your case), the shared objects/DLLs that come with it, and the JAR files that implement the Java side of things all come in a combined package that is not designed nor meant to be run as anything but a combined package.
Specific lists of compatibility issues between Java 7 and Java 8 are known external issues between coherent versions of the entire JVM package.
You've added internal incompatibilities of an incoherent Java installation to those known external incompatibilities. There's no way to get a list of those. It's almost certain that no one even tries to keep track of such things.
You have no idea what should work, what will work, nor how long it will work even if it does appear to work.
java.exe is a simple launcher. It does not contain JVM or Class Library code. Its primary function is just to locate a JRE and to load jvm.dll with the arguments passed in the command line.
You can start a JVM using the Invocation API even without java.exe.
java.c log tells there are not really much changes in the launcher between JDK 7 and JDK 8. E.g. there is a launcher support for JavaFX applications and a few fixes for better argument validation. That's it. So if your application starts fine with JDK 7 launcher, there is apparently nothing to worry about.
I'm trying to migrate from Windows to Linux as a Java development platform, and while the transition has generally been pretty painless, there are a few points of uncertainty that I'd like some feedback on. I'm running openSUSE 11.4, but I'm open to hear what works on other distros.
Where do you install your JDK from? This one is surprisingly not as cut and dry as most people make it out to be. OpenJDk 6 is available in the openSUSE repositories, and was very easy to install. However it's currently update 21, and right now the Oracle release is at update 24. I'm used to a little alert in Windows notifying me that my Java needs updating but that doesn't appear to be the norm in Linux. Do Java developers forgo the JDK in their package manager and install the binary directly? Or is there another way?
Where do you install Eclipse? There seems to be a general agreement online that Eclipse is best installed by simply downloading the binary and extracting it somewhere, but where's the usual place I would extract a program like Eclipse or Ant? I've seen votes for /usr/local and /opt online, but no definitive answer.
Where do you put your Jetty/Tomcat? Similar to the eclipse question, where do most Linux Java developers put their Jetty/Tomcat/other container.
What are some of the differences between the way you setup development versus production At the very least it seems I don't want to run my servlet container as root, that makes sense to me. But what other practices should I watch out for? Is there anything else that could make my development environment easier, but perhaps less secure?
I found this question was similar but ultimately too high level and didn't get into details of how actual developers are setting up their environment. If there's other resources you feel answer these questions, please share them here.
Thanks for your time.
Q> Where do you install your JDK from?
A> I never bother with other JDKs coming from outside Sun/Oracle mainly because our product is only certified to work with Sun/Oracle JRE. On my desktop, I run Kubuntu, but I never use apt-get for this but always download them manually. Reasons:
distro maintainers rarely rush to upgrade packages, as their primary concern is to make dependant apps (such as OpenOffice) work. If JDK changes from 1.6.0_20 to 1.6.0_21, they simply don't care. I might do because a newer patch might have an important bugfix or I simply want to try if my app still passes all the unit tests.
it might be a nightmare to retain old JDK versions. We still support older versions of our product and if I upgrade to a newer Kubuntu, I don't have guarantees that some ancient JDK will still be available as a package.
I am not sure some distros even support multiple existence of JDKs on the same machine.
My preference is to keep all JDKs/JREs in /opt and make a symlink to the newest one or the one I need most. I simply don't see why installing JDK manually is a problem.
I also set the PATH to the newest JDK/JRE.
Same thing (and similar arguments) apply to Ant and Maven.
Q> Where do you install Eclipse?
A> I use IntelliJ but the same applies. I store IDE in my home folder. This allows me to have different versions of it, update them without needing sudo, etc. I could as well install it in /opt but I guess I got this habit when I was downloading and testing newest IntelliJ IDEA EAP every week so I can quickly delete the older versions and do not pollute /opt. Finally, other programs might require Ant/Maven/JDK but it's only me who uses IntelliJ hence the different approach.
Q> Where do you put your Jetty/Tomcat?
A> I have a separate folder tomcats under /home where I have ~10 different Tomcat instances. Each of Tomcats is used for a different version of my app (we bundle Tomcat with our app). This is necessary because one deployment of our app can have different Tomcat settings (or even version) than another.
Q> What are some of the differences between the way you setup development versus production
A> It very much depends on your app. For example, we need some partitions to have lower access latencies but having less space (e.g. gigabytes for Lucene indexes) VS others which can have higher latencies but require more space (e.g. terabytes for content repositories). We, however, design our app so that all these different aspects can reside on different partitions which are configurable. Some partitions need to have special limitations (e.g. file upload) so this doesn't overflow other partitions. There is no simple one-for-all answer to this question, but obviously most of these concerns don't matter that much for a development environment.
Where do you install your JDK from?
I use Arch Linux myself, and we have the oracle jdk/jre in the repository itself. Hence, use your distro-repository if it has the oracle jdk/jre else get it from oracle itself.
Where do you install Eclipse?
Again, the same answer as above applies to this as well. If however, there is any issue with the distro provided version, I always put my custom installs in /opt/ - /opt/java , /opt/eclipse, /opt/netbeans - etc. I dont install stuff in my home folder (except in circumstances where I don't have permission anywhere else - rare), since that would mean that other users would need access to my home folder to run the stuff. I don't want production (or development for that matter) stuff having direct access to my home.
Where do you put your Jetty/Tomcat?
The same answer as above applies here as well. Only in circumstances, where I have installed more than one version, I create an /opt/experimental/ and install there so that I know which one my production is running and which one I can remove when no longer required.
What are some of the differences
between the way you setup development
versus production?
If possible, I always setup different machines for production and development work. Different computers, but exactly identical setup. The only systems that can push code to the production system are those in the development group. Where this segregation is not possible, I prefer to have different install for the servers, so that while I am tweaking the development configuration, my main servers don't crash or something. Also development setup will generally include a clean_up script that makes it ready for production (dropping unnecessary priviledges for db accounts, cleaning up, etc.
Have whatever, setup you will, just make sure you have different database setup for development and production purposes.
The Sun version of Java for openSUSE is on the nonOSS disk (go here and scroll down for an ISO), which is an additional disk image, not part of the main install disk ISO (or you can pull the RPMs from here).
As far as eclipse is concerned, if I'm installing at the system level, I tend to drop it in /opt. You might want to read this article on how best to handle plugins.
(Don't let them steer you off openSUSE, it is the best distro for KDE IMO.)
Working with linux is a lot less hand holding then the windows environment that you're use too. If I were you I would switch distros to either RedHat or Ubuntu, I use to use SUSE and never looked back since I switched.
You can put your JDK/Eclipse/Tomcat binaries in a couple of different places. If you are the only one going to be using them I suggest you put them in your home directory somewhere. For your Eclipse/Tomcat stuff you can but them in a local bin and then add that local bin to your PATH in your .bashrc. You can also set the location of your JDK to a JAVA_HOME env variable in your bash. If you need any more specific help with setup let me know.
1) We have had several problems with OpenJDK (bugs, etc) so we always use the sun jdk.
2/3) A good rule to live by when living in Linux, is always install your custom software under your home folder. Linux needs to be reinstalled from time to time, but everything in your home folder is in a separate disk-partition, so it lives on. I always installs/unzips custom software such as eclipse to /home/myuser/opt, so my eclipse lives at ~/opt/eclipse. I also symlinks the eclipse-binary to my /home/myuser/bin folder for easy access. When I upgrade or change any software, I just rewire the symlink.
4) Production and development environments should be as close as possible to identical. This elimenate loads of bugs caused by different configurations etc.
I create a /usr/local/java directory and unpack the JDK(s), Eclipse, Maven, Ant, Groovy and Grails in there, then create symlinks to /usr/local/bin.
I would like to know if there is any way that I could build a very simple GUI app (it doesn't even have to look good) that will run on a fresh install of Windows Vista and OS X with no other installations needed by the user. I would perfer not to use Java (just out of personal programming preference). I will use it though, if it is the only way. Specically, I am wondering if I can write a swing app with Scala or Groovy and run in on windows without them having to install anything. Sorry if this is a silly question, I am a Obj-C developer by trade.
You can pack the Scala jars into your own, which should work as long as Java is installed (which it usually is on a 3rd party vendor install of Vista or OS X). If you use Java web start, no installations are needed beyond Java itself. Plus, if you're going to install your own code, why not just copy along the Scala jars also?
If you really mean a fresh install--nothing but what the OS provides--then no, I don't think so.
Edit: You do always have javascript on the browser(s). I assume this won't cut it for what you want?
If you really, really don't want to install anything (or carry anything in your app), then write the application as a web app (possibly a javascript app). Then any user can run that UI from any machine with a decent browser. But then, this will require that you host the app somewhere.
If that is not an option, you can develop your app to as a single html/xhtml file containing a self-contained, self-modifiable javascript application (like TiddlyWiki which I use a lot). Then the user user can download on it on his machine, point his browser to it and voila.
If you combine javascript with HTML5 (and assuming the user has a HTML5 compliant browser like safari), your application can use localStorage to keep its state in the user's machine (thus no longer needing to be self-modifiable to save state as TiddlyWiki does.)
But this would break your rule of not downloading anything on the user's host machine. It is a chicken-and-egg problem that has no solution since each OS implements its own set of application libraries. For multi-platform support, you must use a layer that abstracts out differences between operating systems, be it a vm (like JVM, Ruby or Mono) or a set of libraries (Qt, Gnome).
As far as i know you won't be able to accomplish that with no other installations needed by the user. If you violate this restriction, mono (with gtk#) is a good choice.
Scala and Groovy will have the same deployment issues as Java; all of these require a JVM to be installed. You generally have to first install the JVM (which is not included with Windows) and then install your program. Java is included in OS X, however.
It is possible to use Ruby or Python and one of the cross platform libraries (like wxWidgets) and compile these to an executable file that includes the entire set of runtime libraries (e.g. all of ruby and python).
REAL Studio (formally REALbasic) certainly meets this requirement. It creates native applications that have no external dependencies for OS X and Windows (plus Linux).
In theory you could write a .net application using Mono that it should run without issues on any other one with the .net runtime environment installed.
But I'm not sure if it will work on practice.
I've had some success with XulRunner
There's also a couple of recommendations from these questions I asked
Building Cross Platform app - recommendation
Building XUL app a-la SongBird
XULRunner is pretty cool once you get into it, but it's a tad confusing at first (I thought).. the folks on the mozilla google groups are really nice and helpful though!