juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Bognar <james.bog...@salesforce.com>
Subject Re: More/Simpler Examples
Date Mon, 09 Jan 2017 16:00:06 GMT
On Mon, Jan 9, 2017 at 10:42 AM, John D. Ament <johndament@apache.org>
wrote:

> On Mon, Jan 9, 2017 at 9:30 AM James Bognar <james.bognar@salesforce.com>
> wrote:
>
> > Hi John,
> >
> > This is great!  Some notes...
> >
> > There's an existing juneau-samples project.  But it's more targeted
> towards
> > REST examples.  Maybe have the following two projects...
> >
> >    - juneau-examples-rest
> >    - juneau-examples-core
> >
> >
> Yes, that was my intention.  I didn't touch the microservice one yet for a
> couple of reasons.  I wanted to start with a simple example, a little more
> explanatory than what was on the homepage, but showing off a good set of
> features (e.g. without digging into javadocs, its hard to figure out what
> the right annotations are).


I like it.

> While we're at it, maybe rename the following projects to highlight that
> > they're REST apis?...
> >
> >    - juneau-server -> juneau.rest
> >    - juneau.client -> juneau.rest.client
> >
> >
> I think that would be better, and help clear things up.  But I also suspect
> there's some other changes that could go in.  For instance, adding RDF
> support requires me to bring in jena manually.  I would expect that if we
> had a juneau-core-rdf module it would bring in jena automatically.
>

Also like it.


> >
> > Your example uses constructor arguments for setting bean properties
> instead
> > of setters.  While this works fine, setters are generally faster.  With
> > setters, the bean can be instantiated immediately and properties set as
> we
> > find them in the input.  But with constructor args, we have to cache the
> > property values temporarily before we call the constructor.  So there's
> an
> > additional HashMap being created.  Just something to keep in mind.
> >
> >
> Its an interesting tradeoff.  That could be optimized though to only lazily
> parse the JSON as you're hitting parameters on the constructor.


What do you mean by lazily parse the JSON?

Some notes:

   - The JSON parser is a single-pass parser with no intermediate DOM.  It
   parses directly into POJOs.
   - The attributes in the JSON could be arbitrarily ordered.
   - The attributes in the JSON could be incomplete (e.g. some properties
   passed to the constructor end up being null).

Take the following example...

// Constructor with 3 properties
public MyBean(int a, String b, MyOtherBean c);

// An additional property.
public String setD(String d);

// Incoming JSON
{
   d: "bar",
   c: {...},
   a: 123
}

In this case, we don't create an instance of MyBean until we've found a, b,
and c.  And we cannot call setD() on the bean until it's been
instantiated.  So until we've found all the constructor properties,
everything gets stored in a temporary hashmap.  As soon as we find a/b/c,
we instantiate it and start calling setters directly.

Since the JSON in this case doesn't contain 'b', the bean instantiation is
delayed until the very end.

Beans with only setters/getters don't have to deal with this delayed
instantiation.

-- 
James Bognar

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message