[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Integrating the FOSDEM 06 Draft into the Java Policy

On 23.03.2010 11:54, Niels Thykier wrote:
Sylvestre Ledru wrote:
Le mardi 23 mars 2010 à 10:26 +0100, Niels Thykier a écrit :

I have compiled two patches against the current policy that I intend to
apply Friday assuming there are no objections.
Nice work. Glad to see that finally evolving.

Could you just add a few bit on the gcj part ?
* What it is/was ?

Personally I felt the first paragraph of the gcj part was enough. To the
best of my knowledge this is why the gcj stuff is. If you feel it is not
enough (and the addition draft below does not help), then I will need
some pointers to what you would like to see.

That being said I think it would be easier to understand if I replaced
"native code" with "machine code" and I intend to implement this with
the next diff.

* Why it is no longer allowed ?
* What kind of information are expected to grant a packager the
permission to ship gcj-code

Sure, what do you think of this:

	In the past gcj packages were added in order to improve
	performance of Java libraries and programs. However, this
	performance comes at the cost of size, extra compilation
	time and creates architecture dependent packages.

not only in the past.

	A request for permission to add gcj should packages should
	convince the Java Team that the performance boost of adding
	the gcj package or packages out-weights the disadvantages.

this is always true for archs not having vm with a JIT.

	The request and the permission may be limited to certain

that should be removed. there is a list of these archs in
/usr/share/gcj/debian_defaults which should be sourced in debian/rules.
it's fine to build these packages on every arch. the empty package doesn't hurt, and you won't have to make changes to the packaging if a new architecture is added.

the packages do make sense for architectures which only come with the ZeroVM in OpenJDK, and no JIT.


Reply to: