Re: Dropping octave.jar from the source distribution

[Ernst Reissner]

On 08/23/2017 09:29 AM, PhilipNienhuis wrote:
> Ernst Reissner wrote
>> On 08/21/2017 09:30 PM, PhilipNienhuis wrote:
>>> Mike Miller-4 wrote
>>>> Hi,
>>>>
>>>> Octave's Java system includes a JAR file of functions that are required
>>>> for converting types between Octave and Java.
>>>>
>>>> Since Java was merged in, we have been distributing the JAR file along
>>>> with the source, presumably so that users don't have to compile the Java
>>>> bytecode and recreate the JAR themselves.
>>>>
>>>> However, in reality, make always compiles the Java sources and rebuilds
>>>> the JAR archive, whether the file is distributed to users or not.
>>>>
>>>> So in practical terms, distributing octave.jar with Octave's source
>>>> distribution is useless, and no one has reported any problems with
>>>> having to compile the sources and build the JAR archive themselves.
>>>>
>>>> I think we should just stop distributing the JAR file, always rebuild
>>>> it, and remove the "-source 1.3 -target 1.3" options (see bug #51803).
>>>>
>>>> Any objections?
>>> To build octave.jar a JDK is required. AFAIK the rest of the Java
>>> subsystem
>>> (ov-java.cc etc) cannot be built if there's no JDK on the target system,
>>> so
>>> there's no use to distribute a tiny part of octave's Java support (=
>>> octave.jar) if the rest can't built anyway.
>>>
>>> So as far as that reasoning goes, I see no real advantage to have
>>> octave.jar
>>> in the source distribution.
>> Yes, definitively true.
>> With removing the switches
>>
>> "-source 1.3 -target 1.3" 
>>
>> I have some doubts: dropping target has only advantages, although small
>> ones.
>> The source version is not that using the java interface,
>> but it is the one used to implement it.
>> I suspect that one has to change the JNI version also.
>> It is set in libinterp/octave-value/ov-java.cc only and is currently
>> vm_args.version = JNI_VERSION_1_2
>> We could do JNI_VERSION_1_6
>>
>>
>> Java 1.3 is quite old and is not yet typesafe so that I would like to
>> have at least java 1.6 to maintain the java interface.
>> I myself use java 1.8 but I think, there is no real advantage and 1.6
>> would do.
>>
>> On the other hand, if the user shall compile the sources also the java
>> sources himself, we depend on his compiler version.
>> I think we should not force the user to use something beyond 1.6.
>> To ensure this, I suggest to restrict ourselves to maintain the
>> interface also in java 1.6
>> and the best way to do so, is to replace '-source 1.3' by '-source 1.6'.
> Sure, Java 1.3 is IMO even ancient. I used 1.6 several years ago and also
> use 1.8 now; so IMO even 1.6 might be considered old.
>
> Philip
>
>
Yes, it is old, definitively.
With my suggestion I just wanted to be conservative:
I do not want to force any user to update, even if he uses 1.6 or say 1.5.
On the other hand, the version we talk about does any user prevent from
using newer versions, only older ones.

It has some impact on the maintainers of the java integration because
these may only use features until the given version.
At the moment, i must say, 1.3... is ugly as it is impossible to be type
safe.
Whether the integration code needs features beyond 1.5 ... i doubt it.

So 1.6 should be a good choice.


Greetings,
Ernst