[java-policy] 52/198: JNI added, and refer to classpath url instead of listing free jvm:s.
Emmanuel Bourg
ebourg-guest at moszumanska.debian.org
Wed Sep 23 07:49:29 UTC 2015
This is an automated email from the git hooks/post-receive script.
ebourg-guest pushed a commit to branch master
in repository java-policy.
commit 8736bbc353c7e403b010eca52c28d32f4a991710
Author: Ola Nordmann <olapc at yahoo.no>
Date: Thu Apr 17 11:43:24 2003 +0000
JNI added, and refer to classpath url instead of listing free jvm:s.
---
debian/changelog | 8 +++++++
patches/0.18-jni-policy.author | 1 +
patches/0.18-jni-policy.patch | 52 ++++++++++++++++++++++++++++++++++++++++++
policy.xml | 37 ++++++++++++++++++++++--------
4 files changed, 89 insertions(+), 9 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index a3eda41..965606d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+java-common (0.19) unstable; urgency=low
+
+ * Added JNI standardized directories, closes: #163390.
+ * Updated FAQ from cvs.
+ * Now refer to an url instead of listing free jvm:s, closes: #146731.
+
+ -- Ola Lundqvist <opal at debian.org> Thu, 17 Apr 2003 13:32:41 +0200
+
java-common (0.18) unstable; urgency=low
* Updated java faq from cvs to fix deb source line, closes: #162733.
diff --git a/patches/0.18-jni-policy.author b/patches/0.18-jni-policy.author
new file mode 100644
index 0000000..a2f932c
--- /dev/null
+++ b/patches/0.18-jni-policy.author
@@ -0,0 +1 @@
+From: Ben Burton <bab at debian.org>
diff --git a/patches/0.18-jni-policy.patch b/patches/0.18-jni-policy.patch
new file mode 100644
index 0000000..ae0f053
--- /dev/null
+++ b/patches/0.18-jni-policy.patch
@@ -0,0 +1,52 @@
+--- java-common-0.16/policy.xml 2002-09-26 00:53:03.000000000 +1000
++++ java-common-0.16.1/policy.xml 2003-02-09 23:16:23.000000000 +1100
+@@ -147,6 +147,14 @@
+ virtual machine, you &may; name the compiler package xxxx-dev.
+ </para>
+
++ <para>
++ Some Java classes implement their routines using a "native"
++ language (such as C). This native code is compiled and stored
++ in dynamic libraries (such as JNI modules) that are loaded at
++ runtime. If a virtual machine supports native code, it &must;
++ include the directory <filename>/usr/lib/jni</filename> in its
++ search path for these dynamic libraries.
++ </para>
+ </sect1>
+
+ <sect1 id="policy-compiler">
+@@ -245,18 +253,27 @@
+ This applies only to libraries, <emphasis>not</emphasis> to the core
+ classes provied by a the runtime environment.
+ </para>
+-
++
++ <para>
++ Some Java libraries rely on code written in a "native" language,
++ such as JNI (Java Native Interface) code. This native code is
++ compiled into separate dynamic libraries which are loaded by the
++ Java virtual machine at runtime.
++ </para>
++
+ <para>
+- If the Java code depends on code written in a "native" language,
+- for example Java Native Interface code, the compiled native code
+- &should; be shipped in a separate architecture-specific package
+- named libXXX[version]-jni. The package containing Java bytecode
+- &should; depend on this package.
++ If a Java library relies on native code, the dynamic libraries
++ containing this compiled native code &should; be installed into
++ the directory <filename>/usr/lib/jni</filename>. These dynamic
++ libraries &should; be shipped in a separate architecture-specific
++ package named libXXX[version]-jni. The package containing the Java
++ bytecode (generally libXXX[version]-java) &should; depend on
++ this package.
+ </para>
+ <para>
+ There may be situations, such as with very small packages,
+ where it is better to bundle the Java code and the native code
+- together into a single package. Such packages should be
++ together into a single package. Such packages &should; be
+ architecture-specific and follow the usual libXXX[version]-java
+ naming convention.
+ </para>
diff --git a/policy.xml b/policy.xml
index 573ca9a..d803235 100644
--- a/policy.xml
+++ b/policy.xml
@@ -157,6 +157,14 @@
virtual machine, you &may; name the compiler package xxxx-dev.
</para>
+ <para>
+ Some Java classes implement their routines using a "native"
+ language (such as C). This native code is compiled and stored
+ in dynamic libraries (such as JNI modules) that are loaded at
+ runtime. If a virtual machine supports native code, it &must;
+ include the directory <filename>/usr/lib/jni</filename> in its
+ search path for these dynamic libraries.
+ </para>
</sect1>
<sect1 id="policy-compiler">
@@ -255,18 +263,27 @@
This applies only to libraries, <emphasis>not</emphasis> to the core
classes provied by a the runtime environment.
</para>
-
+
+ <para>
+ Some Java libraries rely on code written in a "native" language,
+ such as JNI (Java Native Interface) code. This native code is
+ compiled into separate dynamic libraries which are loaded by the
+ Java virtual machine at runtime.
+ </para>
+
<para>
- If the Java code depends on code written in a "native" language,
- for example Java Native Interface code, the compiled native code
- &should; be shipped in a separate architecture-specific package
- named libXXX[version]-jni. The package containing Java bytecode
- &should; depend on this package.
+ If a Java library relies on native code, the dynamic libraries
+ containing this compiled native code &should; be installed into
+ the directory <filename>/usr/lib/jni</filename>. These dynamic
+ libraries &should; be shipped in a separate architecture-specific
+ package named libXXX[version]-jni. The package containing the Java
+ bytecode (generally libXXX[version]-java) &should; depend on
+ this package.
</para>
<para>
There may be situations, such as with very small packages,
where it is better to bundle the Java code and the native code
- together into a single package. Such packages should be
+ together into a single package. Such packages &should; be
architecture-specific and follow the usual libXXX[version]-java
naming convention.
</para>
@@ -293,8 +310,10 @@
<listitem>
<para>
If your binary package can run only with non-free
- virtual machines (the only free Java virtual machine seems to be
- kaffe - and the one included in libgcj), it cannot go to main. If
+ virtual machines
+ (<ulink
+ url="http://www.gnu.org/software/classpath">classpath</ulink> has
+ a list of free versions), it cannot go to main. If
your package itself is free, it &must; go to contrib.
</para>
</listitem>
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-java/java-policy.git
More information about the pkg-java-commits
mailing list