Why is download for JRE available when it does not have significance without compiler

[Monica Shiralkar]

JDK is compiler (Java) along with runtime JRE.
I have seen that downloads are available for JRE alone too. What I understand is it has significance only when alone with the compiler, that is when JDK is downloaded which has compiler as well as runtime. Why would someone download only the runtime JRE ? Thanks

[Liutauras Vilda]

Monica Shiralkar wrote:Why would someone download only the runtime JRE ?

Imagine someone doesn't want to create Java programs, just run them that are created by somebody else (i.e. compiled classes and packaged into a JAR file).

JRE (Java Runtime Environment) provides the platform that allows to execute Java applications. It Java terminology, that is Java Virtual Machine (JVM) along with its core needs to run programs.

[Tim Holloway]

The JDKs included a copy of the JRE embedded within them. Thus a JRE only would be less to download.

It no longer matters, however, since I'm fairly certain that all of the more recent Java versions are JDK-only with no JRE-only option.

You don't expect to have to download a C compiler to run a compiled C program. Why would it be unreasonable to have to have a Java compiler (JDK) to run a compiled Java program?

In fact, JDKs might have been a lot less popular except that one of the primary uses of Java has been to run JEE webapps and the common way to execute JSPs requires that the server converts the JSP code into a Java Servlet (Tomcat uses JaSPer) and then uses javac to compile the servlet. If JSPs had had a direct-to-bytecode compiler, a JDK wouldn't be needed to run Tomcat or its webapps.

[Paul Clapham]

Back in the days when we had applets, opening a web page which included an applet required a JRE to be downloaded to your computer, so that the applet could run there. Downloading a compiler as well as the JRE would have been pointless and wasteful -- in those days, even having to download a JRE (which was about 4 MB if I recall right) was challenging for people with a dial-up connection.

This made applets unpopular, so when their uncontrollable security problems became clear it was easier for the Java maintainers to deprecate them.

[Monica Shiralkar]

Thanks all.

[Monica Shiralkar]

Paul Clapham wrote:opening a web page which included an applet required a JRE to be downloaded to your computer, so that the applet could run there. .

So It was required to have JRE installed on your system just to be able to open a web page having applet and it is not required in case of a web page say which uses Spring etc ?

[Stephan van Hulst]

Correct.

Applets run on the client machine, therefore a JVM needs to be installed on the client machine.

Servlets run on the server. The client doesn't need a JVM.

[Tim Holloway]

Correct. An applet ran on the client's machine, so a JRE was needed on the client's machine.

A web page from a JEE server requires a JRE installed on the appserver machine (or more usually a JDK) to run the webapp server and its webapps, but does not require a JRE on the client  because the webapp returns HTML (plus maybe some CSS, JavaScript, and so forth).

[Monica Shiralkar]

Thanks

[Monica Shiralkar]

Tim Holloway wrote:
A web page from a JEE server requires a JRE installed on the appserver machine (or more usually a JDK) to run the webapp server.

But how is having a JRE alone sufficient on the machine where the web server is running? Isn't the compiler also surely required ?

[Tim Holloway]

Monica Shiralkar wrote:

Tim Holloway wrote:
A web page from a JEE server requires a JRE installed on the appserver machine (or more usually a JDK) to run the webapp server.

But how is having a JRE alone sufficient on the machine where the web server is running? Isn't the compiler also surely required ?

Yes. For JEE webapp servers that compile JSP pages to Java code, a compiler (JDK) is required to compile the Java code.

[Stephan van Hulst]

Monica Shiralkar wrote:But how is having a JRE alone sufficient on the machine where the web server is running? Isn't the compiler also surely required ?

Not in every case. If the application consists only of file that were already pre-compiled on a development machine, then the machine that hosts the application doesn't need to compile anything.

Tim Holloway wrote:For JEE webapp servers that compile JSP pages to Java code, a compiler (JDK) is required to compile the Java code.

Surely, these days no JEE server bundles an entire JDK? I know that Tomcat comes with its own JSP compiler (Jasper), and I would be surprised if any of the enterprise application servers don't do something similar.

[Tim Holloway]

Tomcat comes with no JDK nor fraction thereof. This is how it handles JSP URL requests:

1. Check the Tomcat working storage for a compiled copy of the JSP. If so, invoke it as a servlet.

2. If not compiled:

 A) run JaSPer to translate the JSP into Java source code in a temporary work directory.

 B) Run the javac compiler that is part of the JDK that's running Tomcat (JAVA_HOME or equivalent). Compiled class code go into the Tomcat work sub directory for that webapp.

 C) At that point, proceed like in step 1.

You should not expect to find compiled JSP code when migrating webapps nor should you trust it if you do. The compiled JSP is not stored as part of the deployed WAR and is likely not portable to other brands and versions of JEE webapp servers. While some systems do have ways to pre-compile JSPs when a webapp starts, I discourage even that. On modern systems, the overhead for the initial JSP-to-class compilation is minimal and easily lost in general operation rather than adding to initial app startup time.

Note that Tomcat supports hot updates for webapps, so if you jam in a changed JSP into its deployed WAR, Tomcat will detect the change and re-compile the JSP automatically.

[Stephan van Hulst]

No, I didn't mean to imply that applications come with pre-compiled JSP Servlets. I was referring to applications that consist only of compiled classes, such as web services without a front-end. Theoretically, you could run those applications on a minimalistic application server that implements the Jakarta EE Core Profile. The application server wouldn't require a JDK.

I guess it makes sense that Tomcat uses the JDK to compile the JSP files. I just never really thought about it. I assumed that Jasper consisted of its own small compiler, but when I give it some more thought, that wouldn't really be a good idea.

[Tim Holloway]

I haven't actually seen what's in the JEE Core Profile, but based on history, I'd be willing to wager that it contains servlets AND JSPs. Although come to think of it, I don't even know if the JEE core provides any web functionality at all. JEE, after is not simply a web support system. I've written stand-alone apps that are technically JEE because they used JPA, but had no web or network (excluding JDBC connections) at all.

So it's probably risky to try and run even minimal web applications without a JDK.

It's moot at this point, since JREs are obsolete.

[Stephan van Hulst]

The JEE Core Profile basically consists of CDI, Interceptors, JAX-RS and JSON. It's likely that a JAX-RS implementation will also require Servlets, but the Core Profile doesn't mandate this. So theoretically it's possible to have a compliant application server that hosts restful web services that aren't based on servlets.

[Tim Holloway]

It's a stretch. It seems that only the JAX-RS annotations are defined in the core and that means that what you do with those annotations (if anything) is up to you. However, they do reference HTTP as a data protocol.

Of course, the base class for servlets doesn't actually mandate HTTP, much less a traditional webapp server (HTTPServlet exists for that). But no one has ever explored that route that I know of.

Ther are non-traditional systems that provide HTTP services. For example, the Apache OSGi server family (servicemix and karaf). Then again, I cannot recall if they implement servlets, much less JSPs. This is the sort of platorm that isn't actually a web service, just borrows protocols from HTTP. Many systems do that. The CUPS print spooling system, for example.

[Dean Sabado]

Can these .class files compiled on your home pc be run on another computer?  Say if he is using a UNIX sytem for an html blog.  With clients.
I'm one of the clients.

[Campbell Ritchie]

Welcome to the Ranch

Techno start wrote:Can these .class files . . . be run on another computer?  . . ..

The simple answer is yes. If the second computer has a JRE available, and you put the XXX.class files into an executable XXX.jar, they should run. Since Java9, however, the officially preferred way to distribute executables has been to bundle modules together and distribute the lot. That could include those parts of the JRE you need.

[Tim Holloway]

Dean Sabado wrote:Can these .class files compiled on your home pc be run on another computer?  Say if he is using a UNIX sytem for an html blog.  With clients.
I'm one of the clients.

I worked at an institution where our desktop development systems were Windows XP (it was a while back!). We built JARS and Tomcat WARS which were deployed to Solaris (Unix) production servers and later to Red Hat Linux servers. The exact same WARs ran on all of those machines, totally unchanged and for the most part we weren't too meticulous as to which JVM/JDK version any of those machines ran since we weren't trying out every new shiny improvement to the language all the time..