Type Loader Classes from Java

[McKinley]

I am working on a strongly typed template language for Java. After
dealing with the complexities of code generation and compilation that
any Java project of this type faces I am considering turning to Gosu.
My templates will have Java types and variables embedded in them. The
templates will be invoked through constructors and methods with the
signatures necessary to assign all the variables in a type safe way.
The target platform is Java and these templates will be used from
Java.

I would like some opinions on some questions I have. If I use Gosu's
custom type loaders to generate one class per template can I use Gosu
reflection to build a straight Java interface? Could I then write the
class file to disk so that Java can compile against it?

I will have custom method signatures per template like,
AccountHome.render(int userId, String theme, Date activitySince) so I
will need one interface per template to have full type safety in using
my templates. I understand that creating and saving to disk the Java
interfaces might be complicated, but code generation and compilation
under Java is no pleasure either.

If I find I can use Gosu, are the dependencies for Gosu and type
loading really about 10MB? What are the redistribution rules on the
Gosu core? Will the core likely be free open source in 2011?

Thanks,

McKinley

[Alan Keefer]

First the licensing questions, since those are easy: the core is all
Apache 2 licensed, so you can package and redistribute it and use it
for just about anything (Apache 2 is pretty lenient). The core isn't
100% open sourced yet, but we intend to do that at some point, we've
simply been focused on lots of other stuff internally, and open
sourcing a previously-closed-source project requires some effort to
clean things up, put in copyright notices and uniform file headers,
etc.

To the typeloader question, yes, you can use Gosu reflection to write
Java wrappers to Gosu code. Our XML typeloader has that capability,
whereby you can turn an XSD or WSDL into a bunch of Gosu types, but
then you can also generate Java wrappers that map to those Gosu types
and call them reflectively. To do that, you still have to have the
Gosu type system initialized and all the Gosu runtime around so that
Gosu code/types can execute.

I'm guessing you're probably aware of this, but Gosu already has a
strongly-typed templating language built in, so you could also
consider just taking those types and generating Java wrappers, if the
language itself suits your purposes.

Unfortunately, the memory consumption is likely not so ideal: I don't
have any hard numbers at this point, and it entirely depends on the
amount of code you want to parse, but I'd guess that for any
significant amount of Gosu code it's closer to 100megs, simply because
we have to convert Java classes into Gosu type representations, and
then there's the overhead of the Gosu classes themselves on top of
that. We're working on memory consumption right now, since it's a
problem in editor plugins, but it's certainly far from ideal.

-Alan

> --
> 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.
>
>

[McKinley]

Thanks and I will take a look at the XML features. Is the source for
the XML type loaders included? It seems like the source for the Gosu
template type loader is *not* included. Is that correct?

[Alan Keefer]

Correct, the source for that typeloader isn't included. I don't
believe the XML library source is included either, unfortunately.

-Alan

[McKinley]

Do you think you could post a small wrapper example from the XML or in
the case of a properties file?

Thanks!

[Alan Keefer]

So I hacked up an example from Tosa, which has a typeloader that
parses CREATE TABLE statements to create entity definitions. The
example is by no means complete, but I at least tested that it
minimally works, so hopefully it's illustrative. Here's the code I
wrote for a Java wrapper around a Gosu type. This particular approach
uses delegation, whereby the Java class has a handle to the underlying
Gosu object.

-Alan

package tosa.loader;

import gw.lang.reflect.IConstructorInfo;
import gw.lang.reflect.IMethodInfo;
import gw.lang.reflect.IPropertyInfo;
import gw.lang.reflect.IType;
import gw.lang.reflect.TypeSystem;

import java.util.Date;

/**
* Created by IntelliJ IDEA.
* User: alan
* Date: 5/13/11
* Time: 5:45 PM
* To change this template use File | Settings | File Templates.
*/
public class BarWrapper {

private Object _delegate;

public BarWrapper() {
this(getConstructor().getConstructor().newInstance());
}

private BarWrapper(Object delegate) {
_delegate = delegate;
}

public Integer getId() {
return (Integer) getProperty("id").getAccessor().getValue(_delegate);
}

public Date getDate() {
return (Date) getProperty("Date").getAccessor().getValue(_delegate);
}

public void setDate(Date value) {
getProperty("Date").getAccessor().setValue(_delegate, value);
}

public void update() {
getMethod("update").getCallHandler().handleCall(_delegate);
}

public static BarWrapper findFromSql(String sql) {
Object delegate = getMethod("findFromSql",
getType("java.lang.String")).getCallHandler().handleCall(null, sql);
return new BarWrapper(delegate);
}

// ----------- Private static helpers

private static IType getType(String fullName) {
return TypeSystem.getByFullName(fullName);
}

private static IType getType() {
return getType("test.testdb.Bar");
}

private static IPropertyInfo getProperty(String name) {
return getType().getTypeInfo().getProperty(name);
}

private static IMethodInfo getMethod(String name, IType... types) {
return getType().getTypeInfo().getMethod(name, types);
}

private static IConstructorInfo getConstructor(IType... types) {
return getType().getTypeInfo().getConstructor();
}

}

[D. Green-Lank]

When you write a custom typeloader, and you define your constructors,
when a constructor is invoked, you have to return an instance of some
java class to represent the thing that floats around in memory. So one
approach (the one we took with the XML typeloader) is that instead of
a delegation model as shown in the previous post, have instances of
the "wrapper" java classes actually *be* the thing that floats around
in memory. The wrapper class just has to implement IGosuObject. Then,
whether you construct the object in Java or Gosu, you end up with the
same exact result.

D

[McKinley]

Alan, that is loads of help. Thank you.

D. Green-Lank, I don't understand. I thought that if Gosu loaded the
type, Java cannot see the methods and members except through
reflection. Could you show me an example?

Thanks,

McKinley

[D. Green-Lank]

That's the point of the wrappers that Alan and myself mentioned. Of
course it someone defeats the point of writing a typeloader. But on
the other hand, such as in the case of the XML typeloader, we codegen
some schemas that we want to use from Java, and not others that we
only use from Gosu. Then if one of those codegen'ed schemas changes,
you have to rerun the codegen - for any of the other schemas you do
not.

David

[Carson Gross]

The general solution here, of course, is to just use Gosu.

;)

Cheers,
Carson