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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
