And since I'm worried that folks won't
notice or take the time to read a long
attachment, here's the same text in-line
(but I think it will be mangled - if
so, see the attachment to the previous
post :-))
WOW! There is a LOT of FUD in this thread and unfortunately, most of it caused
by the way the original question was posed by the SMDteam. I claim the problem
statement is imprecise/incorrect in a way that has sparked some of the FUD in
the replies.
Background: I'm an HP software engineer in the system management space. I
joined HP from the Tru64 side of the house. We've used Java-based tools
for Tru64 and experienced many of the problems that this thread mentions.
I work alongside the SMDteam but not directly on their project.
Specifically, what has caused the major problems thus far was this
part of the original question:
One choice we are considering would require Java to be installed on your
system in order to run the software management tools for either a GUI
(graphical) or TUI (terminal).
I claim that this is *not* a valid choice/consideration (or the wording is
imprecise). As a bundled management tool, you cannot/should not require that
Java be installed. Let me be clear here. I'm referring to the base OS version
of Java. For example, if 11i V2 comes with Java 2 1.x.y, you cannot require
that the sysadmin have to install that. Why not? Because you can't control this
version of Java (as other posters have pointed out). It might require patches
that end up breaking your product. The customer might want to uninstall it to
make room for Java 2 1.x+1.y+1. Again, a version that might break your
product. You are basically *forced* to take a different tack (that has some of
it's own issues). You *have* to bundle the specific JRE you want with your
product. Having lived through binary incompatibilities introduced by Sun into
Java, I can state this categorically.
This way Java is not an installation choice at all for the end-user. The right
Java that is known to work and is totally under your control is always on the
system *in a private/application-specific directory*. This JRE is completely
divorced/separate from any other JRE on the system. So all of the specific
concerns from the following posts become moot:
Patrick:
>...Also, I do not want to have to worry about installing more software to
>make something work. If I don't have to install Java on a machine I don't.
Laurie:
> 1b)Imagine how a user would feel the day they NEED to install a new patch
> or recover a system with ignite and find they can't because of the wrong
> version of JRE.
Steven:
> Java is unreliable. Reliance on java tools could cause version
> conflict issues with Oracle which requires and certifies with only
> certain versions of java.
T G Manikandan:
> b)The dependencies for a tool to work is a hell
Jeroen:
> Yes, but HP has to make damn sure that it is more or less Java
> version independent and that the Java product is stable and easily
> installed.
Volker:
> 1b) "To run xyz-SW goto
www.sun.com/wherever and install java_1.2.3.4.5
> first" When you go there, you find that java_1.2.3.4.5 is not downloadable
> anymore. Instead you can download java_2.3.1.2.3. Try it, ... it runs !
> But is it still supported now ?
Paula:
> 1. NO - As many have said I want to handle my machines out of the OS
> box and have to install additional software.
Stefan:
> 1b) ... and requires a lot of updates/patching.
Now I will readily admit that what we are saying about Java here applies in
general to *anything* that you have a dependency on. I'm very curious what the
response would have been if the SMDteam had said originally:
One choice we are considering would require Perl to be installed on your
system in order to run the software management tools for either a GUI
(graphical) or TUI (terminal).
I'm guessing that there would have been none/little/much less pushback. That's
just a guess. If you feel I'm wrong, please let me know.
Now, I'm sure folks have thought ahead by now and see the problem with the
stated solution. Everybody and their mother has a private version of the JRE
squirreled away. This is precisely what happens on MS Windows today. Products
bundle their own private JRE's. I claim that for all the HP products, they have
to cooperate and share this "private" version of the JRE to avoid complete JRE
anarchy. This is not entirely problem free. We definitely had the case on Tru64
where products were not in sync. and at least one required Java 1.1.8 and the
rest were Java 2 (so we had two JRE's on the system). That's better than
one-JRE-for-every-java-based-product though....
The bottom line is that with a private JRE the choice of Java version issues
are not in the admin's face and causing all sorts of headaches. Now there
are other issues mentioned for Java. I'll return to those in a second.
First I want to address some other specific comments:
Patrick:
> 1b) I DESPISE Java. If the applications are not written well, they
> are junk and perform poorly!!!
The same things can be said about C, C++, Fortran, etc. applications :-)
I don't think it's fair to characterize all Java apps in this way.
Steven:
>Being able to perform installations via web interfaces present
>another possibility of root password compromise. I Think presenting
>the option is fine but leave my command line alone.
There is no question that the command line will still be offered.
Pete:
> c. A CLI would be acceptable if that's the way it had to be to avoid
> Java. Otherwise I can't begin to see the reason not to offer both.
See the above. There's a CLI today and there will continue to be one.
The goal is the offer the CLI and additionally a GUI.
Jeroen:
> b. If not, what are your concerns?
> My concern is that it is depending on other software to run and that
> you need a graphics terminal to run it.
I understand the dependency part (and hopefully have addressed it above) but
I'm not following the graphics terminal part at all. Java is no different
from X11 in this regard. You need an Xserver for both. If you don't have an
Xserver you are left with only three choices:
- curses/TUI (a terminal user interface)
- a command line interface (CLI).
- a browser interface (and of course the browser requires a graphics
terminal somewhere).
However, none of this is related to Java.
Jeroen:
> What technology is usewd by the scure web console? Only web, or also
> Java?
I can never keep secure web console and Central Web Console straight, but CWC
definitely required a Java-capable browser. This was used to launch a Java
terminal emulator for example, to connect to a machine's serial console.
Armin:
> 2a) Please DON'T port everything to be usable with a web browser! A
> real bad example is the kernel configuration in sam in HP-UX 11.23.
> The additional option of doing it over a web interface is ok... but
> do not ignore the ASCII-terminal user. We have 300 systems here and
> in certain cases I can only access them via GSP.
Armin, just to be clear. By ASCII terminal user do you mean you
want only a good CLI (command line interface) or do you want good
curses/TUI style apps as well (or both)?
Also, like Anita, I'm curious what issues you've had with kcweb - the web
based version of kernel configuration tools.
T G Manikandan:
> 2.a)kcweb dependencies on Apache,some other tools.Lot of problems
See above. It would be great to get the specifics here.
Victor:
> c. What's wrong with the user interface?
> I like it - it works - are you planning to stop X support?
I general, management tools are definitely moving away from X support where
"X support" means CDE/Motif/X11 applications. Instead, GUI's are moving more
and more to being either:
- Java based (java standalone applications and Java applets (which run
in web browsers)
- web browser based (e.g. HTML based - optionally using some
javascript and some java as well).
OK, that leaves us with all the other java issues raised in the posts.
Namely:
- performance
- memory utilization
- security
There's no question that the typical Java app is more heavyweight than that
standard C or C++ Motif/X11 app. The Java VM has a real cost. This cost is
typically most visible in terms of the memory footprint of Java apps and app
startup time.
So let's say that a Java-based application has twice the memory footprint or
three times the memory footprint of a traditional X11 GUI (just to pick a
number - I don't have an real example here). How bad is that? For older, small
memory systems that could definitely be a issue. How about for more modern
systems? You probably have a GB or multiple GB's of memory anything purchased
in the last 5 years. I'm not suggesting that system management apps consume
that GB or GB's :-) but I'm suggesting that memory footprint is only an issue
on severely memory constrained systems. If the system is that tight on memory
you are probably using the CLI only and not even X11 management apps....
It would be much worse for long running apps (say a daemon written in Java)
vs. a management tool that you tend to run and then exit. In this specific case
we are talking about software management. You install or install a product or
do a system upgrade. These are reasonably finite operations. How bad is it that
the GUI for such operations takes more memory than a traditional X11
application? Also, Java does have the promise of run-anywhere. (Write once and
run anywhere == write once and test everywhere :-)). That makes it very easy to
build client/server applications. The software management tools are
client/server today. So the Java GUI could run on a workstation, on PC, on a
Mac, etc. I'm not saying that we'd support them on all these clients but the
GUI could run there - and when it does there is no memory issue! Well, it's a
memory issue for the client machine :-) But if that machine is your management
PC or a management workstation, how bad is that?
Let's move on to performance. The complaint I hear most often is that a Java
app takes longer to start up. That's definitely true. Once it's running,
performance is typically not an issue. It's the long startup times that tend to
annoy admins. Again, the startup time depends on the specific Java
application. Even if the startup time was longer than the X11 GUI, in the
software management space, how bad would that be? What do you consider adequate
startup time? (Note: For recent customer surveys we've asked that question of
admins and the answers have been all over the map! Answers have ranged from 0
seconds to 1 minute and 30 seconds....). For me, it's a "how often to I need to
run the application" issue. If I run it 10 times a day vs. once a week, I'm
much more concerned about the startup cost... Please don't make the assumption
that just because it's Java based it MUST have unacceptable startup
costs. That's simply not true. Said another way: Do you not run the X11 tools
today because they take longer to start than using the CLI? Well, rest assured
you will continue to use the CLI :-)
Lastly, security. No specifics were mentioned in any post with a few
exceptions:
Laurie:
> 2b) Working in a firewalled environment means
> there will always be unavailable ports.
> X11 may not be allowed. HTTP on port 80 may
> be unavailable. HTTPS and SSH seems to be
> the most favoured direction.
Steven:
> We don't use root password through any thin clients for fear that
> Microsoft IE will cache the root password on the C: drive.
Volker noted:
> 2b) Any additional Network port for administration agents is a potential
> threat. So if I can get away with ssh I would always be hapy with this.
G Vrijhoeven:
> 2b. The ablilty to install software on remote servers (push function)
> always can generate a security leak. I think ( and know) this must be (
> is) considered. I am no security guru but i am sure HP has some.
None of these are Java related. They are general security concerns. If you
feel that the use of Java itself is somehow a direct security issue, please do
post the specifics. Thanks.
pete
