octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dropping octave.jar from the source distribution


From: Ernst Reissner
Subject: Re: Dropping octave.jar from the source distribution
Date: Wed, 23 Aug 2017 00:09:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

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 via email to

[Prev in Thread] Current Thread [Next in Thread]