> > In a future Clojure release (post 1.7) we will drop support for Java 1.6 >
Please don't. That will mean that Cursive will be stuck on Clojure 1.7 until at least Java 9, and probably later. JDK 6 is still the only recommended JVM for running IntelliJ on the Mac due to significant bugs which prevent many users (including me) from upgrading. All IntelliJ plugins for the moment have to be built for Java 6 because of this. Many of these bugs have fix versions of JDK 9 but who knows when they'll ever actually make it in. Rumour has it that JetBrains are considering releasing their own patched JDK because of this. See: https://intellij-support.jetbrains.com/entries/27854363-IDE-doesn-t-start-after-updating-to-Mac-OS-Yosemite-or-Mavericks On 12 December 2014 at 03:09, Alex Miller <a...@puredanger.com> wrote: > I've done a fair amount of testing on fastload for Rich, as well as on the > direct branch, which further extends some experimental work on static var > invocation. Fastload does indeed reduce startup time by making var loading > lazy. However, it also adds an additional check into the var invocation > path which hurts inlining and makes invoking every var slower thereafter. > > Direct invocation basically creates a static invocation path alongside the > dynamic one. This is faster for invocation, but you are effectively doing > static binding so you really change the dynamic character of Clojure at > that point. However, there are a huge array of choices - effectively every > call site could be either statically or dynamically linked and you probably > want some control over that as either a library or application author. Many > apps at prod time would be totally fine with having 99% of call sites be > static. > > Invokedynamic opens up another realm. Ghadi has been exploring that with > good results. In a future Clojure release (post 1.7) we will drop support > for Java 1.6 and be able to consider that as an option. Indy potentially > could give us lazy loading and direct call performance and possibly > dynamicity too. Anyhow, it should be clear, there are a lot of things still > to explore before this becomes part of Clojure - I expect to see more work > on this in 2015. > > I think Reid said he was planning to pickup Oxcart over the holidays > again. Oxcart really has different goals than Clojure and I don't expect it > to ever directly feed back into Clojure. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
