We Keep Coding

What is the difference betweeen Zulu Server JDK and Zulu Client JDK for Windows?

In Zulu JDK download page, there is a Product column for Windows JDK. There are Server and Client for choice. What is the difference of these two?

I will admit this is a bit confusing and will get our web people (I work for Azul) to look at this.
The client and server part refers to the versions of windows that are supported, the downloads are two different formats, either a zip archive or an MSI installer. Although it looks like the client is associated with the MSI, that's just an artefact of the way the table layout was used. Either the ZIP or MSI files can be used on either the desktop or server OSs that are supported.

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.

is there a JRE reduced version for Tomcat only?

I have a web application that uses embedded Tomcat, which I'll distribute as a desktop app. Since I don't want users to deal with the installation of JRE, I decided to bundle JRE in my installation package, however, I was wondering if there's a reduced version of JRE in order of having a smaller installation file size. For example, I removed all the CORBA related files from JRE and everything seems to be working fine, so I guess some other files could be removed without affecting Tomcat's functionality, but I really don't know which other files should I remove.
If anyone has done this before, I'd appreciate your comments.

AFAIK, there aren't any official cut-down Oracle JRE releases. Certainly not free ones, though I imagine Oracle would create one for a customer who was willing to pay (enough).
If you created and distributed a cut-down JRE based on the Oracle JRE, it would be a violation of the Java Binary license ... which expressly forbids such things. You would need to get permission from Oracle to do this. The same applies to other suppliers, so the chances of you finding a free cut-down JRE based on OpenJDK are "vanishingly small".
I'm don't know for sure the legal constraints on building a cut-down JRE starting from the OpenJDK open-source codebase. I suspect that it is legal from the copyright perspective, but that you need to understand of patent and trademark issues. (For example, a cut-down JRE would not pass Java Standard Edition TCK testing, so you would not be permitted to use trademarked terms like Java and JRE to describe it.)
You should to talk to a lawyer if you intended to build and distribute cut-down JREs to anyone else.
I understand that Azul distributes cut-down JREs as a commercial (non-free) offering. Google found this for me:
The short answer for why we do not remove contents of Zulu JDK is for compliance with Java Standard Edition TCK testing. Changing the contents of tested build after the fact is often believed to be an invalidation of TCK coverage, and we cannot ship without that copyright/patent/trademark umbrella. Secondly, Azul offers cut down JREs and Compact Profile binary builds as a commercial (non-free) offering. We still need some way to monetize Zulu (else the business is not self sustaining) so charging fees and offering only private access to the set of lean & mean production runtimes is core to our business model.

Opensource packaging software for Mysql Server with Java Desktop Application

I have a Java desktop application which uses mysql database . Is there any Open source software for packaging or executable wrapper of Mysql server and Java desktop application into one single Exe/Debian package where i need not separately install Mysql server separately . Its like one click installer which installs everything and the application is ready to use. Thanks

The problem here is that MySQL is a standalone server, and cannot be easily embedded. You should use an embeddable or serverless database, such as :
SQLite (see the SQLite library for Java, containing all the server and the API in one jar)
Apache Derby (see the documentation for embedded use)
HyperSQL

Just so it's said here, if you are not a Open Source project, what you are trying to do is not only a problem technically but also could be one legally. From the mySQL license agreement:
For OEMs, ISVs, VARs and Other
Distributors of Commercial
Applications:
OEMs, ISVs, VARs and other
distributors that combine and
distribute commercially licensed
software with MySQL software and do
not wish to distribute the source code
for the commercially licensed software
under version 2 of the GNU General
Public License (the "GPL") must enter
into a commercial license agreement
with Sun.

You'll probably have to script something together and use the NSIS installer builder (which is free) for Windows.
For Debian it'll be just some scripts which have to be packaged together in a .deb.
But I really don't think there is a out of the box, or off the shelf solution for this.
Good luck :)

Hosting Java Web Start application for inclusion into Linux distros

I authored a Java freeware (closed source) product that I deploy on a web host and distribute via JNLP, inclusive Linux clients.
I plan to suggest this product for inclusion into several Linux distro, if possible "as is" (JNLP-based).
Can I already contact distros, or I need to reconfigure something (deploy on another host, convert JNLP to something, etc.)? What is your experience?

I would say that a freeware JNLP application is pretty much the opposite of what Linux distributions would tend to include.
Firstly, JNLP will not work with the native package management solution. If you wanted to get an application included in a distribution it would need to be package in the native format and updated in the standard way.
Secondly, most distributions will favour open source packages and many will not include non open source packages in their default repositories. Some distributions may have specical non-free repositories. Up until OpenJDK you may not even Java itself would be in these repositories.
In my opinion you would be better trying to build a user base on your own as you then have complete control over releases etc.

Generally Linux distros aren't very interested in things they can't integrate into their release schedules. Since JNLP allows you to deploy a new version at any time, they can't do a version freeze before release. This will exclude you from most distros - Debian even removed Adobe's flash plugin for this very reason, and if they'll remove Flash, don't expect them to make exceptions for a less well known application.
If you're willing to distribute it as just a plain .jar, you might be able to get it in - for debian, you'll want to read the Debian New Maintainer's Guide and Debian Policy on how to package things, submit an ITP (intent to package), upload a package, then seek sponsorship on the debian-mentors mailing list. More info can be found at the Debian mentors FAQ. Packages submitted to Debian will also make their way into Ubuntu in due course.
Other distributions will have different policies, of course; if in doubt, check their faqs, or ask on an appropriate mailing list for the distro in question.

Figure out a way to package it properly on each of the platforms you want to include your software on, and prepare for rigid software management (freezing, multiple versions etc if you want the code included in the standard installation.
Otherwise you may be able to create a simple package just containing the link to the JNLP page which may be included in the non-core parts. It is worth a try.
What applcation are we talking about?

Java programs tend to be very difficult to package and maintain. Therefore guidelines vary from distro to distro. So you should have a look at the specific guidelines for some popular distros first.
In addition to that: Everything that updates itself independently from the package manager can be real pain for the user and maintainer of the package so you should consider a different distribution model for inclusion in linux distros.