Re: Java Interop on steroids?

OK that makes more sense, BeamFn is not an interface. I imagine they argued about that decision at some point. In your example, MyFn looks to be a general class as it can work with any clojure var. Do you have a package with many of these type of stub classes defined? I mean, you could name it

Re: Java Interop on steroids?

I'm glad someone else is thinking on this too! #2 - For my case at the moment (Apache Beam), I believe we will always know the types in advance so using a Java class is workable but of course a (proxy++) would be ideal. Beam asks for us to extend abstract generic class so we must use (proxy).

Re: Java Interop on steroids?

5. If you need a concrete class definition that then implements a set of type specific interfaces this would seem to fall into a category of gen-class assuming you could specify the interfaces with type specifications. I can't immediately place a way to do this with anything mentioned above. It

Re: Java Interop on steroids?

eglue, 1. I think this is a great idea if it is really necessary. I would be in favor of a reify++ alone to simplify things. I find reify amazing at code compression and heavily use it via type specific macros to implement interfaces that for instance support a particular primitive type. 2.

Re: Java Interop on steroids?

Oh, I didn't know about that, pretty funky stuff. -- 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.

Re: Java Interop on steroids?

> Do the framework you're talking about do static analysis of the types? Because generic types are erased at runtime, so there wouldn't ever be a way for proxy to set them in. They aren't entirely erased. They're erased from the code, but Java compilers are obligated to emit generic type

Re: Java Interop on steroids?

> They did cite a significant performance boost as a side effect. I think it isn't very clear from the wording. They didn't just rewrite it in Java, they also changed the architecture: > Storm 2.0.0 introduces a new core featuring a leaner threading model, a > blazing fast messaging subsystem

Re: Java Interop on steroids?

Nathan, For the subset of problems for which clojure has insufficient power to optimize well, I think a good percentage of those would be best off solved by numeric languages like numpy or a numeric compiler like TVM

Re: Java Interop on steroids?

; >> >> -- >> *From:* clojure@googlegroups.com on behalf of >> Nathan Fisher >> *Sent:* Friday, June 21, 2019 4:17:43 PM >> *To:* clojure@googlegroups.com >> *Subject:* Re: Java Interop on steroids? >> >> Storm re

Re: Java Interop on steroids?

're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > -- > *From:* clojure@googlegroups.com on behalf of > Nathan Fisher > *Sent:* Friday, June 21, 2019 4:17:43 PM > *To:* clojure@googlegroups.com > *Subject:* Re

Re: Java Interop on steroids?

Here is my problem, distilled. This code should tell the full story: static class Apple {} Apple a = new Apple() {}; Type[] x = ((ParameterizedType)a.getClass().getGenericSuperclass()) .getActualTypeArguments(); // x is a Type array containing String, Integer HOWEVER, via Clojure `proxy`, I

Re: Java Interop on steroids?

Here is my problem, distilled. This code should tell the full story: static class Apple {} Apple a = new Apple() {}; Type[] x = ((ParameterizedType)a.getClass().getGenericSuperclass()) .getActualTypeArguments(); // x is a Type array containing String, String HOWEVER, via Clojure `proxy`, I

Re: Java Interop on steroids?

By "generic type information", you mean the X in List ? On Friday, June 21, 2019 at 12:03:46 AM UTC-4, atdixon wrote: > > However -- there are many popular Java frameworks that love to reflect on > their annotations and their generic type signatures. > > To name a heavyweight: Spring. But also,

RE: Java Interop on steroids?

21, 2019 4:17:43 PM To: clojure@googlegroups.com Subject: Re: Java Interop on steroids? Storm recently moved away from Clojure in its core. https://storm.apache.org/2019/05/30/storm200-released.html I wonder how much of the legacy Clojure core could be optimised or if they reached an upper lim

RE: Java Interop on steroids?

ret Atwood From: clojure@googlegroups.com on behalf of Chris Nuernberger Sent: Friday, June 21, 2019 12:40:28 PM To: Clojure Subject: Re: Java Interop on steroids? Sean, That is an interesting blog post. Sorry if I am not following everything but why not use the annotati

Re: Java Interop on steroids?

Storm recently moved away from Clojure in its core. https://storm.apache.org/2019/05/30/storm200-released.html I wonder how much of the legacy Clojure core could be optimised or if they reached an upper limit imposed by the runtime/architecture. That being said I suspect for 90% of orgs they'll

Re: Java Interop on steroids?

Sean, That is an interesting blog post. Sorry if I am not following everything but why not use the annotation support in gen-class for those types of things? https://github.com/clojure/clojure/blob/8af7e9a92570eb28c58b15481ae9c271d891c028/test/clojure/test_clojure/genclass/examples.clj#L34

RE: Java Interop on steroids?

You might be interested in how we provide type-based annotations on Clojure functions so that tooling (in our case New Relic) sees those annotations: https://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/ I agree that this could be a lot easier. Sean Corfield --