On Jun 14, 2013, at 10:00:42 AM PDT, bl...@orcaware.com 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.
Better still is to build with the latest JDK, but use javac's -source and -target options to specify the minimum compatible Java language version and minimum compatible JVM version. > Are you seeing code that needs JDK 7? > > Blair _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
