Dropping octave.jar from the source distribution

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Dropping octave.jar from the source distribution

Mike Miller-4
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?

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping octave.jar from the source distribution

PhilipNienhuis
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.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Dropping octave.jar from the source distribution

Ernst Reissner
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'.

Ernst



>
> Philip
>
>
>
>
> --
> View this message in context: http://octave.1599824.n4.nabble.com/Dropping-octave-jar-from-the-source-distribution-tp4684575p4684607.html
> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Dropping octave.jar from the source distribution

PhilipNienhuis
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
Reply | Threaded
Open this post in threaded view
|

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