We Keep Coding

is java 9 and above still platform independent or not after this module system has been introduced?

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.

Java mobile for datalogic elf

I've been given the opportunity to develop an application to collect data including scanning and generating bar codes on a Datalogic ELF. The os is windows mobile 6.5, and the SDK supports java, however there seems to be very little in the way of examples or help etc. I would be grateful for any advice, links, tutorials for Java development.

Datalogic does not offer there SDK for JAVA only. Did you download and install there SDK from http://www.datalogic.com/eng/support-services/automatic-data-capture/downloads/software-utilities-sw-2.html?search_cat=27&search_prod=144.
The site states SDK for C++/.Net/JAVA and I assume it is coming with usage examples.
Further on you need a JVM runtime installed on the device. Does it really come with a JVM pre-installed? Normally you have to buy and install CrEme or J9 JVM for handheld devices running WEH6.5.
I would go with .NET (WEH65 comes with CF 3.5) or C++ and not install an additional Runtime, except for you are really in the need to do it in JAVA. Mostly the JAVA support of handheld SDKs is very limitted.

Java or Objective-C for MacOSX (back to 10.3 & PPC)

We are starting some new app development but because of special business requirements, need to support back to Mac OS X 10.3 as well as PPC/Intel CPUs.
The latest Xcode 4 isn't an option, from what I can tell it only goes back to 10.5 and doesn't support PPC at all. Is Xcode 3 an option? Would it be easier to just use Java?
P.S. From anyone experienced in either, can you please comment on some of the pros and cons you've bumped into?
EDIT
As requested, here's a brief overview of the app:
The app needs to talk to a server which will expose JSON web services. The app itself needs to be built in a way that will allow plugins (not 3rd party, but in-house with the ability to customize which features the customer owns). Each plugin will gather specific information about the host OS - such as running apps, users, CPU usage, etc.

If you can find a way to make Objective-C work with your requirements, it is worth it in my opinion.
I myself am a former Java developer who has moved into the creation of native Mac OS and iOS apps. I tried using Java for some of my early Mac OS projects and always found the support to be lacking. It can be done, but it was always more difficult than it should've been and never worked as well as a native app.
Here is a link to another SO post that describes some workarounds for getting older SDK versions working in Xcode 4. I can't vouch for how well they work with current versions of Xcode, but it's worth trying.

In view of your requirements, especially the need to do some system evaluation, I would strongly recommend to use Objective-C and the Apple development environment. You will have a lot of difficulties using Java to retrieve the neccessary information about the host OS, that you want to use in your application.
You could try to run Xcode with older SDK versions, but I have virtually no experience on OSX to give you solid advice on how to do this.
EDIT: My Xcode 4 gives me an option to select a "Deployment Target", where I can go back to supporting 10.1, but I have no idea, if this is the right thing...

Well,
Apple isn't a Java friendly company. You don't have all the bindings you may need on their JVM.
So I strongelly recommend (given that your project will be Mac OS X only) Objective C instead of Java

I program in Java but on Mac OS X, Objective-C is better than Java because it is faster and developed by Apple itself. Moreover, if you develop a program in Objective-C, you can sell it on the Mac App Store while if you develop it with Java you can't.
So go with Objective-C.

The Java Media Framework isn't cross platform?

I'm using JMF in my Java GUI and before downloading the packages from Oracle, it asks you which version you want:
Linux
Solaris SPARC
Windows
Does this mean my Java (cross-platform by nature) application WON'T be cross platform any more?

There is a 100% pure Java implementation, but that does not support all codecs and doesn't run as efficiently as the version using native code. So, effectively, the JMF is not fully cross-platform.
The developers justify this by considering the JMF an extension to the Java platform itself rather than just a library: just like you have to download a specific JVM for your platform, but can reuse your source and object code unchanged, you need a platform-dependent JMF implementation, but the JMF clients can be reused unchanged.

JMF isn't a pure Java API, so it'll only work where it's officially ported.

Java ME 3.0 SDK on Linux?

Is it possible to develop java me applications on linux? It appears that there is no linux version of the sdk. Otherwise what would you suggest as a good language to develop mobile applications?

Use the 2.5.2 SDK. It works pretty well under Linux, actually.
I'd also second the recommendation for Android, where Linux is definitely not a second-class citizen.

I was able to install (an earlier version of) the SDK on a Windows machine and then copy the relevant libraries to my Linux development environment. I wish sun would provide the all the JDKs in zip/tar format. I hate having to INSTALL software just to get .jar files out of an archive. I should note that the SDK includes a mobile device emulator that doesn't work under Linux but you just need the .jars to compile code.

The Sun Java Wireless Toolkit 2.5.2 runs under Unbuntu 6.x, more details here:
http://java.sun.com/products/sjwtoolkit/download.html
We use WinXP for J2ME and Ubuntu for Android. Though that's more down to the preference of the coders than any limitiations.

Otherwise what would you suggest as a
good language to develop mobile
applications?
Well, you can still use the Java lang.
But maybe develop some Android apps.

virtual box can be a great help here, for OSX and Linux users, unfortunately most of the emulators and sdks, in particular the preverifiers are geared for Windows first, a prime example being Blackberry
Our flow tends to be to develop the bulk of the application in the std wtk environment, then do the final porting and tweaking under a virtualised Windows environment