Java 7 is out!
Daniel Gagnon
Sean Corfield
> So, what does it means for Clojure?
It's not going to mean anything for a long time. Clojure still
supports Java 5 so it is probably going to be years before Java 7 is
mainstream enough that Clojure can _require_ it.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Kenny Stone
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Tal Liron
integrate into Clojure than JRuby (or other JVM languages).
I know the Clojure Java source code pretty well, and wouldn't mind
playing with it a bit to see how feasible it is.
The ideal deployment solution would be to have an extra jar with the
JVM7 stuff that does not interfere with the core code. I'll have to
see how feasible that is.
-Tal
On Jul 28, 6:32 pm, Kenny Stone <kennethst...@gmail.com> wrote:
> Can clojure take advantage of some features if they are available? I know
> the JRuby dudes are pretty excited about invoke dynamic...
>
> Kenny
>
>
>
>
>
>
>
>
> > On Thu, Jul 28, 2011 at 8:54 AM, Daniel Gagnon <redalas...@gmail.com>
> > > So, what does it means for Clojure?
>
> > It's not going to mean anything for a long time. Clojure still
> > supports Java 5 so it is probably going to be years before Java 7 is
> > mainstream enough that Clojure can _require_ it.
> > --
> > Sean A Corfield -- (904) 302-SEAN
> > An Architect's View --http://corfield.org/
> > World Singles, LLC. --http://worldsingles.com/
Ken Wesson
> Can clojure take advantage of some features if they are available? I know
> the JRuby dudes are pretty excited about invoke dynamic...
I'm not really sure there's a single answer to that question.
On the one hand, assuming that Java 7 doesn't outright break anything,
just using it to run new or existing Clojure code gets you any new
Hotspot optimizations, the new G1 garbage collector, and (with new
Clojure code) access to new library functionality via interop.
On the other hand, invokedynamic won't instantly get you anything. If
Clojure can benefit from it at all, one *could* in principle modify
Compiler.java to try to detect whether it's running on a JVM that
supports the instruction or not, and to generate code that uses
invokedynamic only if it is.
As for using hypothetical new library functionality to implement parts
of clojure.core or clojure.lang, that would create a big backward
compatibility headache and should probably be avoided for now. Third
party libraries that provide functionality based on, say, fork-join
can certainly be made available though.
--
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.
OGINO Masanori
if Java7 gets default and it fits for Clojure.
However, for example, new HotSpot gains more performance then Clojure
may also gain if you use Java7...
(but you can't force everyone to use Java7 of course.)
Also, you can call new libraries even if they are not used Clojure itself.
(You may tell users your code works with Java7)
--
Name: OGINO Masanori (荻野 雅紀)
E-mail: masanor...@gmail.com
Bill Robertson
noticed that (at least for 64-bit) that the Windows version only comes
with the hotspot compiler. No client jvm. I haven't checked 32-bit.
This is a big change, because previous 32-bit JRE's only came w/
client. I had never checked the 64-bit.
I also agree that clojure is more able to take advantage of JDK 7,
since you tend to compile at runtime, you could just detect which JVM
you're running and install the fancier invokedynamic compiler. I've
seen claims that that won't really benefit Clojure, but I think that
determination ought to be left to measurement rather than guesswork.
One potential issue would be AOT compiled code, you would probably
want it to default to the old way, and have the option to compile with
the new compiler, should such a thing ever come into existence.
Apache Derby manages to pack multiple JDBC versions into the same jar.
I think, at runtime, its basically o.k. as long as you get the
dependencies right and never touch the wrong version's classes, the
classloader will not load them.
OGINO Masanori
---
I would like java to default to -server. I have a lot of scripts which
I cannot change (or do not want to change). Is there any way to do
this?
Since Java SE 5.0, with the exception of 32-bit Windows, the server VM
will automatically be selected on server-class machines. The
definition of a server-class machine may change from release to
release, so please check the appropriate ergonomics document for the
definition for your release. For 5.0, it's Ergonomics in the 5.0
Java[tm] Virtual Machine.
Are both -client and -server VM modes available in 64-bitJava?
Currently only the Java HotSpot Server VM supports 64-bit operation,
and the -server option is implicit with the use of -d64. This is
subject to change in a future release.
---
So 32-bit Windows JRE matters, right?
--
Name: OGINO Masanori (荻野 雅紀)
E-mail: masanor...@gmail.com
cassiel
> On the one hand, assuming that Java 7 doesn't outright break anything, [...]
Like loops?
http://www.lucidimagination.com/blog/2011/07/28/dont-use-java-7-for-anything/
Aaron Bedra
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
The short answer here is that the new platform features in Java 7 will
not get any attention for quite some time. There is a lot of
stabilization and maturity that has to happen here before we jump into
implementation. There is also the story of the backports. Since
Clojure still targets 1.5, this is walking the line of a non-starter.
This can eventually change, but the benefit that we would see versus the
impact to the language doesn't make sense right now.
That being said, given other benefits like the new garbage collector and
more hotspot optimizations, it is very likely that Clojure sees
performance improvements without doing anything. We will be taking the
time to make sure that Clojure runs on Java 7 and address issues that
come up, but the invoke dynamic and method handle stuff is not in the
immediate pipeline. Neither is adding the Java language bits like
Diamond, try-with-resources, or the rest of them into the Java parts of
Clojure.
--
Cheers,
Aaron Bedra
--
Clojure/core
http://clojure.com