What are the concentual differences between Java Virtual Machine (JVM) and Java Middleware?
JVM is a runtime to execute Java (and a few other languages these days) bytecode.
Java Middleware are frameworks for technologies like EJB, RMI, Corba etc. Essentially technologies which might not have anything to do with Java specifically, but is supported by Java.
Related
Am I seeing a fundamental difference between how Java Standard API and Java EE API's are implemented?
Java Standard API is up here, implemented by Oracle, for anyone to use in Java programming:
http://docs.oracle.com/javase/7/docs/api
But why is it that makers (i.e. IBM, RedHat, Oracle) of application servers (i.e. JBoss, WebLogic, WebSphere, GlassFish, WildFly) come up with different implementations of the same Java EE API?
Example-1: RESTEasy is an implementation of JAX-RS available with JBoss
Example-2: HornetQ is an implementation of JMS available with WildFly
I guess I should ask, "What does it even mean to have this EE API page on the Oracle website since every vendor has its own implementation? Is the link below just for a show?"
https://docs.oracle.com/javaee/7/api/
Your initial assumption is not entirely correct.
There are in fact several implementations of Java SE besides the most widely used oracle distribution. The biggest ones are OpenJDK and IBM's JDK.
So, the Java SE API's have a spec just like Java EE does, each with different implementations. The oracle api links you posted are merely requirements for the interfaces, but there still needs to be an implementation for these APIs whether it's Java SE or Java EE.
Is it possible to implement a RabbitMQ RPC between Java (acting as a client) and a .NET application (server/worker) using the RabbitMQ .NET library?
It seems like it should be possible, as RabbitMQ broker handles the queues and the socket connections are established between party and the RabbitMQ broker.
Are there any practical considerations in doing so?
The short answer is yes. In fact, my company uses RabbitMQ for that very reason - it offers a platform-neutral (as close as possible anyway) way to communicate between different applications. So in theory, I could have Java applications running on Linux and .NET applications running on Windows, and everything works together just fine.
You will need to come up with a common serialization format for your messages; I recommend using JSON as there are JSON libraries in every major programming language.
If you have any trouble with the RabbitMQ .NET library, feel free to post more questions :-)
Would the JVM (and probably also the CLI) be considered a virtual machine (the equivalent of the x86 in a "normal" program stack) or a virtual OS (the equivalent of Windows)?
Strictly speaking, it is a virtual machine, ie: it executes a special low-level language (similar to x86 ASM. CLI uses MSIL, JVM uses "byte codes") and translates them into the target machine's op-codes (x86, x86_64, ARM .. etc.) for execution on the host CPU.
It also manages marshaling (ie: correct handling and passing through of variables to native memory stack/heap) to allow function calls from inside the managed world to the outside OS on which the VM runs.
Practically though, neither the JVM nor the CLI alone are very helpful except for automated garbage collection and CPU-architecture-independence, but they are complemented by a large base library (the Java classes, or the .NET BCL) which allows you to do many platform-y things without having to call platform specific APIs and use marshaling manually for everything.
That's why there is a different Java Runtime Environment for each OS. Each one's JVM translates to a specific CPU arch, and uses different platform specific-APIs to accomplish what the unified base library exposes to you as a friendly API inside the managed world.
Hope that helps you.
The jvm is considered a real computer, only not realized in hardware. The machine has it's own storage capacity, it's own memory model, it's own specific behaviour of it's central processing unit and it's own internal machine code. This machine is extendable with new possibilities and modules that are represented with classes, API's, etc...
It has it's own stack based architecture, like most virtual machines.
How does software allow developers to make a plugin / extensions on top of its core? How is that related to object oriented programming? maybe with inheritance or interfaces? What kind of design pattern should one use?
For example, firefox extensions that enhance firefox, wordpress extensions, etc. Those systems sort of "recognize" plugins after being installed and work well and in some cases they perform safety checking, dependencies, and the like.
Anyone care to shed light on this?
Plugin models in real applications like firefox may be more complex than they are in general. In general you define some interface that a plugin should implement, and implement it in your plugins, that's it.
Modern frameworks contain plugin development facilities like MEF in .NET, mojo in Java, etc.
Java supports a basic plug-in mechanism through its SPI (Service Provider Interface). The main mechanism revolves around discovery and binding of the new provider. Below two articles will get you started
Replaceable Components and the Service Provider Interface
Creating Extensible Java Applications
There are open source frameworks that are more powerful than provided by JDK
JPF
JSPF
But OSGi is the standard and mother of all plugin frameworks in my opinion.
I have two Java Programs each running in its own JVM instance ? Can they communicate with each other using any IPC technique like Shared Memory or Pipes ? Is there a way to do it ?
Yes; D-BUS and Pipes are both easy to use, and cross-platform. D-BUS is useful for general message-passing IPC, and pipes for sending bulk data.
You can also open a TCP or UDP socket on localhost, if you need to support multiple clients connecting to a central server.
I also found an implementation of UNIX sockets in Java, though it requires the JNI.
http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp
Java Remote Method Invocation (Java RMI) enables the programmer to create distributed Java technology-based to Java technology-based applications, in which the methods of remote Java objects can be invoked from other Java virtual machines*, possibly on different hosts. RMI uses object serialization to marshal and unmarshal parameters and does not truncate types, supporting true object-oriented polymorphism.
Sure. Have a look at RMI or a Shared Memory concept like Java Spaces.
Use MemoryMappedByteBuffer in Java NIO for sharing memory between processes.
There is a fairly new initiative for language-agnostic IPC of columnar (i.e. array-based) data from Apache called Plasma.
As of yet (Sept '17) there are no JVM bindings, but as the project is backed by the likes of Spark, I think it won't be long before we see an implementation.
My understanding however is that there is not a general IPC system, as it is geared toward sharing arrays of primitives like double,long, for scientific computing, rather than classes/objects; though I could be wrong here.
On the plus side, it's also language-agnostic, so you could use it to communicate with another (non-JVM) runtime. However, the OP did ask for Java IPC so this could be irrelevant.