Closed rbouckaert closed 10 years ago
So a minimal annotation class would look something like this:
// package beast.core;
import java.lang.annotation.*;
/**
And I think we could add the static methods we need directly to the existing BEASTObject class, instead of adding to a new Core class. It is an existing class and a natural place to have it. The static methods would include:
public static void init(Object beastObject, final Object... inputValues); public static void initByName(Object beastObject, final Object... inputValues); public static String getDescription(Object beastObject); public static Citation getCitation(Object beastObject); public static String getCitations(Object beastObject);
et cetera
On 26/05/2014, at 11:47 am, rbouckaert notifications@github.com wrote:
If the requirement of deriving from BEASTObject could be relaxed, while still having BEASTObject like behaviour (Inputs as members, initAndValidate to initialise, Description annotation, etc) a class could derive from existing classes (like JComponent) while still having the benefits of the BEAST framework.
Implementation ideas: o Add annotation to indicate a class is a BEASTObject. o Use introspection to create objects o Have a static beast.core.Core class to manage these changes, so changes to existing code is limited to XML and others Parsers/Producers. o Deprecate BEASTObject?
— Reply to this email directly or view it on GitHub.
I like the idea of not having an extra Core class.
Perhaps we could repurpose the Description annotation as well -- if a class wants to be a BEASTObject but not inherit from BEASTObject, better give a description.
After thinking more about it, it seems to me that a new Core class gives us a clear encapsulation of the "new paradigm", and also provides an obvious and clean migration path that allows us to use built in migration approaches like deprecation. Whereas just adding methods to BEASTObject means that we can't easily isolate the "old paradigm" for deprecation. Since our machinery is fundamentally based on introspection and annotations (like Beans), it would be nice to deprecate the concrete class (BEASTObject) that represents the major departure from that design principle.
On 26/05/2014, at 12:49 pm, rbouckaert notifications@github.com wrote:
I like the idea of not having an extra Core class.
Perhaps we could repurpose the Description annotation as well -- if a class wants to be a BEASTObject but not inherit from BEASTObject, better give a description.
— Reply to this email directly or view it on GitHub.
If we would go for Java 8, we can have a BEASTInterface interface with static and default implementations of methods. BEASTInterface would then take care of most of the methods we need from BEASTObject (except getID/setID, and getOutputs), and BEASTObject could be the default implementation of BEASTInterface, thus keeping backward compatibility with existing code.
This means creating a BEAST-object could be as simple as
Another benefit of Java 8 is that it comes with JavaFX support (allows for better looking FIleChoosers and other widgets) on top of all benefits of Java 7. Also, future proofs us for a couple of Java versions for the next couple of years. Disadvantage is that it requires users to install Java 8, even if they already have Java 7 (also see issue #99). Would that be a shows-topper? Even if we implement #99 and/or give the option of downloading with Java 8 pacakged with the BEAST distribution?
Java 8 is already easy to install on OS X 10.9 [I have it installed], but it is only available from oracle.com and not yet java.com.
Looking at Google Analytics of the beast2.org website we had 56% of Mac Users on 10.9, 17% on 10.8, 11% on 10.7 and 15% on 10.6 (in the last 2 months Apr-May).
What versions of OS X can you easily install Java 8 on?
For example it looks like you can't even install Java 7 on 10.6 (Snow Leopard).
I think if we can keep support for 10.7 we should go for Java 8. Otherwise we should think carefully about it.
(As far as Windows users go, 71% of beast2.org website visitors had Windows 7)
(Windows + Mac were 87% of all visits, Linux 10%)
Alexei
On 30/05/2014, at 12:57 pm, rbouckaert notifications@github.com wrote:
If we would go for Java 8, we can have a BEASTInterface interface with static and default implementations of methods. BEASTInterface would then take care of most of the methods we need from BEASTObject (except getID/setID, and getOutputs), and BEASTObject could be the default implementation of BEASTInterface, thus keeping backward compatibility with existing code.
This means creating a BEAST-object could be as simple as
deriving from BEASTObject, OR implementing BEASTInterface, which only requires you to implement getID, setID, and getOutputs, which are trivial to do. The latter allows possibly deriving from any other class. Another benefit of Java 8 is that it comes with JavaFX support (allows for better looking FIleChoosers and other widgets) on top of all benefits of Java 7. Also, future proofs us for a couple of Java versions for the next couple of years. Disadvantage is that it requires users to install Java 8, even if they already have Java 7 (also see issue #99). Would that be a shows-topper? Even if we implement #99 and/or give the option of downloading with Java 8 pacakged with the BEAST distribution?
— Reply to this email directly or view it on GitHub.
http://www.oracle.com/technetwork/java/javase/certconfig-2095354.html
shows only OS X 10.8 and 10.9 have "Certified System Configurations Contents" which I suppose means it does not run on 10.7 and below -- that is about half of our Mac visitors for the last 2 months. So, I suppose Java 8 is not practical for now.
Back to a Java 7 solution then...
Remco
Another way to look at it is that BEAST2 is the cutting edge new system and if people don't have 10.8 or 10.9 then they can always use BEAST1.8?
I think if we fast-forward 12 months into the future probably 80% of Mac Users will be on 10.8 and 10.9 anyway. I think I am more inclined towards the Java 8 solution.
Alexei
On 30/05/2014, at 1:48 pm, rbouckaert notifications@github.com wrote:
http://www.oracle.com/technetwork/java/javase/certconfig-2095354.html
shows only OS X 10.8 and 10.9 have "Certified System Configurations Contents" which I suppose means it does not run on 10.7 and below -- that is about half of our Mac visitors for the last 2 months. So, I suppose Java 8 is not practical for now.
Back to a Java 7 solution then...
Remco — Reply to this email directly or view it on GitHub.
Remember, a vote for Java 8 is a vote for lambdas!
I created a java8 branch containing a Java 8 style BEASTInterface that solves this issue. Will have a look at a Java 7 implementation and see how that compares to this one.
Turns out the Java 7 solution works on Java 6 as well -- no need to upgrade for now (or upset Hudson, which runs Java 6). The code changes for the Java 8 solution are a lot smaller though, while the current code is bound to break some packages (because a few methods now return BEASTInterfaces instead of BEASTObjects, a cast may be required).
BEAST benchmark for Oracle JDKs with examples/benchmark/II/testHKY1809.xml with java likelihood core: jdk1.6.0_45 4m23s/Msamples jdk1.7.0_25 3m24s/Msamples jdk1.8.0_05 3m30s/Msamples Note the massive difference between Java 6 and Java 7. The slight degradation for Java 8 was observed for SciMark 2 (http://math.nist.gov/scimark2/) as well.
Same, but with BEAGLE-SSE jdk1.6.0_45 1m57s/Msamples jdk1.7.0_25 1m56s/Msamples jdk1.8.0_05 1m54s/Msamples
If the requirement of deriving from BEASTObject could be relaxed, while still having BEASTObject like behaviour (Inputs as members, initAndValidate to initialise, Description annotation, etc) a class could derive from existing classes (like JComponent) while still having the benefits of the BEAST framework.
Implementation ideas: o Add annotation to indicate a class is a BEASTObject. o Use introspection to create objects o Have a static beast.core.Core class to manage these changes, so changes to existing code is limited to XML and others Parsers/Producers. o Deprecate BEASTObject?