macports vs java
Jack Howarth
howarth at bromo.med.uc.edu
Fri Jun 14 12:50:50 PDT 2013
On Fri, Jun 14, 2013 at 10:00:42AM -0700, Blair Zajac wrote:
> On 06/14/2013 08:49 AM, Jack Howarth wrote:
>> Can someone clarify what the situation is with Java and MacPorts? On fink, we have a number
>> of packages (like graphviz) which previously have been built against the JavaVM.framework
>> in /System/Library/Frameworks. We had hoped to transition to the Oracle JDK for this but
>> they both don't use a framwork build but also stupidly install the JDK in a versioned directory
>> which will change with each Java 1.7 update. Unfortunately they don't install a generic symlink
>> that would allow the path for linkages to survive these updates (eg /Library/Java/JavaVirtualMachines/jdk1.7.jdk
>> to point at /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk, etc). It is unclear where the JRE
>> standalone package is installing as they use a sandbox during the installation. Any clarifications
>> and advice on this transition is welcome.
>
> I've got two thoughts on Java packages in general:
>
> 1) I don't see the point of us doing builds, it's better just to unpack
> the upstream package which contains jars, wars, etc. This of course
> doesn't work for development versions, but in practice, we don't have
> many -devel Java packages, especially when people get their jars from
> Maven or Ivy.
>
> 2) Unless there's code specifically in the package that needs new
> classes in JDK 7, it's better to compile against JDK 6 so that the class
> files are JDK 6 compatible. One could pass to JDK 7's javac the target
> flags.
>
> Are you seeing code that needs JDK 7?
On fink, we have some packages where all of the bells and whistles have been enabled (such as
graphviz). I noticed that the MacPorts' java variant for graphviz depends on swig-java which
in turn seems to use kaffe (which seems rather archiac). My own preference is not to bloat
the dependencies on a package unless the feature really adds functionality and isn't just
some obscure language interface for the package that no one (other than its own testsuite)
ever uses.
Jack
>
> Blair
More information about the macports-dev
mailing list