summaryrefslogtreecommitdiff
path: root/Doc/Manual/Java.html
diff options
context:
space:
mode:
authorWilliam S Fulton <wsf@fultondesigns.co.uk>2005-11-26 22:46:14 +0000
committerWilliam S Fulton <wsf@fultondesigns.co.uk>2005-11-26 22:46:14 +0000
commit709c840f6af01acda082987b1477a50967274d7b (patch)
tree19242b01bb369fb6bf09705b1ab5440a7b1dfca0 /Doc/Manual/Java.html
parentf736ec91c285f1ac47e0f041fb7c88adb7614dcf (diff)
downloadswig-709c840f6af01acda082987b1477a50967274d7b.tar.gz
Update enum documentation with enums with initialisers, initialising from another enum item.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@7874 626c5289-ae23-0410-ae9c-e8d60b6d4f22
Diffstat (limited to 'Doc/Manual/Java.html')
-rw-r--r--Doc/Manual/Java.html249
1 files changed, 135 insertions, 114 deletions
diff --git a/Doc/Manual/Java.html b/Doc/Manual/Java.html
index f85d08a43..106ad1a97 100644
--- a/Doc/Manual/Java.html
+++ b/Doc/Manual/Java.html
@@ -5,7 +5,7 @@
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body bgcolor="#FFFFFF">
-<H1><a name="Java"></a>21 SWIG and Java</H1>
+<H1><a name="Java"></a>23 SWIG and Java</H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@@ -146,7 +146,7 @@ It covers most SWIG features, but certain low-level details are covered in less
</p>
-<H2><a name="java_overview"></a>21.1 Overview</H2>
+<H2><a name="java_overview"></a>23.1 Overview</H2>
<p>
@@ -181,7 +181,7 @@ Various customisation tips and techniques using SWIG directives are covered.
The latter sections cover the advanced techniques of using typemaps for complete control of the wrapping process.
</p>
-<H2><a name="java_preliminaries"></a>21.2 Preliminaries</H2>
+<H2><a name="java_preliminaries"></a>23.2 Preliminaries</H2>
<p>
@@ -197,7 +197,7 @@ Run <tt>make -k check</tt> from the SWIG root directory after installing SWIG on
The Java module requires your system to support shared libraries and dynamic loading.
This is the commonly used method to load JNI code so your system will more than likely support this.</p>
-<H3><a name="running_swig"></a>21.2.1 Running SWIG</H3>
+<H3><a name="running_swig"></a>23.2.1 Running SWIG</H3>
<p>
@@ -244,7 +244,7 @@ To change this, you can use the <tt>-o</tt> option.
It is also possible to change the <a href="SWIG.html#output">output directory </a> that the Java files are generated into using <tt>-outdir</tt>.
</p>
-<H3><a name="java_commandline"></a>21.2.2 Additional Commandline Options</H3>
+<H3><a name="java_commandline"></a>23.2.2 Additional Commandline Options</H3>
<p>
@@ -276,7 +276,7 @@ swig -java -help
Their use will become clearer by the time you have finished reading this section on SWIG and Java.
</p>
-<H3><a name="getting_right_headers"></a>21.2.3 Getting the right header files</H3>
+<H3><a name="getting_right_headers"></a>23.2.3 Getting the right header files</H3>
<p>
@@ -291,7 +291,7 @@ They are usually in directories like this:</p>
<p>
The exact location may vary on your machine, but the above locations are typical. </p>
-<H3><a name="compiling_dynamic"></a>21.2.4 Compiling a dynamic module</H3>
+<H3><a name="compiling_dynamic"></a>23.2.4 Compiling a dynamic module</H3>
<p>
@@ -319,7 +319,7 @@ The name of the shared library output file is important.
If the name of your SWIG module is "<tt>example</tt>", the name of the corresponding shared library file should be "<tt>libexample.so</tt>" (or equivalent depending on your machine, see <a href="#dynamic_linking_problems">Dynamic linking problems</a> for more information).
The name of the module is specified using the <tt>%module</tt> directive or<tt> -module</tt> command line option.</p>
-<H3><a name="using_module"></a>21.2.5 Using your module</H3>
+<H3><a name="using_module"></a>23.2.5 Using your module</H3>
<p>
@@ -354,7 +354,7 @@ $
If it doesn't work have a look at the following section which discusses problems loading the shared library.
</p>
-<H3><a name="dynamic_linking_problems"></a>21.2.6 Dynamic linking problems</H3>
+<H3><a name="dynamic_linking_problems"></a>23.2.6 Dynamic linking problems</H3>
<p>
@@ -428,7 +428,7 @@ The following section also contains some C++ specific linking problems and solut
</p>
-<H3><a name="compilation_problems_cpp"></a>21.2.7 Compilation problems and compiling with C++</H3>
+<H3><a name="compilation_problems_cpp"></a>23.2.7 Compilation problems and compiling with C++</H3>
<p>
@@ -481,7 +481,7 @@ Finally make sure the version of JDK header files matches the version of Java th
</p>
-<H3><a name="building_windows"></a>21.2.8 Building on Windows</H3>
+<H3><a name="building_windows"></a>23.2.8 Building on Windows</H3>
<p>
@@ -490,7 +490,7 @@ You will want to produce a DLL that can be loaded by the Java Virtual Machine.
This section covers the process of using SWIG with Microsoft Visual C++ 6 although the procedure may be similar with other compilers.
In order for everything to work, you will need to have a JDK installed on your machine in order to read the JNI header files.</p>
-<H4><a name="visual_studio"></a>21.2.8.1 Running SWIG from Visual Studio</H4>
+<H4><a name="visual_studio"></a>23.2.8.1 Running SWIG from Visual Studio</H4>
<p>
@@ -529,7 +529,7 @@ To run the native code in the DLL (example.dll), make sure that it is in your pa
If the library fails to load have a look at <a href="#dynamic_linking_problems">Dynamic linking problems</a>.
</p>
-<H4><a name="nmake"></a>21.2.8.2 Using NMAKE</H4>
+<H4><a name="nmake"></a>23.2.8.2 Using NMAKE</H4>
<p>
@@ -588,7 +588,7 @@ Of course you may want to make changes for it to work for C++ by adding in the -
</p>
-<H2><a name="java_basic_tour"></a>21.3 A tour of basic C/C++ wrapping</H2>
+<H2><a name="java_basic_tour"></a>23.3 A tour of basic C/C++ wrapping</H2>
<p>
@@ -598,7 +598,7 @@ variables are wrapped with JavaBean type getters and setters and so forth.
This section briefly covers the essential aspects of this wrapping.
</p>
-<H3><a name="module_packages_classes"></a>21.3.1 Modules, packages and generated Java classes</H3>
+<H3><a name="module_packages_classes"></a>23.3.1 Modules, packages and generated Java classes</H3>
<p>
@@ -632,7 +632,7 @@ swig -java -package com.bloggs.swig -outdir com/bloggs/swig example.i
SWIG won't create the directory, so make sure it exists beforehand.
-<H3><a name="functions"></a>21.3.2 Functions</H3>
+<H3><a name="functions"></a>23.3.2 Functions</H3>
<p>
@@ -666,7 +666,7 @@ System.out.println(example.fact(4));
</pre></div>
-<H3><a name="global_variables"></a>21.3.3 Global variables</H3>
+<H3><a name="global_variables"></a>23.3.3 Global variables</H3>
<p>
@@ -753,7 +753,7 @@ extern char *path; // Read-only (due to %immutable)
</div>
-<H3><a name="constants"></a>21.3.4 Constants</H3>
+<H3><a name="constants"></a>23.3.4 Constants</H3>
<p>
@@ -885,7 +885,7 @@ Or if you decide this practice isn't so bad and your own class implements <tt>ex
</p>
-<H3><a name="enumerations"></a>21.3.5 Enumerations</H3>
+<H3><a name="enumerations"></a>23.3.5 Enumerations</H3>
<p>
@@ -899,7 +899,7 @@ The final two approaches use simple integers for each enum item.
Before looking at the various approaches for wrapping named C/C++ enums, anonymous enums are considered.
</p>
-<H4><a name="anonymous_enums"></a>21.3.5.1 Anonymous enums</H4>
+<H4><a name="anonymous_enums"></a>23.3.5.1 Anonymous enums</H4>
<p>
@@ -908,7 +908,7 @@ There is no name for anonymous enums and so they are handled like constants. For
<div class="code">
<pre>
-enum { ALE, LAGER=10, STOUT, PILSNER };
+enum { ALE, LAGER=10, STOUT, PILSNER, PILZ=PILSNER };
</pre>
</div>
@@ -922,6 +922,7 @@ public interface exampleConstants {
public final static int LAGER = exampleJNI.LAGER_get();
public final static int STOUT = exampleJNI.STOUT_get();
public final static int PILSNER = exampleJNI.PILSNER_get();
+ public final static int PILZ = exampleJNI.PILZ_get();
}
</pre></div>
@@ -938,7 +939,7 @@ Example usage:
<pre>
%javaconst(1);
%javaconst(0) PILSNER;
-enum { ALE, LAGER=10, STOUT, PILSNER };
+enum { ALE, LAGER=10, STOUT, PILSNER, PILZ=PILSNER };
</pre>
</div>
@@ -950,8 +951,9 @@ generates:
public interface exampleConstants {
public final static int ALE = 0;
public final static int LAGER = 10;
- public final static int STOUT = LAGER+1;
+ public final static int STOUT = LAGER + 1;
public final static int PILSNER = exampleJNI.PILSNER_get();
+ public final static int PILZ = PILSNER;
}
</pre></div>
@@ -960,12 +962,12 @@ As in the case of constants, you can access them through either the module class
</p>
-<H4><a name="typesafe_enums"></a>21.3.5.2 Typesafe enums</H4>
+<H4><a name="typesafe_enums"></a>23.3.5.2 Typesafe enums</H4>
<p>
This is the default approach to wrapping named enums.
-The typesafe enum pattern is a relatively well known construct to work around the lack of enums in versions of Java prior to Java 2 SDK 1.5.
+The typesafe enum pattern is a relatively well known construct to work around the lack of enums in versions of Java prior to JDK 1.5.
It basically defines a class for the enumeration and permits a limited number of final static instances of the class.
Each instance equates to an enum item within the enumeration.
The implementation is in the "enumtypesafe.swg" file.
@@ -975,7 +977,7 @@ Let's look at an example:
<div class="code">
<pre>
%include "enumtypesafe.swg" // optional as typesafe enums are the default
-enum Beverage { ALE, LAGER=10, STOUT, PILSNER };
+enum Beverage { ALE, LAGER=10, STOUT, PILSNER, PILZ=PILSNER };
</pre>
</div>
@@ -988,6 +990,7 @@ public final class Beverage {
public final static Beverage LAGER = new Beverage("LAGER", exampleJNI.LAGER_get());
public final static Beverage STOUT = new Beverage("STOUT");
public final static Beverage PILSNER = new Beverage("PILSNER");
+ public final static Beverage PILZ = new Beverage("PILZ", exampleJNI.PILZ_get());
[... additional support methods omitted for brevity ...]
}
</pre>
@@ -1003,7 +1006,7 @@ However, as with anonymous enums and constants, use of the <tt>%javaconst</tt> d
<pre>
%include "enumtypesafe.swg" // optional as typesafe enums are the default
%javaconst(1);
-enum Beverage { ALE, LAGER=10, STOUT, PILSNER };
+enum Beverage { ALE, LAGER=10, STOUT, PILSNER, PILZ=PILSNER };
</pre>
</div>
@@ -1018,6 +1021,7 @@ public final class Beverage {
public final static Beverage LAGER = new Beverage("LAGER", 10);
public final static Beverage STOUT = new Beverage("STOUT");
public final static Beverage PILSNER = new Beverage("PILSNER");
+ public final static Beverage PILZ = new Beverage("PILZ", PILSNER);
[... additional support methods omitted for brevity ...]
}
</pre>
@@ -1047,15 +1051,15 @@ Please look at the following references for further information:
<p>
Note that the syntax required for using typesafe enums is the same as that for proper Java enums.
This is useful during the period that a project has to support legacy versions of Java.
-When upgrading to J2SDK 1.5 or later, proper Java enums could be used instead, without users having to change their code.
+When upgrading to JDK 1.5 or later, proper Java enums could be used instead, without users having to change their code.
The following section details proper Java enum generation.
</p>
-<H4><a name="proper_enums"></a>21.3.5.3 Proper Java enums</H4>
+<H4><a name="proper_enums"></a>23.3.5.3 Proper Java enums</H4>
<p>
-Proper Java enums were only introduced in Java 2 SDK 1.5 so this approach is only compatible with more recent versions of Java.
+Proper Java enums were only introduced in JDK 1.5 so this approach is only compatible with more recent versions of Java.
Java enums have been designed to overcome all the limitations of both typesafe and type unsafe enums
and should be the choice solution, provided older versions of Java do not have to be supported.
In this approach, each named C/C++ enum is wrapped by a Java enum.
@@ -1070,7 +1074,7 @@ Let's take a look at an example.
<pre>
%include "enums.swg"
%javaconst(1);
-enum Beverage { ALE, LAGER=10, STOUT, PILSNER };
+enum Beverage { ALE, LAGER=10, STOUT, PILSNER, PILZ=PILSNER };
</pre>
</div>
@@ -1084,7 +1088,8 @@ public enum Beverage {
ALE,
LAGER(10),
STOUT,
- PILSNER;
+ PILSNER,
+ PILZ(PILSNER);
[... additional support methods omitted for brevity ...]
}
</pre>
@@ -1103,7 +1108,7 @@ The additional support methods need not be generated if none of the enum items h
<a href="#simpler_enum_classes">Simpler Java enums for enums without initializers</a> section.
</p>
-<H4><a name="typeunsafe_enums"></a>21.3.5.4 Type unsafe enums</H4>
+<H4><a name="typeunsafe_enums"></a>23.3.5.4 Type unsafe enums</H4>
<p>
@@ -1118,7 +1123,7 @@ Let's take a look at an example.
<pre>
%include "enumtypeunsafe.swg"
%javaconst(1);
-enum Beverage { ALE, LAGER=10, STOUT, PILSNER };
+enum Beverage { ALE, LAGER=10, STOUT, PILSNER, PILZ=PILSNER };
</pre>
</div>
@@ -1133,6 +1138,7 @@ public final class Beverage {
public final static int LAGER = 10;
public final static int STOUT = LAGER + 1;
public final static int PILSNER = STOUT + 1;
+ public final static int PILZ = PILSNER;
}
</pre>
</div>
@@ -1147,10 +1153,10 @@ C++ enums defined within a C++ class are generated into a static final inner Jav
<p>
Note that unlike typesafe enums, this approach requires users to mostly use different syntax compared with proper Java enums.
-Thus the upgrade path to proper enums provided in J2SDK 1.5 is more painful.
+Thus the upgrade path to proper enums provided in JDK 1.5 is more painful.
</p>
-<H4><a name="simple_enums"></a>21.3.5.5 Simple enums</H4>
+<H4><a name="simple_enums"></a>23.3.5.5 Simple enums</H4>
<p>
@@ -1169,7 +1175,7 @@ SWIG-1.3.21 and earlier versions wrapped all enums using this approach.
The type unsafe approach is preferable to this one and this simple approach is only included for backwards compatibility with these earlier versions of SWIG.
</p>
-<H3><a name="pointers"></a>21.3.6 Pointers</H3>
+<H3><a name="pointers"></a>23.3.6 Pointers</H3>
<p>
@@ -1257,7 +1263,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return
a NULL pointer if the conversion can't be performed.
</p>
-<H3><a name="structures"></a>21.3.7 Structures</H3>
+<H3><a name="structures"></a>23.3.7 Structures</H3>
<p>
@@ -1425,7 +1431,7 @@ x.setA(3); // Modify x.a - this is the same as b.f.a
</div>
-<H3><a name="classes"></a>21.3.8 C++ classes</H3>
+<H3><a name="classes"></a>23.3.8 C++ classes</H3>
<p>
@@ -1488,7 +1494,7 @@ int bar = Spam.getBar();
</div>
-<H3><a name="inheritance"></a>21.3.9 C++ inheritance</H3>
+<H3><a name="inheritance"></a>23.3.9 C++ inheritance</H3>
<p>
@@ -1549,7 +1555,7 @@ Note that Java does not support multiple inheritance so any multiple inheritance
A warning is given when multiple inheritance is detected and only the first base class is used.
</p>
-<H3><a name="pointers_refs_arrays"></a>21.3.10 Pointers, references, arrays and pass by value</H3>
+<H3><a name="pointers_refs_arrays"></a>23.3.10 Pointers, references, arrays and pass by value</H3>
<p>
@@ -1604,7 +1610,7 @@ to hold the result and a pointer is returned (Java will release this memory
when the returned object's finalizer is run by the garbage collector).
</p>
-<H4><a name="null_pointers"></a>21.3.10.1 Null pointers</H4>
+<H4><a name="null_pointers"></a>23.3.10.1 Null pointers</H4>
<p>
@@ -1628,7 +1634,7 @@ For <tt>spam1</tt> and <tt>spam4</tt> above the Java <tt>null</tt> gets translat
The converse also occurs, that is, NULL pointers are translated into <tt>null</tt> Java objects when returned from a C/C++ function.
</p>
-<H3><a name="overloaded_functions"></a>21.3.11 C++ overloaded functions</H3>
+<H3><a name="overloaded_functions"></a>23.3.11 C++ overloaded functions</H3>
<p>
@@ -1743,7 +1749,7 @@ void spam(short); // Ignored
</pre>
</div>
-<H3><a name="java_default_arguments"></a>21.3.12 C++ default arguments</H3>
+<H3><a name="java_default_arguments"></a>23.3.12 C++ default arguments</H3>
<p>
@@ -1786,7 +1792,7 @@ Further details on default arguments and how to restore this approach are given
</p>
-<H3><a name="namespaces"></a>21.3.13 C++ namespaces</H3>
+<H3><a name="namespaces"></a>23.3.13 C++ namespaces</H3>
<p>
@@ -1846,7 +1852,7 @@ symbols separate, consider wrapping them as separate SWIG modules.
Each SWIG module can be placed into a separate package.
</p>
-<H3><a name="templates"></a>21.3.14 C++ templates</H3>
+<H3><a name="templates"></a>23.3.14 C++ templates</H3>
<p>
@@ -1895,7 +1901,7 @@ Obviously, there is more to template wrapping than shown in this example.
More details can be found in the <a href="SWIGPlus.html#SWIGPlus">SWIG and C++</a> chapter.
</p>
-<H3><a name="smart_pointers"></a>21.3.15 C++ Smart Pointers</H3>
+<H3><a name="smart_pointers"></a>23.3.15 C++ Smart Pointers</H3>
<p>
@@ -1979,7 +1985,7 @@ Foo f = p.__deref__(); // Returns underlying Foo *
</pre>
</div>
-<H2><a name="further_details"></a>21.4 Further details on the generated Java classes</H2>
+<H2><a name="further_details"></a>23.4 Further details on the generated Java classes</H2>
<p>
@@ -1994,7 +2000,7 @@ Finally enum classes are covered.
First, the crucial intermediary JNI class is considered.
</p>
-<H3><a name="imclass"></a>21.4.1 The intermediary JNI class</H3>
+<H3><a name="imclass"></a>23.4.1 The intermediary JNI class</H3>
<p>
@@ -2107,7 +2113,7 @@ If <tt>name</tt> is the same as <tt>modulename</tt> then the module class name g
from <tt>modulename</tt> to <tt>modulenameModule</tt>.
</p>
-<H4><a name="imclass_pragmas"></a>21.4.1.1 The intermediary JNI class pragmas</H4>
+<H4><a name="imclass_pragmas"></a>23.4.1.1 The intermediary JNI class pragmas</H4>
<p>
@@ -2186,7 +2192,7 @@ For example, let's change the intermediary JNI class access to public.
All the methods in the intermediary JNI class will then be callable outside of the package as the method modifiers are public by default.
</p>
-<H3><a name="java_module_class"></a>21.4.2 The Java module class</H3>
+<H3><a name="java_module_class"></a>23.4.2 The Java module class</H3>
<p>
@@ -2217,7 +2223,7 @@ example.egg(new Foo());
The primary reason for having the module class wrapping the calls in the intermediary JNI class is to implement static type checking. In this case only a <tt>Foo</tt> can be passed to the <tt>egg</tt> function, whereas any <tt>long</tt> can be passed to the <tt>egg</tt> function in the intermediary JNI class.
</p>
-<H4><a name="module_class_pragmas"></a>21.4.2.1 The Java module class pragmas</H4>
+<H4><a name="module_class_pragmas"></a>23.4.2.1 The Java module class pragmas</H4>
<p>
@@ -2268,7 +2274,7 @@ See <a href="#imclass_pragmas">The intermediary JNI class pragmas</a> section fo
</p>
-<H3><a name="java_proxy_classes"></a>21.4.3 Java proxy classes</H3>
+<H3><a name="java_proxy_classes"></a>23.4.3 Java proxy classes</H3>
<p>
@@ -2342,7 +2348,7 @@ int y = f.spam(5, new Foo());
</pre>
</div>
-<H4><a name="memory_management"></a>21.4.3.1 Memory management</H4>
+<H4><a name="memory_management"></a>23.4.3.1 Memory management</H4>
<p>
@@ -2504,7 +2510,7 @@ and
</p>
-<H4><a name="inheritance_mirroring"></a>21.4.3.2 Inheritance</H4>
+<H4><a name="inheritance_mirroring"></a>23.4.3.2 Inheritance</H4>
<p>
@@ -2618,7 +2624,7 @@ However, true cross language polymorphism can be achieved using the <a href="#ja
</p>
-<H4><a name="proxy_classes_gc"></a>21.4.3.3 Proxy classes and garbage collection</H4>
+<H4><a name="proxy_classes_gc"></a>23.4.3.3 Proxy classes and garbage collection</H4>
<p>
@@ -2695,7 +2701,7 @@ The section on <a href="#java_typemaps">Java typemaps</a> details how to specify
</li>
</ol>
-<H3><a name="type_wrapper_classes"></a>21.4.4 Type wrapper classes</H3>
+<H3><a name="type_wrapper_classes"></a>23.4.4 Type wrapper classes</H3>
<p>
@@ -2782,7 +2788,7 @@ public static void spam(SWIGTYPE_p_int x, SWIGTYPE_p_int y, int z) { ... }
</div>
-<H3><a name="enum_classes"></a>21.4.5 Enum classes</H3>
+<H3><a name="enum_classes"></a>23.4.5 Enum classes</H3>
<p>
@@ -2791,7 +2797,7 @@ The <a href="#enumerations">Enumerations</a> section discussed these but omitted
The following sub-sections detail the various types of enum classes that can be generated.
</p>
-<H4><a name="typesafe_enums_classes"></a>21.4.5.1 Typesafe enum classes</H4>
+<H4><a name="typesafe_enums_classes"></a>23.4.5.1 Typesafe enum classes</H4>
<p>
@@ -2802,12 +2808,12 @@ The following example demonstrates the typesafe enum classes which SWIG generate
<pre>
%include "enumtypesafe.swg"
%javaconst(1);
-enum Beverage { ALE, LAGER=10, STOUT, PILSNER };
+enum Beverage { ALE, LAGER=10, STOUT, PILSNER, PILZ=PILSNER };
</pre>
</div>
<p>
-The following is what SWIG generates:
+The following is the code that SWIG generates:
</p>
<div class="code">
@@ -2817,6 +2823,7 @@ public final class Beverage {
public final static Beverage LAGER = new Beverage("LAGER", 10);
public final static Beverage STOUT = new Beverage("STOUT");
public final static Beverage PILSNER = new Beverage("PILSNER");
+ public final static Beverage PILZ = new Beverage("PILZ", PILSNER);
public final int swigValue() {
return swigValue;
@@ -2848,7 +2855,13 @@ public final class Beverage {
swigNext = swigValue+1;
}
- private static Beverage[] swigValues = { ALE, LAGER, STOUT, PILSNER };
+ private Beverage(String swigName, Beverage swigEnum) {
+ this.swigName = swigName;
+ this.swigValue = swigEnum.swigValue;
+ swigNext = this.swigValue+1;
+ }
+
+ private static Beverage[] swigValues = { ALE, LAGER, STOUT, PILSNER, PILZ };
private static int swigNext = 0;
private final int swigValue;
private final String swigName;
@@ -2857,17 +2870,18 @@ public final class Beverage {
</div>
<p>
-As can be seen, there a fair number of support methods for the typesafe enum pattern.
+As can be seen, there are a fair number of support methods for the typesafe enum pattern.
The typesafe enum pattern involves creating a fixed number of static instances of the enum class.
The constructors are private to enforce this.
-Two constructors are available - one for C/C++ enums with an initializer and one for those without an initializer.
+Three constructors are available - two for C/C++ enums with an initializer and one for those without an initializer.
+Note that the two enums with initializers, <tt>LAGER</tt> and <tt>PILZ</tt>, each call one the two different initializer constructors.
In order to use one of these typesafe enums, the <tt>swigToEnum</tt> static method must be called to return a reference to one of the static instances.
The JNI layer returns the enum value from the C/C++ world as an integer and this method is used to find the appropriate Java enum static instance.
The <tt>swigValue</tt> method is used for marshalling in the other direction.
The <tt>toString</tt> method is overridden so that the enum name is available.
</p>
-<H4><a name="proper_enums_classes"></a>21.4.5.2 Proper Java enum classes</H4>
+<H4><a name="proper_enums_classes"></a>23.4.5.2 Proper Java enum classes</H4>
<p>
@@ -2878,7 +2892,7 @@ The following example demonstrates the Java enums approach:
<pre>
%include "enums.swg"
%javaconst(1);
-enum Beverage { ALE, LAGER=10, STOUT, PILSNER };
+enum Beverage { ALE, LAGER=10, STOUT, PILSNER, PILZ=PILSNER };
</pre>
</div>
@@ -2892,7 +2906,8 @@ public enum Beverage {
ALE,
LAGER(10),
STOUT,
- PILSNER;
+ PILSNER,
+ PILZ(PILSNER);
public final int swigValue() {
return swigValue;
@@ -2919,6 +2934,11 @@ public enum Beverage {
SwigNext.next = swigValue+1;
}
+ private Beverage(Beverage swigEnum) {
+ this.swigValue = swigEnum.swigValue;
+ SwigNext.next = this.swigValue+1;
+ }
+
private final int swigValue;
private static class SwigNext {
@@ -2939,7 +2959,7 @@ These needn't be generated if the enum being wrapped does not have any initializ
<a href="#simpler_enum_classes">Simpler Java enums for enums without initializers</a> section describes how typemaps can be used to achieve this.
</p>
-<H4><a name="typeunsafe_enums_classes"></a>21.4.5.3 Type unsafe enum classes</H4>
+<H4><a name="typeunsafe_enums_classes"></a>23.4.5.3 Type unsafe enum classes</H4>
<p>
@@ -2950,7 +2970,7 @@ The following example demonstrates type unsafe enums:
<pre>
%include "enumtypeunsafe.swg"
%javaconst(1);
-enum Beverage { ALE, LAGER=10, STOUT, PILSNER };
+enum Beverage { ALE, LAGER=10, STOUT, PILSNER, PILZ=PILSNER };
</pre>
</div>
@@ -2965,11 +2985,12 @@ public final class Beverage {
public final static int LAGER = 10;
public final static int STOUT = LAGER + 1;
public final static int PILSNER = STOUT + 1;
+ public final static int PILZ = PILSNER;
}
</pre>
</div>
-<H2><a name="java_directors"></a>21.5 Cross language polymorphism using directors (experimental)</H2>
+<H2><a name="java_directors"></a>23.5 Cross language polymorphism using directors (experimental)</H2>
<p>
@@ -2991,7 +3012,7 @@ The upshot is that C++ classes can be extended in Java and from C++ these extens
Neither C++ code nor Java code needs to know where a particular method is implemented: the combination of proxy classes, director classes, and C wrapper functions transparently takes care of all the cross-language method routing.
</p>
-<H3><a name="java_enabling_directors"></a>21.5.1 Enabling directors</H3>
+<H3><a name="java_enabling_directors"></a>23.5.1 Enabling directors</H3>
<p>
@@ -3062,7 +3083,7 @@ public:
</pre>
</div>
-<H3><a name="java_directors_classes"></a>21.5.2 Director classes</H3>
+<H3><a name="java_directors_classes"></a>23.5.2 Director classes</H3>
<p>
@@ -3089,7 +3110,7 @@ If the correct implementation is in Java, the Java API is used to call the metho
</p>
-<H3><a name="java_directors_overhead"></a>21.5.3 Overhead and code bloat</H3>
+<H3><a name="java_directors_overhead"></a>23.5.3 Overhead and code bloat</H3>
<p>
@@ -3107,7 +3128,7 @@ This situation can be optimized by selectively enabling director methods (using
</p>
-<H3><a name="java_directors_example"></a>21.5.4 Simple directors example</H3>
+<H3><a name="java_directors_example"></a>23.5.4 Simple directors example</H3>
<p>
@@ -3172,7 +3193,7 @@ directorDerived::upcall_method() invoked.
</pre>
</div>
-<H2><a name="common_customization"></a>21.6 Common customization features</H2>
+<H2><a name="common_customization"></a>23.6 Common customization features</H2>
<p>
@@ -3184,7 +3205,7 @@ be awkward. This section describes some common SWIG features that are used
to improve the interface to existing C/C++ code.
</p>
-<H3><a name="helper_functions"></a>21.6.1 C/C++ helper functions</H3>
+<H3><a name="helper_functions"></a>23.6.1 C/C++ helper functions</H3>
<p>
@@ -3250,7 +3271,7 @@ hard to implement. It is possible to improve on this using Java code, typemaps,
customization features as covered in later sections, but sometimes helper functions are a quick and easy solution to difficult cases.
</p>
-<H3><a name="class_extension"></a>21.6.2 Class extension with %extend</H3>
+<H3><a name="class_extension"></a>23.6.2 Class extension with %extend</H3>
<p>
@@ -3313,7 +3334,7 @@ Vector(2,3,4)
in any way---the extensions only show up in the Java interface.
</p>
-<H3><a name="exception_handling"></a>21.6.3 Exception handling with %exception and %javaexception</H3>
+<H3><a name="exception_handling"></a>23.6.3 Exception handling with %exception and %javaexception</H3>
<p>
@@ -3470,7 +3491,7 @@ to raise exceptions. See the <a href="Library.html#Library">SWIG Library</a> ch
The typemap example <a href="#exception_typemap">Handling C++ exception specifications as Java exceptions</a> provides further exception handling capabilities.
</p>
-<H3><a name="method_access"></a>21.6.4 Method access with %javamethodmodifiers</H3>
+<H3><a name="method_access"></a>23.6.4 Method access with %javamethodmodifiers</H3>
<p>
@@ -3496,7 +3517,7 @@ protected static void protect_me() {
</pre>
</div>
-<H2><a name="tips_techniques"></a>21.7 Tips and techniques</H2>
+<H2><a name="tips_techniques"></a>23.7 Tips and techniques</H2>
<p>
@@ -3506,7 +3527,7 @@ strings and arrays. This chapter discusses the common techniques for
solving these problems.
</p>
-<H3><a name="input_output_parameters"></a>21.7.1 Input and output parameters using primitive pointers and references</H3>
+<H3><a name="input_output_parameters"></a>23.7.1 Input and output parameters using primitive pointers and references</H3>
<p>
@@ -3680,7 +3701,7 @@ void foo(Bar *OUTPUT);
will not have the intended effect since <tt>typemaps.i</tt> does not define an OUTPUT rule for <tt>Bar</tt>.
</p>
-<H3><a name="simple_pointers"></a>21.7.2 Simple pointers</H3>
+<H3><a name="simple_pointers"></a>23.7.2 Simple pointers</H3>
<p>
@@ -3746,7 +3767,7 @@ System.out.println("3 + 4 = " + result);
See the <a href="Library.html#Library">SWIG Library</a> chapter for further details.
</p>
-<H3><a name="c_arrays"></a>21.7.3 Wrapping C arrays with Java arrays</H3>
+<H3><a name="c_arrays"></a>23.7.3 Wrapping C arrays with Java arrays</H3>
<p>
@@ -3813,7 +3834,7 @@ Please be aware that the typemaps in this library are not efficient as all the e
There is an alternative approach using the SWIG array library and this is covered in the next section.
</p>
-<H3><a name="unbounded_c_arrays"></a>21.7.4 Unbounded C Arrays</H3>
+<H3><a name="unbounded_c_arrays"></a>23.7.4 Unbounded C Arrays</H3>
<p>
@@ -3958,7 +3979,7 @@ well suited for applications in which you need to create buffers,
package binary data, etc.
</p>
-<H2><a name="java_typemaps"></a>21.8 Java typemaps</H2>
+<H2><a name="java_typemaps"></a>23.8 Java typemaps</H2>
<p>
@@ -3979,7 +4000,7 @@ Before proceeding, it should be stressed that typemaps are not a required
part of using SWIG---the default wrapping behavior is enough in most cases.
Typemaps are only used if you want to change some aspect of the generated code.
-<H3><a name="default_primitive_type_mappings"></a>21.8.1 Default primitive type mappings</H3>
+<H3><a name="default_primitive_type_mappings"></a>23.8.1 Default primitive type mappings</H3>
<p>
@@ -4130,7 +4151,7 @@ There is no perfect mapping between Java and C as Java doesn't support all the u
However, the mappings allow the full range of values for each C type from Java.
</p>
-<H3><a name="jvm64"></a>21.8.2 Sixty four bit JVMs</H3>
+<H3><a name="jvm64"></a>23.8.2 Sixty four bit JVMs</H3>
<p>
@@ -4143,7 +4164,7 @@ Unfortunately it won't of course hold true for JNI code.
</p>
-<H3><a name="what_is_typemap"></a>21.8.3 What is a typemap?</H3>
+<H3><a name="what_is_typemap"></a>23.8.3 What is a typemap?</H3>
<p>
@@ -4266,7 +4287,7 @@ int c = example.count('e',"Hello World");
</pre>
</div>
-<H3><a name="typemaps_c_to_java_types"></a>21.8.4 Typemaps for mapping C/C++ types to Java types</H3>
+<H3><a name="typemaps_c_to_java_types"></a>23.8.4 Typemaps for mapping C/C++ types to Java types</H3>
<p>
@@ -4456,7 +4477,7 @@ These are listed below:
</table>
-<H3><a name="typemap_attributes"></a>21.8.5 Java typemap attributes</H3>
+<H3><a name="typemap_attributes"></a>23.8.5 Java typemap attributes</H3>
<p>
@@ -4486,7 +4507,7 @@ the union of the exception classes is added to the throws clause ensuring there
See the <a href="#nan_exception_typemap">NaN exception example</a> for further usage.
</p>
-<H3><a name="special_variables"></a>21.8.6 Java special variables</H3>
+<H3><a name="special_variables"></a>23.8.6 Java special variables</H3>
<p>
@@ -4621,7 +4642,7 @@ This special variable expands to the module name, as specified by <tt>%module</t
Useful for constructing the intermediary classname, which is just <tt>$moduleJNI</tt>.
</p>
-<H3><a name="typemaps_for_c_and_c++"></a>21.8.7 Typemaps for both C and C++ compilation</H3>
+<H3><a name="typemaps_for_c_and_c++"></a>23.8.7 Typemaps for both C and C++ compilation</H3>
<p>
@@ -4658,7 +4679,7 @@ If you do not intend your code to be targeting both C and C++ then your typemaps
</p>
-<H3><a name="java_code_typemaps"></a>21.8.8 Java code typemaps</H3>
+<H3><a name="java_code_typemaps"></a>23.8.8 Java code typemaps</H3>
<p>
@@ -4848,7 +4869,7 @@ For the typemap to be used in all type wrapper classes, all the different types
Again this is the same that is in "<tt>java.swg</tt>", barring the method modifier for <tt>getCPtr</tt>.
</p>
-<H3><a name="java_directors_typemaps"></a>21.8.9 Director specific typemaps</H3>
+<H3><a name="java_directors_typemaps"></a>23.8.9 Director specific typemaps</H3>
<p>
@@ -5038,7 +5059,7 @@ The basic strategy here is to provide a default package typemap for the majority
</div>
-<H2><a name="typemap_examples"></a>21.9 Typemap Examples</H2>
+<H2><a name="typemap_examples"></a>23.9 Typemap Examples</H2>
<p>
@@ -5048,7 +5069,7 @@ the SWIG library.
</p>
-<H3><a name="simpler_enum_classes"></a>21.9.1 Simpler Java enums for enums without initializers</H3>
+<H3><a name="simpler_enum_classes"></a>23.9.1 Simpler Java enums for enums without initializers</H3>
<p>
@@ -5127,7 +5148,7 @@ This would be done by using the original versions of these typemaps in "enums.sw
</p>
-<H3><a name="exception_typemap"></a>21.9.2 Handling C++ exception specifications as Java exceptions</H3>
+<H3><a name="exception_typemap"></a>23.9.2 Handling C++ exception specifications as Java exceptions</H3>
<p>
@@ -5252,7 +5273,7 @@ We could alternatively have used <tt>%rename</tt> to rename <tt>what()</tt> into
</p>
-<H3><a name="nan_exception_typemap"></a>21.9.3 NaN Exception - exception handling for a particular type</H3>
+<H3><a name="nan_exception_typemap"></a>23.9.3 NaN Exception - exception handling for a particular type</H3>
<p>
@@ -5370,7 +5391,7 @@ If we were a martyr to the JNI cause, we could replace the succinct code within
If we had, we would have put it in the "in" typemap which, like all JNI and Java typemaps, also supports the 'throws' attribute.
</p>
-<H3><a name="converting_java_string_arrays"></a>21.9.4 Converting Java String arrays to char ** </H3>
+<H3><a name="converting_java_string_arrays"></a>23.9.4 Converting Java String arrays to char ** </H3>
<p>
@@ -5514,7 +5535,7 @@ Lastly the "jni", "jtype" and "jstype" typemaps are also required to specify
what Java types to use.
</p>
-<H3><a name="expanding_java_object"></a>21.9.5 Expanding a Java object to multiple arguments</H3>
+<H3><a name="expanding_java_object"></a>23.9.5 Expanding a Java object to multiple arguments</H3>
<p>
@@ -5596,7 +5617,7 @@ example.foo(new String[]{"red", "green", "blue", "white"});
</div>
-<H3><a name="using_typemaps_return_arguments"></a>21.9.6 Using typemaps to return arguments</H3>
+<H3><a name="using_typemaps_return_arguments"></a>23.9.6 Using typemaps to return arguments</H3>
<p>
@@ -5714,7 +5735,7 @@ $ java main
1 12.0 340.0
</pre></div>
-<H3><a name="adding_downcasts"></a>21.9.7 Adding Java downcasts to polymorphic return types</H3>
+<H3><a name="adding_downcasts"></a>23.9.7 Adding Java downcasts to polymorphic return types</H3>
<p>
@@ -5920,7 +5941,7 @@ SWIG usually generates code which constructs the proxy classes using Java code a
Note that the JNI code above uses a number of string lookups to call a constructor, whereas this would not occur using byte compiled Java code.
</p>
-<H3><a name="adding_equals_method"></a>21.9.8 Adding an equals method to the Java classes</H3>
+<H3><a name="adding_equals_method"></a>23.9.8 Adding an equals method to the Java classes</H3>
<p>
@@ -5959,7 +5980,7 @@ System.out.println("foo1? " + foo1.equals(foo2));
</div>
-<H3><a name="void_pointers"></a>21.9.9 Void pointers and a common Java base class</H3>
+<H3><a name="void_pointers"></a>23.9.9 Void pointers and a common Java base class</H3>
<p>
@@ -6018,7 +6039,7 @@ This example contains some useful functionality which you may want in your code.
<li> It also has a function which effectively implements a cast from the type of the proxy/type wrapper class to a void pointer. This is necessary for passing a proxy class or a type wrapper class to a function that takes a void pointer.
</ul>
-<H3><a name="struct_pointer_pointer"></a>21.9.10 Struct pointer to pointer</H3>
+<H3><a name="struct_pointer_pointer"></a>23.9.10 Struct pointer to pointer</H3>
<p>
@@ -6190,7 +6211,7 @@ The C functional interface has been completely morphed into an object-oriented i
the Butler class would behave much like any pure Java class and feel more natural to Java users.
</p>
-<H3><a name="java_memory_management_member_variables"></a>21.9.11 Memory management when returning references to member variables</H3>
+<H3><a name="java_memory_management_member_variables"></a>23.9.11 Memory management when returning references to member variables</H3>
<p>
@@ -6313,7 +6334,7 @@ public class Bike {
Note the <tt>addReference</tt> call.
</p>
-<H3><a name="java_memory_management_objects"></a>21.9.12 Memory management for objects passed to the C++ layer</H3>
+<H3><a name="java_memory_management_objects"></a>23.9.12 Memory management for objects passed to the C++ layer</H3>
<p>
@@ -6430,7 +6451,7 @@ The 'javacode' typemap simply adds in the specified code into the Java proxy cla
-<H2><a name="java_directors_faq"></a>21.10 Living with Java Directors</H2>
+<H2><a name="java_directors_faq"></a>23.10 Living with Java Directors</H2>
<p>
@@ -6611,10 +6632,10 @@ public abstract class UserVisibleFoo extends Foo {
</li>
</ol>
-<H2><a name="odds_ends"></a>21.11 Odds and ends</H2>
+<H2><a name="odds_ends"></a>23.11 Odds and ends</H2>
-<H3><a name="javadoc_comments"></a>21.11.1 JavaDoc comments</H3>
+<H3><a name="javadoc_comments"></a>23.11.1 JavaDoc comments</H3>
<p>
@@ -6670,7 +6691,7 @@ public class Barmy {
-<H3><a name="functional_interface"></a>21.11.2 Functional interface without proxy classes</H3>
+<H3><a name="functional_interface"></a>23.11.2 Functional interface without proxy classes</H3>
<p>
@@ -6731,7 +6752,7 @@ All destructors have to be called manually for example the <tt>delete_Foo(foo)</
</p>
-<H3><a name="using_own_jni_functions"></a>21.11.3 Using your own JNI functions</H3>
+<H3><a name="using_own_jni_functions"></a>23.11.3 Using your own JNI functions</H3>
<p>
@@ -6781,7 +6802,7 @@ This directive is only really useful if you want to mix your own hand crafted JN
</p>
-<H3><a name="performance"></a>21.11.4 Performance concerns and hints</H3>
+<H3><a name="performance"></a>23.11.4 Performance concerns and hints</H3>
<p>
@@ -6803,7 +6824,7 @@ This method normally calls the C++ destructor or <tt>free()</tt> for C code.
</p>
-<H2><a name="java_examples"></a>21.12 Examples</H2>
+<H2><a name="java_examples"></a>23.12 Examples</H2>
<p>
View Lorry Controller Status