-
Notifications
You must be signed in to change notification settings - Fork 19
/
Copy pathNEWS
125 lines (90 loc) · 4.9 KB
/
NEWS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
20/10 -- 2018:
Array can be initialized either using:
{{array, Type, Dimensions}, Values} or
{{array, Type}, Values},
Dimensions is a positive integer indicating the number of
dimensions of the array,
and Values can either a tuple of items, or a list of items.
Example: {{array,'int',2},{{1},{2}}}, {{array,'int',2},{}},
{{array,'int',2},{{1}}},
and {{array,'int'},{{1},{2}}}.
Empty arrays can be created using:
{{array_empty, Type, Sizes},null} where
Size is a tuple of positive integers indicating the
sizes (and overall dimension) of the resulting array.
An example: {{array, 'int, {1,2}},null}.
25/10 -- 2018:
A couple of updates to manage situations where the Java node cannot be
started by calling the main method (i.e., by starting a new Java runtime),
but should rather be integrated into an existing Java runtime.
There are two new (Java) methods:
- receiveConnection(Level logLevel, String name, String cookie, boolean returnOtpErlangObject)
- reportAndReceiveConnection(Level logLevel, String ourName, String otherNode, String reportName, String cookie, boolean returnOtpErlangObject)
The first method waits for the Erlang side to initiate a connection attempt
(using java:connect as before). This works well if the Erlang side somehow
has prior knowledge of the Java node name.
If the Erlang side cannot obtain a prior knowledge of the Java node name,
then the second method may be used, which starts by sending a message
to the Erlang process registered under the name reportName,
at the node otherNode, with the name of the new Java node.
Then connection proceeds as for the first method.
25/10 -- 2018:
The library now supports a facility for directly returning OtpErlangObject
values (i.e., those Java values which the Erlang jinterface library understands), without first mapping them in the Java layer.
This behaviour, which is not the default one, can be enabled
by passing the flag {return_OtpErlangObject,true} to start_node/2.
Alternatively, using the new Java connection primitives explained above,
the last argument (returnOtpErlangObject) to the two methods should be true.
3/8 -- 2018:
The library used to not permit access to synthetic or bridge methods
in a class, due to the misguided idea that such methods did not correspond
to "normal" user declared methods, but were compiler "artifacts".
This turned out to not be true, so now we permit calling such methods too.
The change may cause problems with the procedure for deciding which method
to call in some cases.
13/6 -- 2018:
Added the function string_to_utf8(JavaObjectString)
to translate a java String object into an Erlang UTF8 binary.
27/3 -- 2017:
The library now has better support for accessing non-public
members (methods and fields) by specifying the enter_classes option
when starting a node.
Example:
start_node([{enter_classes,['MyClassyClass']}])
will permit non-public methods in instances of MyClassyClass (or static
methods) to be called, and fields are handled similarly.
4/11 -- 2016:
The library now handles widening conversions better, e.g., instead
of java:call_static(Node,'java.lang.math',pow,[2,3]) raising an exception as
before, JavaCall now widens the ints 2 and 3 automatically.
4/3 -- 2015:
If you are using Javassist to create new classes which should be callable
from Erlang, the library now supports "importing" such classes
using java:acquire_class(Node,ClassRef) where ClassRef is the
Class object corresponding to the newly created class. Using this mechanism
the new class becomes callable using its name, e.g.,
java:new(Node,'MyNewJavaAssistClass',[]).
The library now also supports adding additional parameters to the Java
interpreter in the java_options option, e.g., if for some reason
the Hotspot compiler should not be run, the option
{java_options,["-Xint"]} disables it.
13/2 -- 2014:
JavaErlang now has support for implementing Java objects in Erlang
using the Javassist byte code manipulation library.
For details consult the new module "java_proxy" and the example
new example tests/swing_hello_world.erl.
11/2 -- 2014:
JavaErlang now has support for garbage collection of Java objects passed
to Erlang. This is (for now) disabled by default, to enable it use the
option {gc_enable,true} (an option to java:start_node/1).
Due to the support for garbage collection it is no longer safe to
check whether two Java object references in Erlang are equal using normal
Erlang term equality ("=="); the function java:eq/2 should be used instead.
Moreover, the implementation of garbage collection requires to use the NIF
(foreign function interface) of Erlang. Concretely a file C program
c/java_int_resource.c must be compiled and loaded. In case this creates
difficulties it is possible to simply comment out the line beginning
with "RESOURCE = ".
Yes, we should probably use a better build system. What this is, given
a mix of Erlang, Java and C code, and the requirement to have a system
usable on both Linux and Windows, I don't know.