FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 04-30-2008, 05:14 PM
Andrew Haley
 
Default Java debugging

Les Mikesell wrote:
> Andrew Overholt wrote:
>>
>>>>> On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley <aph@redhat.com> wrote:
>>>>>> I take your point. Does simply rebuilding that RPM fix this
>>>>>> problem?
>>>>> Rebuilding that RPM fails:
>>>>>
>>>>> [javac]
>>>>> /home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
>>>>>
>>>>> clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot
>>>>> override clearCache() in java.util.ResourceBundle; overridden method
>>>>> is static final
>>>>> [javac] public static void clearCache()
>>>>> [javac] ^
>>>> Oh, great. :-(
>>>>
>>>> That's an incompatible change from Java 1.5 to 1.6.
>>>>
>>>> Java 1.6 has a final method clearCache(), 1.5 doesn't:
>>>>
>>>> http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html
>>>> http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
>>> So someone has noticed that shipping a 1.6'ish JVM isn't necessarily
>>> going to work for everyone who needs to run current java applications?
>>
>> Since OpenJDK is >= 1.6 (ignoring gcj and other GNU Classpath-based
>> JVMs), I'm not sure if there's a better solution. Is there?
>
> The obvious solution is to ship a jpackage nosrc style rpm for the Sun
> Java versions that you are unwilling to include. That would fix up the
> fedora rpm dependencies and alternatives symlink weirdness that make
> using your own downloaded binary painful otherwise.

That seems a little extreme. All we have to do is fix a few incompatibilities.

Andrew.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 05:27 PM
Les Mikesell
 
Default Java debugging

Andrew Overholt wrote:


The obvious solution is to ship a jpackage nosrc style rpm for the Sun
Java versions that you are unwilling to include.


This would go against Fedora's goals.


Your goal is to be unusable with java-compliant code?

--
Les Mikesell
lesmikesell@gmail.com


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 05:28 PM
Paul Howarth
 
Default Java debugging

Les Mikesell wrote:

Andrew Overholt wrote:



On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley <aph@redhat.com> wrote:
I take your point. Does simply rebuilding that RPM fix this
problem?

Rebuilding that RPM fails:

[javac]
/home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:


clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot
override clearCache() in java.util.ResourceBundle; overridden method
is static final
[javac] public static void clearCache()
[javac] ^

Oh, great. :-(

That's an incompatible change from Java 1.5 to 1.6.

Java 1.6 has a final method clearCache(), 1.5 doesn't:

http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html
http://java.sun.com/javase/6/docs/api/java/util/ResourceBundle.html
So someone has noticed that shipping a 1.6'ish JVM isn't necessarily
going to work for everyone who needs to run current java applications?


Since OpenJDK is >= 1.6 (ignoring gcj and other GNU Classpath-based
JVMs), I'm not sure if there's a better solution. Is there?


The obvious solution is to ship a jpackage nosrc style rpm for the Sun
Java versions that you are unwilling to include. That would fix up the
fedora rpm dependencies and alternatives symlink weirdness that make
using your own downloaded binary painful otherwise. Or maybe someone
can get the jpackage people to document which of their packages will
work for recent fedora versions.


The java-1.5.0-sun package from JPackage doesn't install on Fedora 7
onwards due it having pathname-based dependencies on things that have
moved in the great modular X shake-up.


Here's how I get Sun Java 5 installed:
http://www.city-fan.org/tips/SunJava5OnFedora

Paul.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 05:35 PM
"Jerry James"
 
Default Java debugging

On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley <aph@redhat.com> wrote:
> I take your point. Does simply rebuilding that RPM fix this problem?

For the benefit of the community at large, I'll repeat some
information I just posted to bug #434827. It seems that
java-1.5.0-gcj-devel has not been updated on F8 since the release of
F8, so the current version is 1.5.0.0-17.fc8, dated 17 Oct 2007. When
did the debuginfo fix go in?
--
Jerry James
http://loganjerry.googlepages.com/

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 07:05 PM
Callum Lerwick
 
Default Java debugging

On Wed, 2008-04-30 at 12:27 -0500, Les Mikesell wrote:
> Andrew Overholt wrote:
> >
> >> The obvious solution is to ship a jpackage nosrc style rpm for the Sun
> >> Java versions that you are unwilling to include.
> >
> > This would go against Fedora's goals.
>
> Your goal is to be unusable with java-compliant code?

We insist on all packages being patched to compile with the GCC we are
shipping, which has similar, if not worse, pain-in-the-ass breakage
issues, especially with C++. Why should Java be any different? Fix the
code, ask for help if you need it.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-30-2008, 07:31 PM
Les Mikesell
 
Default Java debugging

Callum Lerwick wrote:

The obvious solution is to ship a jpackage nosrc style rpm for the Sun
Java versions that you are unwilling to include.

This would go against Fedora's goals.

Your goal is to be unusable with java-compliant code?


We insist on all packages being patched to compile with the GCC we are
shipping, which has similar, if not worse, pain-in-the-ass breakage
issues, especially with C++.


What does that have to do with being able to run other people's
standard-compliant code? Or with shipping a nosrc rpm that just deals
with fedora's internal strangeness.



Why should Java be any different?


Java is different because people need to download their own copy of a
standard-compliant JVM. That's not a problem by itself. The problem is
that the fedora rpms have built in dependencies not satisfied by any
standard-compliant JVM that you can download, and the fedora file
structure expects an odd morass of symlinks that nothing else is going
to provide. Jpackage.org used to fill this need, but the relationship
seems badly broken these days.


> Fix the

code, ask for help if you need it.


It's not my code and it doesn't need to be fixed. I want to run things
like opennms, alfresco, openfire, spark, opengrok, etc. Some of these
may work with 1.6 already but at least opennms doesn't and I don't like
surprises.


--
Les Mikesell
lesmikesell@gmail.com



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 03:21 PM
Andrew Haley
 
Default Java debugging

Jerry James wrote:
> On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley <aph@redhat.com> wrote:
>> I take your point. Does simply rebuilding that RPM fix this problem?
>
> For the benefit of the community at large, I'll repeat some
> information I just posted to bug #434827. It seems that
> java-1.5.0-gcj-devel has not been updated on F8 since the release of
> F8, so the current version is 1.5.0.0-17.fc8, dated 17 Oct 2007. When
> did the debuginfo fix go in?

I asked the java-1.5.0-gcj-devel maintainer, and got the reply:

"We generally don't do updates in Fedora except for security fixes.
We fix bugs in Rawhide and if users of the latest stable Fedora badly
want the bug fix they can install the Rawhide packages."

It's pretty hard in this case, as that'll pull in java-1.5.0-gcj*
as well. Sorry.

Andrew.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 03:21 PM
Andrew Haley
 
Default Java debugging

Jerry James wrote:
> On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley <aph@redhat.com> wrote:
>> I take your point. Does simply rebuilding that RPM fix this problem?
>
> Rebuilding that RPM fails:
>
> [javac] /home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363:
> clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot
> override clearCache() in java.util.ResourceBundle; overridden method
> is static final
> [javac] public static void clearCache()
> [javac] ^

I've looked, and I don't think it's possible to fix this for Java 1.6.

In
http://ws.apache.org/axis/java/apiDocs/org/apache/axis/i18n/ProjectResourceBundle.html,
clearCache() is part of the public API. However,
org.apache.axis.i18n.ProjectResourceBundle inherits from
java.util.ResourceBundle, and that class marks clearCache() as final.
We could delete clearCache() and just use the inherited method as
a workaround, but it doesn't do the same thing.

The only way to recompile this, or indeed to use it, is with
Java < 1.6.

Andrew.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 07:07 PM
"Jerry James"
 
Default Java debugging

On Thu, May 1, 2008 at 9:21 AM, Andrew Haley <aph@redhat.com> wrote:
> I've looked, and I don't think it's possible to fix this for Java 1.6.
>
> In
> http://ws.apache.org/axis/java/apiDocs/org/apache/axis/i18n/ProjectResourceBundle.html,
> clearCache() is part of the public API. However,
> org.apache.axis.i18n.ProjectResourceBundle inherits from
> java.util.ResourceBundle, and that class marks clearCache() as final.
> We could delete clearCache() and just use the inherited method as
> a workaround, but it doesn't do the same thing.
>
> The only way to recompile this, or indeed to use it, is with
> Java < 1.6.

Yes. On the other hand, it's an old version of an obsolete product,
with at least one serious bug that I can easily demonstrate, so I
don't think we should suffer any heartburn over it. What we need to
do is work on getting axis2 packaged. Jpackage already has it, which
should makes things easier.

Who else out there is interested in getting a modern web services
platform put together for Fedora? We should coordinate efforts. I am
being forced to consume an external web service that has references
to the apachesoap namespace, meaning it can only be consumed by axis.
My organization uses CXF to produce our own web services. I can
*probably* get my boss to give me some work cycles towards getting one
or both platforms packaged for Fedora, and then we can just ditch the
obsolete, buggy, unrecompilable axis package.
--
Jerry James
http://loganjerry.googlepages.com/

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-01-2008, 07:09 PM
"Jerry James"
 
Default Java debugging

On Thu, May 1, 2008 at 9:21 AM, Andrew Haley <aph@redhat.com> wrote:
> I asked the java-1.5.0-gcj-devel maintainer, and got the reply:
>
> "We generally don't do updates in Fedora except for security fixes.
> We fix bugs in Rawhide and if users of the latest stable Fedora badly
> want the bug fix they can install the Rawhide packages."
>
> It's pretty hard in this case, as that'll pull in java-1.5.0-gcj*
> as well. Sorry.

Correct me if I'm wrong in reaching these conclusions:
1. No F8 Java debuginfo package includes sources.
2. This will not be fixed.
--
Jerry James
http://loganjerry.googlepages.com/

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 06:15 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org