Suggestions to improve the JAVA guidelines
by Orcan Ogetbil
Hi,
As I promised overholt on IRC, I wanted to share my views about the Fedora Java packaging guidelines from a non-Java-coder point of view.
JAVA GUIDELINES:
- "JNI-using JAR files"
This link is broken. It can be fixed easily.
- BuildRequires: jpackage-utils
Why do we need this? I understand Requires: jpackage-utils for directory ownership etc, but the BR is not necessary for most packages (at least all the ones I saw so far). I think this should *not* be required.
- In certain cases, we can build applications GCJ-natively (producing .so files). But these won't work with any JVM. What should be the packager's primary preference? GCJ-native or OpenJDK? The first one runs faster, but the second one has larger coverage.
For instance, tuxguitar (that I packaged) provides GNU Makefiles (that use GCJ) for this. Are the resulting .so files going to be the same as the ones built by aot-compile-rpm? (More about AOT later)
This case has confused me a lot in the past.
- Some explanation in the beginning about what GCJ can do and what openjdk can do; and some information about byte-code vs. machine-code will be very useful.
- BuildRequires: java-devel [>= specific_version]
How will the packager get to know the "specific_version"? For openjdk this is 1:1.6.0 , but for GCJ this is 1.5.0 . Are there other numbers that we need to know? Can't we put the numbers for all the cases in the guidelines?
- The Specfile Templates for ant and maven contradict with what was written in the BuildRequires and Requires section.
- the abbreviation "SNPG" should be defined in the first possible place, not in the third iteration (both for ant and maven).
- "Will this preserve the line ending as the this page says it must?"
This would be an artistic ending if we were writing a novel. But I think a guideline shouldn't end with open questions :)
GCJ GUIDELINES:
- It would be nice if there was a definition of GCJ-AOT bits. What do they do? Why do we like them? What does gij do? etc
- "Note: For Fedora versions < 8, no JDK was available other than GCJ so java packages with executable code MUST have the GCJ AOT bits."
This notice can be removed safely.
- The occurences of
%attr(-,root,root)
should be removed.
- GCJ AOT bits SHOULD be built and included in packages.
This needs to be more explicit. ie. 's@in packages@in all Java packages@'. I also think that this sentence should go to JAVA GUIDELINES so people click on the link for "GCJ Guidelines". The way that "GCJ Guidelines" link is put there, doesn't give an impression that it should be visited for any possible Java package.
These are all issues I encountered. If I remember more I will post them here. I thought a review on the guidelines from a Java-ignorant person would help other Java-ignorant people in the future. Thanks for reading :)
-oget
14 years, 9 months
jython 2.5fc3 anybody?
by Matej Cepl
Hi,
does anybody works on packaging of jython 2.5rc3? Are there any
preliminary packages for that? I tried to rebuild Rawhide jython
with new sources, but build crashed (I would have to run build
again, not having particular error messages at hand, and I don't
think it helps anybody else than somebody who actually works on
packaging).
My current spec file is
http://mcepl.fedorapeople.org/tmp/jython.spec
Best,
matěj
15 years
Removing Eclipse Fedora branding for F-12
by Andrew Overholt
Hi,
I think the time has come to remove the Fedora branding in our Eclipse
SDK packages. We originally did it for a few reasons (gcj wasn't
supported by upstream and we were relying on it, we were patching a few
places, etc.) but those are mostly gone now.
If I don't hear any reasons that people think we should keep it, I'm
going to remove it in the devel branch by the end of the week, 15 May.
Thanks,
Andrew
15 years
Should the rebuilt java-1.5.0-gcj go to F-11 ?
by Stepan Kasal
Hello all,
I have fixed a bug in F-11 and I need your help for decision whether
the fixed package should be pushed to F11 Alpha or whether it should
stay away from F11 itself and released as a 0-day update.
As you probably know, a mass rebuild was performed during F-11
development (https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild)
java-1.5.0-gcj has resisted all attempts to be rebuilt, so the
latest build was (until now) java-1.5.0-gcj-1.5.0.0-25.fc11,
predating the mass rebuild.
This build contained a i386.rpm for x86, not i586 (the i586 change
was one of the reasons for the rebuild).
But yum "frowned upon" the i386 rpm, leading to the consequence that
the openjdk java was preferred on x86, while gcj was preferred on all
other archs, including x86_64.
This can be puzzling; we have discussed this in the thread I started
a few days ago.
I have worked around the bug that prevented java-1.5.0-gcj from
rebuilding (it was #500314, if you are curious) and rebuilt it.
Consequently, gcj is again the preferred java on all architectures.
This new build of java-1.5.0-gcj is ready for the future rawhide
(dist-f12) and also for F-11. The question is how it should be
included to F-11: it can be either a 0-day update or we can push it
to F11 Alpha.
Before pushing to F11 Alpha, we have to judge the wins and the risk.
- the win is removing the above confusing inconsistency
- But what are the risks that this change introduces a new bug to F11
Alpha? I need your help here as I do not understand Java.
Would you recommend including the rebuilt java-1.5.0-gcj to Fedora 11
itself?
Cheers,
Stepan
15 years
The default java alternative?
by Stepan Kasal
Hello,
I noticed that "BuildRequire: java-devel" is interpreted
differently on different architectures. Namely, it evaluates
java-1.5.0-gcj-devel on ppc{,64} and x86_64 but to
java-1.6.0-openjdk-devel on i586.
I observed this in rawhide koji.
This inconsistency brings various problems, like totally different
documentations builds between i586 and x86_64 (javadoc vs. sinjdoc)
or arch-dependent bugs, e.g., jni.h not found on i586 (#498964).
What's the intended default and who is the guilty one here?
Regards,
Stepan
15 years
endorsed jaxp_parser_impl ?
by Joshua Daniel Franklin
Anyone know a particular reason for this postinstall script in the
Tomcat5 rpm:
rpm -q --scripts tomcat5
build-jar-repository /var/lib/tomcat5/common/endorsed jaxp_parser_impl \
xml-commons-jaxp-1.3-apis 2>&1
It's in both EL5 and the latest Fedora:
rpm -q tomcat5
tomcat5-5.5.27-6.2.fc11.noarch
It breaks an app we've got, so I'm going to file a bug if it's not
required for something.
15 years
Bug in openjdks TreeMap?
by Christoph Höger
Hi,
I enounter a very odd behaviour of a TreeMap. This is the code fragment:
System.err.println("contains: " +
state.getIndexMap().containsKey(termString));
for (TerminalString term : state.getIndexMap().keySet())
System.err.println("KEYS: " + term + "==" + termString +":" +
term.equals(termString) + " compare: " +
state.getIndexMap().comparator().compare(term, termString));
The TreeMap returned getIndexMap contains mappings from TerminalString
to Integer.
This is the output:
contains: false
KEYS: redeclare (1581148120) ==redeclare (1581148120) :true compare: 0
So the key _is_ in that map. It also has the very same hashcode and the
comparator returns 0 and equals() is true. But still containsKey returns
zero.
Any guess why that?
15 years
OT: java question: CharSequence from file
by Christoph Höger
Hi guys,
I need to lex a textfile as fast as possible(TM) by using a set of regex
patterns.
Pattern expects a CharSequence as input. I used to read the input file
into a StringBuffer completely and than start lexing (cutting of the
part that matches in every step).
This is not very effective from both the memory and runtime perspective.
(ok, not so much runtime, since you _have_ to read every char anyway).
Today I just searched for some kind of delayed Buffer that would take
the input from the reader on demand or even do it in a parallel thread.
Is there any such thing out there yet?
thanks
christoph
15 years
F9: Eclipse plug: Subversive SVN does not work?
by Dan Thurman
I have checked out my svn installation and I am able
to access it via my webpage, and then proceeded to
add the URI to the Eclipse SVN Repository plugin
(not Team), and was left with this error:
=========================================
SVN: '0x00400006: Validate Repository Location' operation finished with
error: Selected SVN connector library is not available or cannot be loaded.
If you selected native JavaHL connector, please check if binaries are
available or install and select pure Java Subversion connector from the
plug-in connectors update site.
If connectors already installed then you can change the selected one at:
Window->Preferences->Team->SVN->SVN Client.
Selected SVN connector library is not available or cannot be loaded.
If you selected native JavaHL connector, please check if binaries are
available or install and select pure Java Subversion connector from the
plug-in connectors update site.
If connectors already installed then you can change the selected one at:
Window->Preferences->Team->SVN->SVN Client.
How can I resolve this problem?
15 years
