Java on VMS

[Jan van den Ende]

Does anybody else have "the Java Experience"?

- ANY product using Java has its OWN Java with it.
Well, the is some reason to that: Thanks to the shining Sun any version (down to patch-level) of Java appears to be incompatible (upward, downward, or sideways) with ANY other (sub-)version, so you need EXACTLY the version on which your product was built. Sad, but that's what the world seems to want.

- for ANY product I have seen so far that uses Java, the RJE does NOT have any concept of common access to disk-data (read: program code etc). So you have to do a FULL install for EVERY node in the cluster (I am told it is the same for Tru64; so much for the fact that Sun "does very good clustering".)

- if you happen to have several products using the SAME Java version, imagine how many duplicates you have (and have to maintain!)


Would it be a very terrible effort to declare Java a formal Layered Product, installed in its own, version dependant, Concealed Device?
That allows multiple simultanious versions, but ONLY one of each clusterwide.

Starting _A_ JavaRuntimeEnvironment would require setting up ONE logical name pointing to the desired version.

- would it hurt very much if the JRE images are INSTALLed ? :-)



If enough of you forumers agree, I think we should make this into a formal call to HP.


Cheers.

Have one on me.

Jan

[Ian Miller.]

I agree the current multiple copies that may or may no be the same is a mess. Parhaps another issue for the hpadvocacy.com web site?

[Willem Grooters]

Jan,


Does anybody else have "the Java Experience"?


What'ld you expect - in the Land_Of_Blue....
On our development machine we have 1.1.8, 1.3 and several 1.4.x versions - in
parallel. So I can tell at least something....


- ANY product using Java has its OWN Java with it.

Not entirely true. Some do, some (most?) don't. Agreed on the lack of
comptability in any direction, but it depends. Some are worse than others. I don't know if that's what the world wants. The "donno-CIO" anyway. How innocent can you be ;-(


- for ANY product I have seen so far that uses Java, the RJE does NOT have any concept of common access to disk-data (read: program code etc).

If you mean" No shared images", that's true. You cannot install the JRE
shared, nor the class files (what you would call "executable code") - like you would expect on VMS. Primarely due to the concept the JRE is designed, this is simply impossible. EACH process running a JAVA application will have its OWN java environment. That's part of the problem.


So you have to do a FULL install for EVERY node in the cluster.

Not entirely true. Do it on a shared disk, accessable by all nodes. If you
have shared system disk, and do the default installation, you're done, it will install in VMS$COMMON! You may have to put the setup-files, as used by the process to setup the JRE, in a centralized location.
(Isn't this true for ANY VMS-native compiler?)


...so much for the fact that Sun "does very good clustering".

You're kidding, I hope.
SUN doesn't cluster. It clutters. Sun tends to make things hopelessly inefficient in order to sell more hardware :-D.
(You know: "the only SUN that never sets, is an VMS cluster in DoD-IOE-mode")


- if you happen to have several products using the SAME Java version, imagine how many duplicat8es you have (and have to maintain!)

Again, not needed; depends how you installed it. You can have several JAVA versions in parallel, completely separated. All products that use the same version can use that single version's JRE. Within a process context you just set the right JAVA environment - with all logicals, symbols etc refrerring to the right version by calling the right version-specific setup commandprocedure. The only point is you can have ONE active at a time within a process.


Would it be a very terrible effort to declare Java a formal Layered Product,
installed in its own, version dependant, Concealed Device? That allows multiple simultanious versions, but ONLY one of each clusterwide.
Starting _A_ JavaRuntimeEnvironment would require setting up ONE logical
name pointing to the desired version.

For what I've seen, each Java version installs in it's own directory -
default under VMS$COMMON - and has it's own setup commandfile. Do it on a clusterwide disk and you're done.

Declare it as being a Layered Product:
I suspect that the JRE (and SDK) are created and maintained by SUN, not HP (and certainly not by OpenVMS engineering); at least: goverened. To have ANY JAVA environemnt fit within the OpenVMS way-how-things-are-done will require drastic change of attitude at SUN - given your (valid) concerns. I don't think that will ever happen.


- would it hurt very much if the JRE images are INSTALLed ? :-)

I think this is impossible, given the nature of how JRE behaves. Again, only after things have changed.


If enough of you forumers agree, I think we should make this into a formal call to HP.

See above. It will require HP to pay a huge amount of money to SUN in order to get that done. I think there are better ways to spend the money.

Willem

Don't get me wrong.
Java DOES have advantages. It's just not mature enough to be marketed.

[Bojan Nemec]

Hi Jan,

I think that this is more a problem of bad application programming than problem of java itself. I "play" with Java for abbout 4 years on different versions an different OS platforms and much of programs I write are upward and downward compatible. You need much effort to do this (yust read the documentation and not use the last feature :-). But this is true for every programming language (How many "normal" VMS programmers can write a shareable run-time library which will be upward compatible?)

I think that Java libraries (which are shareable images) can be installed. Something different is with Java code. You must think that running a java program (class) is much more similar to booting a virtual computer than running a program.

So pressure must be made on product developers to write clean and not java-version depending code.

And I am with Willem. Java DOES have advantages. It is a clean and good object language which is not platform dependent.

Bojan

[Willem Grooters]

It is a clean and good object language which is not platform dependent.


I didn't say that.

"Not platform dependent": yes, BUT only as long as you do adhere to U*x way of doing things, which makes it a different matter on VMS: Do NOT expect a JAVA application to co-opereate flawlessly with non-Java, native programs. It won't, except if the JAVa application is completely isolated, by communicatting over a TCPIP socket, without any other interaction. Still inefficient (by nature).

"clean and good": I simply can NOT agree.
I see no problems in the basics of the language itself - nor the basic concept. It has quite a few great built-in solutions making your work as a programmer very easy, especially where communication and interfacing is involved.

But "clean", no way.
I have not that much experience with java, but I'm not impressed by Java's cleanliness. Just take a look to all 'depricated' methods and why the deporication: Most because it didn't work the same on all platforms.
IMHO, the errors were not fixed but circumvented: create a new class, with methods having the same name and actual function but now really 'platform independent'. I cannot call that 'clean'.

Nor "good".
Java allows (and, I suspect, practices) what I consider "dirty programming": create an object of a given class, if done create a new one without removing the previous one first. Simply forget - clutting up memory with a lot of junk. Well, carbage collection will take care eventually - stalling your machine once in a while...

Of course, this is largely a matter of good programming practice and the dicipline applying it. But the standard lacks methods to enforce these good practices, and though carbage collection _may_ be required (due to the nature of Java: it still is an interpretor!) having no control over it is a mistake.

The basic idea was to create an environment where you could use a standard workstation (SUN, preferable ;=)) to create OS, applications and whatsoever to be used in cell phones, automates etc. To be able to be hardware independent, it is needed to build the image against a 'virtual machine' and then execute that code on specific hardware.

The concept of a platform-independent 'virtual machine', from where any hardware platform can interpret the code into natively executed instructions is a very nice idea, indeed. But the flaw is the implementation - and it's background.

The JAVA standard is set and controlled by an institute that has a direct, commercial interest in the product: SUN. It should have been passed to an organization in which all parties that have an interest participate - the very same way other programming languages, general standards etcetera are set and controlled.

In that case, there might have been a much more straightforward and far more efficient procduct, that could adjust to the platform facilities - when available.

[Jan van den Ende]

Willem,



Not entirely true. Do it on a shared disk, accessable by all nodes. If you
have shared system disk, and do the default installation, you're done, it will install in VMS$COMMON! You may have to put the setup-files, as used by the process to setup the JRE, in a centralized location.
(Isn't this true for ANY VMS-native compiler?)



Well, at least my latest Java experience was installing the VMS agent for Open View San Manager, (see my thread on that) which
- DOES have its OWN JRE
- installs HARDCODED in SYS$SPECIFIC
- uses SYS$SPECIFIC in many, many places in all kinds of files. I _COULD_ of course edit the files that are in text format, but that would leave me out in the blue on ANY occurring issue, let alone anyone else who would inherit the stuff. Plus, I am not sure (yet( whether it is used in some image as well.
- runs ONLY by user SYSTEM


So, maybe I have been generalising a bit too much, and the general situation altogether is not as badd as this specific one.
Guess that would convert the problem to : How do I get a decently-installable variant of this version of JRE, &, would OpenView accept a JRE that is NOT SYS$SPECIFIC, but off-system disk?

.. and the situation of this same software for tru64 is even worse: according to my SAN- and Tru64 managing collegues even the installation procedure does not accept rather normal tru64 settings.
All-in-all rather a shame that software from HP is delevered in this condition... :-(

Cheers.

Have one on me.

jpe

[Jan van den Ende]

Willem,


If you mean" No shared images", that's true. You cannot install the JRE
shared, nor the class files (what you would call "executable code") - like you would expect on VMS. Primarely due to the concept the JRE is designed, this is simply impossible. EACH process running a JAVA application will have its OWN java environment. That's part of the problem.


I am not sure if we understand each other here.
Why should Shared images be forbidden?

No shared JRE? Give me ANY reason why COM files etc cannot be used by various system at the same time?

No shared class files. Ok, I know way too little of that to give reasonable comment either way

EACH process will have its own Java environment?
(question from ignorance :-( How do you mean that? Is there only ONE process doing Java, in some re-entrant way serving multiple users? Or do you mean each Java-using process must have its own full copy of the JRE?


Well, maybe this should be summed up as I have been living way too luxurious in the (almost) VMS-only world, and this is a
"Welcome to the real world, what you consider horrors is really normal"

:-(

Anyway:
Cheers.

Have one on me

jpe

[Willem Grooters]

- ANY product using Java has its OWN Java with it.

Not entirely true. Some do, some (most?) don't. Agreed on the lack of
comptability in any direction, but it depends. Some are worse than others.


THIS was my reply on this.
This HP "product" (HP: sorry for the quotes but that's my hesitation given the experiences exposed in this sthread) seems to be one of those that do (luckily) but (unluckily) NOT in a proper (that is: OS specific) way.
(MIND THE LAST SENTENCE. This is a deliberate statement)


I am not sure if we understand each other here.
Why should Shared images be forbidden?

No shared JRE? Give me ANY reason why COM files etc cannot be used by various system at the same time?


Must be a misunderstanding. Sharing files is of course NOT forbidden. COMfiles - and classffiles are of course shared. It's the OBJECTS that are the result of instantiation of the calsses that aren't.


No shared class files. Ok, I know way too little of that to give reasonable comment either way


You may install the class files as a known image, but that will be the limit.
With that, that is the max you can do with the JRE as well. This happens to be a bunch of classes, contained in a number of (compressed) Java ARchive (.JAR) files.


EACH process will have its own Java environment?
(question from ignorance :-( How do you mean that? Is there only ONE process doing Java, in some re-entrant way serving multiple users? Or do you mean each Java-using process must have its own full copy of the JRE?

The last one. Java runs in a Per process method. The basic .COM file to start a JAVA application is like these three steps:

1. @SYS$MAANAGER:JAVA$SETUP (since 1.3, the JAVA releasenumber is part of the filename but I al;ways forget where it is...). This sets a number of logicals and symbols.
2. Update CLASSPATH logical to include ALL directories where classes or class-containes (.JAR) can be found
3. Execute the application: java

The JRE is started in that process's context. ALL objects are created within that process's addressspace.
A second process can do exactly the same thing, but within THAT process's context.

That means that EACH process has it's own copy of the JRE (which can be a different version, by the way) - and will need tons of addressspace.

One cheer for SUN. We can sell CPUs, memory and disks :-(((((

Let's get drunk. I'm just a small-system user...

Willem

[Jan van den Ende]

Willem,

thanks for the speed-course.

So, essentially, if I understand correctly, all FILES can be shared, but any code (being gigantic) is always loaded in process space?
Well, that WAS my original impression, which was shattered be this special installation.

It seems to boil down to the terrible implementation of the OpenView stuff.
Obviously the ones who built the Agents for VMS and Tru64 are even more to blame then Sun. And THAT makes me really sad!


Let's get drunk.


You are alone on that one. I really like a good beer, especially if it comes in plural, but I pretend that I usually succeed in staying below that theshold (which tends to get higher with training!!!)

Have you look at the time?

Anyway:
Cheers.

Have one on me.

jpe

[Willem Grooters]

So, essentially, if I understand correctly, all FILES can be shared, but any code (being gigantic) is always loaded in process space?

Your understanding is correct.
To be more precise: JRE is, for some part, ONE execuatble: java.exe. (You _may_ be able to install THAT part - as a shared image.)
The rest is created at runtime - by the java executable - in the addressspace of the process. Since JRE is a bunch of classes, it will be expanded to objects in runtime and therefore in the process's context. So will the application.
Keep in mind that these created objects are VM-executables - VM = Virtual Machine. Actually, it's byte code - which is interpreted and executed by the JRE. Since this all is within the process itself, it cannot be shared.
That's why a java-application takes HUGE amounts of virtual memory and CPU power


It seems to boil down to the terrible implementation of the OpenView stuff.
Obviously the ones who built the Agents for VMS and Tru64 are even more to blame then Sun. And THAT makes me really sad!

Well, using Java for this does make sense, to be honest. The major part won't be much difference whether run on VMS or TRU64 (or virtually any platform). With java, you have to code this whole bunch just once, then it will run on any platform. Just some stages can be different, and perhaps may be controlled by some configuration file.
The main point is that java does not cover the concepts we're so used to on VMS: shared objects, shared code... It has never been an issue, because java was never designed that way but for 'single user usage'. (ever heard of a clustered cell-phone?). This is not SUN's fault.
For this agent - one active on each machine - I don't think there would be too much of a problem. It would be quite different if you had tens of it (or even more).
Nevertheless, the designers of this OVSAM software should at least have been aware of the potential problems.

I do agree that the way the installation and usage-requirements have been set up, as I read in your other thread on the subject, is definitely NOT the way it should have been done. That, indeed, is HP to be blamed for.


Let's get drunk.


I get so many by you, I will. But it's no fun doing it on your own :-D


Have you look at the time?

Too early, I know...But sometimes, ANY time is right ;-)

Cheers.
Have one on me, for a change.

Willem