Bug 157444

According to a posting on the opensuse ML, it still seems to be an issue on beta8.

Strangely enough, I could install the program without any problem, however:
The oxygen editor needs to have explicity a Java runtime from SUN.
Does it still make sense to put energy into getting the installation to run smoothly with gcj if the program itself needs SUN Java anyways (tried BEA as well and it still complains)?
Note: The installation can be done in a 'non-Gui' mode as well, passing the setup the '-c' option.
Adding gcj-compat and libgcj to CC.

I don't know what to answer regarding java-1_4_2-gcj-compat
(i.e. what is the question reagrding java-1_4_2-gcj-compat)?

If XEP runs only with SUN JRE, shouldn't there be an explicite
RPM requirement for SUN JRE in our XEP spec file?
Or is this "XEP" a third-party product?

There was actually now question :)
I just added you as the problem occured with GNU Java. 
XEP is a third party software, that is correct ... and it explicitly needs SUN Java to run. 
To my knowledge there is no RPM but only an install script.
The error that occurs during the installation phase could however probably be valuable for improving libgcj.
The question is if we are going to do anything about it. Therefore we need more info on the error that occurs and we need to be able to recreate the bug.

And from my side it seems that nothing is to be done.  According to comment #2
it installs fine.  That it doesn't run because it requires Sun Java
explicitely is a problem of XEP not ours.

Now the only remaining problem is:
Is it INVALID or WONTFIX or WORKSFORME?
;-)

XEP ran on 10.0 "out-of-the-box".  On SL10.1 (and on SLE 10), the user has to take special action to make XEP running.  XEP might not be the only java program that will fail (see comment #1).

I do not know, why my installation attempt failed...  I tried on beta7...

It does not seem to be an option to install Sun Java as our default java engine. I'd recommend to "warn" the user in the release notes.  Maybe, that's already done for SLE?

huh? But we don't ship XEP, right?
The XEP program itself insists on a SUN Java runtime, so I don't see how we could fix that.
Note that we shipped SUN Java on a 10.0 ... but we can not change the fact, that XEP checks whether the used JVM is the original SUN or not.
I think it is only the default Java on the OSS version ... on all other versions the user can choose in YAST IIRC.

Karl, use the binary add-on CD and install java from there.

Thanks, I got it running in the meantime.  In the release-notes, we already mention the "Add-On CD-ROM with Binary-Only Software" (see Bug 144403).  Maybe, we should simply add java as another piece of software, that the user can install from it?

@comment #8: Our competitor ensures that third party software still runs after a system update - at least, he tries up to soem degree.  Last, java programs are hyped to be plattform independent - this means we must tell the user how he can continue to work with already brought java software.

Regarding comment #10 "java programs are hyped to be plattform independent":
Do not mix up "platform" (e.g. i386 versus x86_64)
with "Java Runtime Environment (JRE)".
It is a well known problem that many Java programmers like
to use the most current "hyped" features of a particular JRE.
This was meant as a general info and it does not mean
that XEP has also this problem.
Nevertheless: From my point of view it is still one of
INVALID, WONTFIX (i.e. CANTFIX) or WORKSFORME.
And this does not mean that we do not appreciate it
that you informed us about this problem.

Let's close this as CANTFIX.

Karl, feel free to add java as proposed in Comment #10.