Calling goso from Java?

[Fred Janon]

Is it possible to call gosu from Java? Is it possible to compile gosu to .class files and run a Java program calling gosu?

Thanks

Fred

[Carson Gross]

Fred,

The answer to your second question is no, not right now.

With respect to the first question, what you want to do is first initialize Gosu, and then use ReflectUtil to construct an instance of your Gosu class:

  //Some static block in your application

  static {

    gw.lang.shell.Gosu.initGosuWithNoFile( convertJavaClassPathIntoListOfFiles() )

  }

  public void createGosuObject() {

    SomeJavaInterface gosuInstance = (SomeJavaInterface) gw.lang.reflect.ReflectUtil.construct( "example.MyGosuClass" )

  }

Here I am casting the gosu class to a java interface, so I can work with it in normal terms within Java, without having to go back through ReflectUtil.

Obviously this is not an ideal situation.  Eventually we'd like to be able to load Gosu classes directly out of .class files, but as of right now there is a ton of metadata that is collected during the compilation phase that is not captured in the .class files, so it is going to be some work to get there.

It is easier, right now, to host in Gosu and call out to Java, which works without any reflective hacks.

Cheers,

Carson

Cheers,

Carson

--
You received this message because you are subscribed to the Google Groups "gosu-lang" group.
To post to this group, send email to gosu...@googlegroups.com.
To unsubscribe from this group, send email to gosu-lang+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gosu-lang?hl=en.

[Carson Gross]

Also,

Cheers,

Carson

Just wanted to get that in.

Cheers,

Carson

[Fred Janon]

Hum, thanks. How would I create a servlet to run on a Servlet container then? Sorry, I haven't looked at the example from the gosu site.

Fred

[Carson Gross]

The best environment for Gosu hosting java via a web app is probably Ronin:

  http://code.google.com/p/ronin/

The only problem is that ronin is in *heavy* flux right now, as Gus incorporates feature literals and I try to get decent trace support in.  You'd probably be best served by waiting a week or so until we can get everything polished up and documented.

There is a servlet that ships with Gosu, gw.util.servlet.GosuServlet, that you can use, but it is not something that is intended to be a long term hosting solution.

I encourage you, and anyone else who has patience and can deal with upgrade/API change pain, to take a look at Ronin, and help us improve it.  Community feedback would be absolutely awesome, although, again, I have to warn that there will be severe upgrade pain for at least a few months while we bang the stuff into shape.

Cheers,

Carson

[Brandon Gresham]

I just want to comment... that I *LOVE* Ronin's basic-approach... including it's easy-config for its DB and it's approach to convention over configuration (ie: controller and method names become the http-path).

 

Having said that, I'm hoping at some point Ronin will incorporate some DI as well as annotations to override conventions with configurations where/when desired... ie:

 

@Controller( pathname="admin", extension="rpg" )     

class MyController {

               

 

                @Controller( pathname="viewAllUsers" )

                function myMethod() {

 

                }

}

 

would be called by:

                http:.../admin/viewAllUsers.rpg

 

as opposed to:

                http:.../MyController/myMethod

[Carson Gross]

Brandon,

Doesn't sound unreasonable.  We (well, gus) are working on foundational stuff right now, but features like this are likely to be supported (or easy to implement) Pretty Soon Now(tm).

You might want to post over on the ronin group:

  http://groups.google.com/group/ronin-gosu

Cheers,

Carson

[Fred Janon]

The top appeal of Groovy and Scala is the interoperability with Java. Basically a lot of people are looking for a "better" Java. I can't use gosu if I can't call gosu code from Java and vice versa transparently. That's a show stopper. I can play with gosu but I can't use it in my projects. I don't know if/how it's possible, but I would look into solving that issue really quick if I wanted any kind of significant adoption in my opinion.

That said, I like the gosu approach, intermediate between Scala and Groovy.

Thanks

Fred

[Ted Neward]

Why can’t you just bury the Gosu-accessing details behind a Java API/library for the Java-minded on your project? That’s what I’d be doing with my Scala or Groovy objects anyway (for that same crowd)…

 

Ted Neward

Java, .NET, XML Services

Consulting, Teaching, Speaking, Writing

http://www.tedneward.com

 

 

From: gosu...@googlegroups.com [mailto:gosu...@googlegroups.com] On Behalf Of Fred Janon

Sent: Thursday, December 23, 2010 4:53 PM
To: gosu...@googlegroups.com

[Carson Gross]

Fred,

We all recognize that the current situation isn't ideal, but we have limited resources and, tragically, customer demands to meet (and, ahem, a few bugs to fix.)

We would like Gosu to interoperate with Java just like Scala does.  It's just a matter of time until we get there.  I think it can be ruled out for 1.0/most of 2011, but we might have something worked out by 2.0, depending on resources and priorities.

In the meantime, Teds suggestion is probably the best option for embedding Gosu within an existing Java application: partition out a small subsystem to implement in Gosu, put a Java API on top of it with Java interfaces implemented by the Gosu classes, and reflectively create the entry point with ReflectUtil.  Ideally, the subsystem would be something where you can leverage Gosu's strengths.  Once we've released the XML type loaders, for example, you might use Gosu for an integration layer and take advantage of the WSDL features.

If you are willing to experiment and take risks, you can start looking at Ronin for web applications.  I wouldn't use it for anything mission critical right now, but I can assure you that it will be making rapid progress, and will leverage Gosu to the hilt, so if you think The Gosu Way is good, you will find Ronin very comfortable.

Finally, again, once we've released the XML type loaders, you might find Gosu programs to be a good "glue" technology within your infrastructure, since it will be dead simple to consume and publish web services.  Additionally, Gosu provides a nice way to interact with the host OS, gw.util.Shell (see http://lazygosu.org/strings.html) which, when coupled with web services, might enable you to do some new and interesting things that would be too painful in Java.

So, we're workin' on it, and maybe in the meantime you can get in a bit of Gosuin'.

Cheers,

Carson

[Stephen Haberman]

> @Controller( pathname="admin", extension="rpg" )
>
> class MyController {

I'm being too lazy to move the conversation to the ronin group, but this
is way too spring mvc-ish for my liking.

Not that that is inherently evil...but it's close. :-)

- Stephen

[Brandon Gresham]

I understand that not everyone likes every kewl framework out there
(though why one doesn't like Spring is beyond me -- it could be improved,
certainly, but it's far better IMHO than most of the options available)...
but that's the kewl thing (I think) about my suggestion... if Ronin
maintained convention over configuration, and made configuration done via
tags as my example shows, then those who hate that approach could just
avoid it and stick with the standard-convention approach.

IOW, you wouldn't need to touch the springiness stuff!
;)

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

[Stephen Haberman]

> I think it can be ruled out for 1.0/most of 2011, but we might have
> something worked out by 2.0, depending on resources and priorities.

Given the bytecode retrieved from the gosu classloader implements real
Java methods and interfaces, and there is the general assertion that
gosu compiles to bytecode that is very close to the .java bytecode, why
is saving/loading the gosu bytecode to/from disk so difficult that it
must wait until 2012?

Or is it trivial, but just realistically that low on the priority list?

I am admittedly not an expert on exactly what happens between
the .class file and a classloader.

Thanks,
Stephen

[Carson Gross]

I'll defer to Scott, the Gosu dev lead, on the details of this, but to summarize: there is a lot of metadata that we collect during the compilation phase (e.g. parameter names) that are not serialized to the class file.  Additionally, there is a chicken and egg problem: we need Gosu classes at compilation time to do the actual compile, so we need them before they have gone to disk.  

Speculatively, I *think* we might be able to do something low rent, like generate a jar of class files that you could use to compile your java against, and then strip the jar out at runtime to let the Gosu compiler/classloader provide the implementations, in relatively short order, if there is enough demand for it.  That still wouldn't allow cross-type dependencies, but at least the entry point problem would be easier

Again, I'll defer to Scott on this, since this is all very speculative, and I know he's done a lot of thinking around this.

Cheers,

Carson

[Carson Gross]

My take (Gus' take is really the only one that matters) is that Ronin should stick with the simple dispatch model it has, but have a programmatic hook for hijacking requests from the standard dispatch approach, which would allow users to dispatch on whatever they felt like: annotations, an XML file, the time of day, whatever.

Simple things simple, hard things possible.  Both debuggable.

Cheers,

Carson

[Konstantine Prevas]

My take is that we should take this thread to the Ronin group, which I'll be doing shortly. :)

[Alan Keefer]

The classloader side of things isn't that hard; there are other blocking issues that are hard to resolve, though. The hardest one is the fact that the Gosu type system, which is used both for on-the-fly compilation and for reflective access, relies on a representation of the Gosu classes that includes information that is not currently in the class files, such as method parameter names and even, in other cases, the actual parse tree of some expressions. So creating a version of the GosuClass class that can be loaded from a .class file rather than a .gs is a fairly large chunk of work. Secondly, there are some parts of compilation that actually build up in-memory data structures that are used at runtime, for example dynamically storing eval expressions in a map so they don't have to be recompiled every time they're executed provided the source hasn't changed. So the difficult parts are not around the Java classloading at all, they're around changing the parts of Gosu that expect dynamic compilation to work properly with up-front compilation.

-Alan

[Stephen Haberman]

> The hardest one is the fact that the Gosu type system, which is used
> both for on-the-fly compilation and for reflective access, relies on a
> representation of the Gosu classes that includes information that is
> not currently in the class files

Ah, okay--it sounds vaguely like the type metadata that Scala squirrels
away inside of annotations in the .class file.

> , such as method parameter names

Makes sense.

> and even, in other cases, the actual parse tree of some expressions.

Ooh...tricky. Sounds vaguely like LINQ. What features use this?

I just came across call site validators on lazygosu--sounds very
spiffy. I'm a big fan of compile-time metaprogramming.

> So the difficult parts are not around the Java classloading at all,
> they're around changing the parts of Gosu that expect dynamic
> compilation to work properly with up-front compilation.

Cool, thanks for the explanation.

- Stephen

[Alan Keefer]

I believe that most of the things that use the expression tree to do
stuff are parts of Guidewire's platform; our web framework, for
example, inspects the parse trees of action expressions (i.e. for the
action associated with a button) in order to see if there are any
method calls in it that represent transitions to other pages, which we
then use to do things like automatically disable the button if the
user doesn't have permission to visit that page. I believe the ronin
framework originally used parse tree inspection to deal with links as
well, but has since made the transition to using feature literals
instead. We're generally trying to discourage people from using the
parse trees at runtime, however, since we're not sure how/if we can
support them generally when combined with up-front class compilation.

In general I think compiletime metaprogramming is something we'd like
to explore more in the language in the future; there's probably a lot
we can do there, but we'll be making sure we really nail down what we
already have before we starting pushing more in that direction, and as
with other language features we'll be looking for the simplest things
we can do that will be maximally useful, rather than trying to allow
for the absolute most power or flexibility.

-Alan