The public draft of the JPA 2.0 specification is already out and includes a much-awaited feature: an API that lets you create queries by calling methods of Java objects, instead of by embedding JPA-QL into strings that are parsed by the JPA implementation. You can learn more about the API proposed by the public draft at Linda's blog.

There's several reasons to prefer the API-based approach:

  • It's easier to build queries dynamically, to handle cases where the query structure varies depending upon runtime conditions.
  • Since the query is parsed by the Java compiler, no special tooling is needed in order to get syntactic validation, autocompletion and refactoring support.

(Note that JPA-QL syntax validation and autocompletion is available is some IDEs - in JBoss Tools, for example.)

There's two major problems with criteria query APIs in the Java language:

  • The queries are more verbose and less readable.
  • Attributes must be specified using string-based names.

The first problem isn't really solvable without major new language features (usually described as DSL support). The second problem could easily be solved by adding a typesafe literal syntax for methods and fields to Java. This is now a sorely needed feature of the language, it's especially useful in combination with annotations.

There have been some previous efforts to work around the lack of method and field literals. One recent example is LIQUidFORM. Unfortunately that particular approach forces you to represent every persistent attribute as a public getter method, which is not a restriction that is acceptable in the JPA specification.

I've proposed a different approach to the JPA EG. This approach comes in three layers:

  • A metamodel API for JPA
  • A query API where types and attributes are specified in terms of metamodel API objects
  • Support for third-party tooling which would generate a typesafe metamodel from the entity classes

Let's go layer-by layer.

The Metamodel

The metamodel API is a bit like the Java reflection API, except that it is provided by the JPA persistence provider, is aware of the JPA metadata, and uses generics in a clever way. (Also it uses unchecked exceptions.)

For example, to obtain an object that represents an entity, we call the MetaModel object:

import javax.jpa.metamodel.Entity;
Entity<Order> order = metaModel.entity(Order.class);
Entity<Item> item = metaModel.entity(Item.class);
Entity<Product> item = metaModel.entity(Product.class);

To obtain attributes of the entity, we need to use string-based names, as usual:

import javax.jpa.metamodel.Attribute;
import javax.jpa.metamodel.Set;
Set<Order, Item> orderItems = order.set("items", Item.class);
Attribute<Item, Integer> itemQuantity = item.att("quantity", Integer.class);
Attribute<Item, Product> itemProduct = item.att("product", Product.class);
Attribute<Product, BigDecimal> productPrice = product.att("price", BigDecimal.class)

Notice how the metamodel types which represent attributes are parameterized not only by the type of the attribute they represent, but also by the type that they belong to.

Also notice that this code is non-typesafe and can fail at runtime if no persistent attribute with the given type and name exists in the entity class. This is the only non-typesafe code we'll see - our goal is keep the rest of the API completely typesafe. How does that help us? Well, the trick here is to notice that the metamodel objects represent completely static information about a persistent classes, state that doesn't change at runtime. So we can:

  • obtain and cache these objects at system intialization time, forcing any errors to occur upfront, or even
  • let a tool that has access to our persistent classes generate the code that obtains and caches metamodel objects.

That's much better than having these errors occur at query execution time, as they do in the previous criteria query proposal.

The metamodel API is generally useful, even independent of the query API. Currently it's very difficult to write generic code that interacts with JPA because JPA metadata may be partitioned between annotations and various XML documents.

But, of course, the most popular use of the metamodel is to build queries.


To construct a query, we pass metamodel objects to the QueryBuilder API:

Query query = queryBuilder.create();

Root<Order> orderRoot = query.addRoot(order);
Join<Order, Item> orderItemJoin = orderRoot.join(orderItems);
Join<Item, Product> itemProductJoin = orderItemJoin.join(itemProduct);

Expression<Integer> quantity = orderItemJoin.get(itemQuantity);
Expression<BigDecimal> price = itemProductJoin.get(productPrice);

Expression<Number> itemTotal =, price);
Expression<Boolean> largeItem =, 100);


For comparison, here is the same query expressed using the API proposed in the public draft:

Query query = queryBuilder.createQueryDefinition();

DomainObject orderRoot = query.addRoot(Order.class);
DomainObject orderItemJoin = orderRoot.join("items");
DomainObject itemProductJoin = orderItemJoin.join("product");

Expression quantity = orderItemJoin.get("quantity");
Expression price = itemProductJoin.get("price");

Expression itemTotal = quantity.times(price);
Predicate largeItem = queryBuilder.greaterThan(100);


Of course, this query could be written more compactly in either API, but I'm trying to draw attention to the generic types of the objects that make up the query. The type parameters prevent me from writing something like this:

orderItemJoin.get(productPrice); //compiler error

The use of generics means the compiler can detect when we try to create a path expression by combining a queried entity of one type and an attribute of some other type. The metamodel object productPrice has type Attribute<Product, BigDecimal> and therefore cannot be passed to the get() method of orderItemJoin. get() only accepts Attribute<Item, ?>, since orderItemJoin is of type Join<Order, Item>.

Expressions are also parameterized by the expression type, so the compiler detect mistakes like:, numericExpression); //error

Indeed, the API has sufficient typesafeness that it's more or less impossible to build an unexecutable query.

Generating a typesafe metamodel

It's completely possible to build queries with only the metamodel API and the query API. But to really make the most of these APIs, the final piece of the puzzle is a little code generation tool. This tooling doesn't need to be defined by the JPA specification, and different tools don't need to generate exactly the same code. Nevertheless, the generated code will always be portable between all JPA implementations. All the tool does is reflect upon the persistent entities and create a class or classes that statically cache references to the metamodel Entity and Attribute objects.

Why do we need this code generator? Because writing Attribute<Item, Integer> itemQuantity = item.att("quantity", Integer.class); by hand is tedious and slightly error prone, and because your refactoring tool probably isn't smart enough to change the string based name when you refactor the name of the attribute of the persistent class. Code generation tools don't make these kind of errors, and they don't mind re-doing their work from scratch each time you ask them to.

In a nutshell: the tool uses the non-typesafe metamodel API to build a typesafe metamodel.

The most exciting possibility is that this code generation tool could be an APT plugin for javac. You wouldn't have to run the code generator explicitly, since APT is now fully integrated into the Java compiler. (Or, it could be an IDE plugin.)

But didn't code generation tools go out of fashion recently? Wasn't one of the great features of ORM solutions like Hibernate and JPA that they didn't rely upon code generation? Well, I'm a great believer in using whatever tool is the right solution to the problem at hand. Code generation has certainly been applied to problems where it wasn't the best solution. On the other hand, I don't see anyone bashing ANTLR or JavaCC for their use of code generation to solve the problem they address. In this case, we're working around a specific problem in the Java type system: the lack of a typesafe metamodel (reflection is one of the worst-designed language features). And code generation is simply the only solution that works. Indeed, for this problem it works well.

Don't worry, the generated code won't be hard to understand ... it might look something like this, for example:

public class persistent {
	static Metamodel metaModel;

	public static Entity<model.Order> order = metaModel.entity(model.Order.class);
	public static class Order {
		public static Attribute<model.Order, Long> id =;
		public static Set<model.Order, model.Item> items = order.set("items", model.Item.class);
		public static Attribute<model.Order, Boolean> filled = order.att("filled", Boolean.class);
		public static Attribute<model.Order, Date> date = order.att("date", Date.class);

	public static Entity<model.Item> item = metaModel.entity(model.Item.class);
	public static class Item {
		public static Attribute<model.Item, Long> id =;
		public static Attribute<model.Item, model.Product> product = item.att("product", model.Product.class);
		public static Attribute<model.Item, model.Order> order = item.att("order", model.Order.class);
		public static Attribute<model.Item, Integer> quantity = item.att("quantity", Integer.class);

	public static Entity<model.Product> product = metaModel.entity(model.Product.class);
	public static class Product {
		public static Attribute<model.Product, Long> id =;
		public static Set<model.Product, model.Item> items = product.set("items", model.Item.class);
		public static Attribute<model.Product, String> description = product.att("description", String.class);
		public static Attribute<model.Product, BigDecimal> price = product.att("price", BigDecimal.class);


This class just let's us refer to attributes of the entities easily. For example, we could type to refer to the id attribute of Order. Or persistent.Product.description to refer to the description of the Product.

16. Dec 2008, 06:22 CET | Link

I like the idea and I agree some kind of code generation supported by a metmodel is the only viable solution within the current Java Model - trick like liquidform or db4o's query tricks is simply hacks.

And it even works well with dynamically built queries since the compiler can still type check based on generics. The JPA metamodel should though also allow to call metaModel.entity() on non-entity classes such as @MappedSuperclass to allow common querying on base attributes.



16. Dec 2008, 06:28 CET | Link
Jevgeni Kabanov | ekabanov(AT)

We did a similar thing for SQL with Squill ( We were considering also a wrapper for Hibernate/JPA, but if someone else is working on that already, that's great! You might also be interested in our paper on typesafe DSLs in Java:

16. Dec 2008, 20:48 CET | Link

Is this something that would be JPA-only or is it possible to be applied to ordinary hibernate projects as well?

16. Dec 2008, 20:50 CET | Link

I don't understand what you mean ... what is an ordinary hibernate project? Why could it not use JPA APIs?

17. Dec 2008, 21:06 CET | Link
AndyT (lordpixel)

We've been wondering whether to switch from using the Hibernate APIs to JPA, and what's been holding us back is the lack of User Type support in JPA.

The feedback I've gotten is people dislike having to sprinkle Hibernate annotations among the JPA ones. The objection is really that this information isn't optional - the application won't work without the user types, and so if we're going to have to import and use Hibernate annotations anyway, why not just stick with Hibernate top to bottom. I suppose we could layer that on in XML, but people like the idea of maintaining 2 files even less!

Just an example of something that makes the Hibernate APIs sticky - not sure if that's a good thing in and of itself.

I suppose it is orthogonal - presumably we could still use this query API even if we use Hibernate in other parts of the code base?

18. Dec 2008, 02:31 CET | Link

There's no reason why we couldn't do what we did with Hibernate annotations and make the criteria API a separate package from the EntityManager API.

However, FYI, it's very likely that Hibernate4 will be packaged quite differently, with the JPA APIs (plus extensions) as the native view of Hibernate, and support for stuff like the old Hibernate XML as the add-on package.

Personally, I'm deeply, deeply unconvinced by the oh, we occasionally have to use non-standard features of Hibernate, so therefore we should never use the standard JPA APIs for anything argument.

18. Dec 2008, 05:27 CET | Link
AndyT (lordpixel)

I suppose it depends on your definition of occasionally...

Almost every mapping we have has a user type in it. So while it is fair to say we don't use a lot of non-standard Hibernate features, the one or two we do use we use pervasively.

Then again, there's another question lurking below the surface here: is there some philosophical objection to user types that is keeping them out of JPA or is it simply priorities?

From our point of view their lack is a glaring, inexplicable omission, but then we use them everywhere, so we're bound to think that, aren't we? Any different perspective?

18. Dec 2008, 06:31 CET | Link

Well, from my point of view it would be extremely difficult to come up with a UserType API that accommodated the differences between the implementations of various JPA solutions. If you look at the hibernate UserType, it contains a whole lot of stuff that is just very specific to how Hibernate is implemented.

And I don't see the job of porting what ... 10? .... user type implementations from one JPA provider to another as especially difficult...

18. Dec 2008, 07:56 CET | Link
AndyT (lordpixel)

I believe you - from what I understand it took a long time for Hibernate to 'apply' the user types as consistently and transparently as it does. e.g. for the longest time I don't think they worked in all cases with Queries.

But then are you leaving this as yes, they're useful, yes, they're widely used but unfortunately they're just too hard to do right?

Maybe what's needed is a richer set of built in types? e.g. here are some of our reasonably generic user types:

  • TrimmedStringType -> gets rid of all the useless whitespace when someone has modeled a column as char(10) instead of varchar(10)
  • BooleanYNType -> maps bools to a char(1) column with Y/N
  • AbstractEnumType -> maps db values to typesafe enums (the old Java 1.4 pattern, but probably could be adapted for Java 5 enums)
  • PropertyEditorType -> uses Java Beans PropertyEditors to convert a class to a String representation for storage and vice-versa
  • NumericType -> See this issue

That's a mixed bag. The first two aim to deal with legacy schema issues, the next two are trying to automagically map from classes to a varchar representation and the last is a workaround.

I wonder if anyone has data on what the top 10 most common user types are? Are we all coding the same thing over and over?

18. Dec 2008, 08:03 CET | Link
AndyT (lordpixel)

On second thoughts, I reject my own idea - if I look at the balance of the rest of our user types, they're all really specific to our code base, so there would always need to be a user type facility in whatever implementation we might use.

It'd be great if it were portable, but as you say, they are not the most challenging things to reimplement.

18. Dec 2008, 23:12 CET | Link
AndyT (lordpixel)

Having wandered off topic and talked about something else, I find I want to comment on the proposal.

Overall it is something I think I would use, certainly the type safety and automated refactoring is great. Having the meta model generated helps massively with the typos and Don't Repeat Yourself aspect.

The fact it is in a separate package feels weird. There would be a learning curve, but I don't think it is insurmountable.

I guess if we have field literal's it'd look something like mypackage.Order#id rather than, right? But you're correct I simply can't think of a way around this at present that doesn't involve making everything public. It is frustrating because all of the data is in the class file, there's just no syntax to refer to it.

One idea this sparked... would the meta model be richer than just the Type and Name of each Attribute?

Hibernate knows all sorts of interesting things about my code, because it parses in the XML and annotations, but traditionally getting at this has been kind of tricky:

e.g. I have some code like this that figures out the database table name for an entity for doing SQL queries using Hibernate:

org.hibernate.cfg.Configuration cfg = ...

String tableName = cfg.getClassMapping(someEntityClass.getName()).getTable().getName()

Another example: the other day I was working on figuring out if the primary key of a persistent class was a composite key or not. Hibernate knows but it is a bit tricky to navigate the configuration model and find out.

Would you see a meta model API as a natural place to expose all of this juicy stuff that the ORM tool knows, or is that a bridge too far?

19. Dec 2008, 01:58 CET | Link

Actually we can make attribute references look like,, etc. Stylistically, this is really nice, and really close to what you would type if Java had method/attribute literals. I will do another post on that.

JPA annotations come in two layers:

  1. information about the model semantics, e.g. @ManyToMany, @Id, @Emddable
  2. information about how the model maps to the database, e.g. @Column, @Table, @GeneratedValue

The current proposed metamodel API gives you access to everything in the first layer, but to nothing in the second layer.

19. Dec 2008, 09:39 CET | Link

I like the idea of type safe attributes provided throw your meta model proposition. My fear is adding another artefact (while inevitable for the task at hand) will drive us far from the POJO model. Yes a generation tool like wsimport will come at handy, but I already hear screaming detractors voices about tool reliance and that the javac should be the only tool to hand coded class's. Certainly the JAVA language have to address those limitations.. Until that happen I support this proposal.

Warm Regards, Daoud AbdelMonem Faleh.

19. Dec 2008, 16:06 CET | Link

Hi guys, I like to subscribe your site, but the Subscrie to this site link ( doesn't work.

- Patrick

19. Dec 2008, 21:12 CET | Link

Define doesn't work? 404? Parsing error? Works for me, have you tried with another reader?

20. Dec 2008, 10:24 CET | Link
My fear is adding another artefact (while inevitable for the task at hand) will drive us far from the POJO model.

It's still a POJO model, since this proposal does not affect the implementation of your model classes.

Yes a generation tool like wsimport will come at handy, but I already hear screaming detractors voices about tool reliance and that the javac should be the only tool to hand coded class's.

So I've just spent several days researching the capabilities of javac Processors, and it's very clear that you can generate the necessary types as part of the compilation process. So no tool will be required. (This is a very exciting new language feature of Java 6, by the way.

20. Dec 2008, 20:50 CET | Link
Gavin King wrote on Dec 20, 2008 04:24:
My fear is adding another artefact (while inevitable for the task at hand) will drive us far from the POJO model. It's still a POJO model, since this proposal does not affect the implementation of your model classes. Yes a generation tool like wsimport will come at handy, but I already hear screaming detractors voices about tool reliance and that the javac should be the only tool to hand coded class's. So I've just spent several days researching the capabilities of javac Processors, and it's very clear that you can generate the necessary types as part of the compilation process. So no tool will be required. (This is a very exciting new language feature of Java 6, by the way.

Good to know :)

31. Dec 2008, 13:28 CET | Link

This is just like EnitySpaces for .NET Dynamic queries, with one exception they include metadata in their entity classes as inner class, so you access it like


On a separate note it would be nice if we could use a builder pattern to resemble something like



30. Mar 2009, 20:48 CET | Link
Vladimir Kovalyuk | gmail(AT)kovalyuk


I believe metamodel API should be aware of @Column annotation. I believe the classes should be serializable in order to unbound it from persistence context.

1000 for fields and method literals in Java. But I won't obtain my hope until I understand why new version of Java language has to be compatible with old JVMs (at the time when the runtimes are not compatible with each other).

I like the idea of LiquidForms. I employed some techniques it uses. Unfortunately it isn't possible to build metamodel API the same way because we have to refuse primitive types in properties. The problem is fundamental - CGLIB can't instrument all the invocations which return primitive types with the equivalent that return Object in order to insert them into IdentityMap.

Thank you for your effort in changing JPA criteria API.

P.S. I would like to read about your attention to Wicket. I'm done with JSF after more than 2 years of thinking how to do this and that when it is just impossible or expensive. I know you like JSF and made some contribution into JSF 2.0 spec. That's why it would be interesting to read about how would you compare JSF 2 with current Wicket capabilities.

30. Mar 2009, 20:51 CET | Link
Vladimir Kovalyuk | gmail(AT)kovalyuk

Sorry, forget to mention why. I believe metamodel API should be aware of @Column annotation because it would come in handy when we want to perform some sort of validation on the client side. It is possible with annotations right now. But that way does not accomodate orm.xml metadata.

30. Oct 2009, 06:42 CET | Link

I have a few concerns about the static metadata model:

- The generated metadata classes with one underscore in name are jpa specific; for example what happens if someone wants to create strongly-typed xpath api, would that implementation's static metadata model have two underscores in the class name? Also, the generated metadata class could not be able to be used in other places with strings are currently used (e.g. apache's BeanComparator).

- Probably won’t survive refactoring well (unless refactoring the entity's field would refactor the static metadata class’s field usages).

I would propose a more different approach of invoking methods on a proxy instance to form path expressions (instead accessing fields on a static metadata model). This would be strongly typed, would work with both jpa and hibernate (and potentially with other criteria use cases).

The code would look like:

ProxyQueryFactory queryFactory = new JpaProxyQueryFactoryImpl(entityManager);
ProxyQuery<Customer> query = queryFactory.createQuery(Customer.class);
Customer a = query.getRootProxy();


List<Customer> results =;

jpql produced: select a from Customer a where a.firstName = :p1

This would be akin to mock object techniques where a method calls are invoked a proxy for a class and the resulting calls are recorded.

I’ve made a somewhat complete prototype at:

It looks like another framework has also independently came up with a similar concept:

30. Oct 2009, 06:50 CET | Link
Unfortunately that particular approach forces you to represent every persistent attribute as a public getter method, which is not a restriction that is acceptable in the JPA specification.

A transient public method could be linked to a persistent field with a private access with via an annotation.

Also it begs the question of whether a field is really private if one is using it with any criteria expression (is read access prohibited or is is not!).

30. Oct 2009, 11:52 CET | Link
another framework ... came up with a similar concept

Yes, actually more than one. I added your project to my list of similar projects.

21. Jan 2010, 04:33 CET | Link
According to literals:
Yes, I'm waiting for Java literals to utilize then in Java ORMs.
I think that this Java Feature request for enhancement is this what you mean: literals, am I right?
I've already voted for this requst - vote for it too! ;]

Smiles and Regards,
24. May 2011, 04:30 CET | Link

On second thoughts, I reject my own idea - if I look at the balance of the rest of our user types, they're all really specific to our code base, so there would always need to be a user type facility in whatever implementation we might use.

It'd be great if it were portable, but as you say, they are not the most challenging things to reimplement.

02. Nov 2011, 02:49 CET | Link
Xavier Jodoin | xjodoin(AT)

You can use TorpedoQuery to create type safe hibernate query.

Entity entity = from(Entity.class);
org.torpedoquery.jpa.Query<Entity> select = select(entity);
List<Entity> result = select.list(entityManager);
08. Sep 2014, 07:42 CET | Link

Creating a beauty regimen for yourself, shows that you take pride in the way you look. That may not work the same with everyone, but it is really important to your personal presentation. So, do yourself a favor and do your research. Be sure to apply the tips in this article to your own beauty regimen. penis advantage review

08. Sep 2014, 11:05 CET | Link

Everyone can use a little revitol hair removal cream advice! Even people blessed with easy to care for hair have bad hair days now and then. Read over this advice and find out which tips will work best for you. The next time you have a bad hair day, you'll be glad you know what to do next.

08. Sep 2014, 11:41 CET | Link

Hopefully you have found the tips contained in this article to be highly beneficial to your muscle building efforts. Incorporate them into your fitness program to build and condition your muscles smartly and effectively. With time and dedication you will have the amazing body you want and are striving for, so get started somanabolic muscle maximizer soon!

18. Sep 2014, 13:11 CET | Link

Many new students feel overwhelmed by all that college life entails. It isn't easy to leave the comfort of your own home and start life anew among total strangers. If you're worried about college, then this article is just for you. For a handful of practical and proven pieces of advice, continue reading.

Go visit tao of badass pdf several potential colleges to help you decide where you want to go to college. By visiting universities, private colleges and community colleges, you can decide what environment you really want to be in. Most colleges offer several tours throughout the school year. Many also offer an opportunity to shadow a student to see what a normal day is like.

20. Sep 2014, 07:05 CET | Link

Voilà pourquoi il est judicieux, lorsque vous tirez les cartes du tarot, de noter le résultat sur un papier que vous relirez plus tard, afin d'en faire une seconde interprétation avec le recul nécessaire.voyance amour

30. Sep 2014, 09:58 CET | Link

Brisk walking even 30 minutes a day, can assist to you torch fat the long run. And, she loves her job which she finds lucrative. Monkey (Monyet) Indonesian monkey makes use of grounded stances, acrobatic movements, parries, grabbing, pounding fists, medium height positions, crawl, low movements, rolls, jumping and leaping with its playful power sets. Though this therapy was originally made to help consumers with Borderline Personality Disorder, it has proven to be equally effective in the treatment of self-harmers as group therapy and as individual counselling. A 360 spin is 1 total turn, or 360 degrees. Informed Readers. old school new body pdf

09. Oct 2014, 08:42 CET | Link

This way it motivates you to shop all-close to in order to get the rather ideal quantity. Agen IBCBET

13. Oct 2014, 13:30 CET | Link
why not try here

Secondly we have also hired the best and trained experts who will work to solve your repair problem in the best way and don't need to call them again as they gives best part of their services. why not try here

21. Nov 2014, 12:03 CET | Link

A economy is during complete control by applying few general steps. You're going to be more more comfortable in keep in mind that healthier habitat. 'House through order' produces good serenity. When most people build your dwelling you are able to build it again more energy source efficiently. Showcase homes are actually always enticing and glamorous.

21. Nov 2014, 12:04 CET | Link

Upcoming often browse about for the most impressive curiosity monetary fee. It will never really make a difference what particular home lending product often stow about not to mention review need to know rates. There might be one challenge that 1 residential home loan are generally distinct a strong additional so have the phrases not to mention situations.

21. Nov 2014, 12:04 CET | Link

As homeowners have grown more careful about improving the design of their residence, home progression industry seems to have undergone an immense revolution. Several styling firms at this moment bringing healthy home renovation tips to the platform. Some companies have gone over the internet to get into this unique new caused market.

21. Nov 2014, 12:05 CET | Link

In some cases, your the next door neighbor's children are interested in clogs your residential pets. Yet this mightn't be the most suitable option, as kids are generally reckless not to mention ignore general needs associated with animal Therefore, protection of this health and fitness of a pets could be handed finished in paid off professionals, as you'll get calmness and then the serenity from mind you will need to not to choose from.

21. Nov 2014, 12:05 CET | Link

Make an effort holding pet dog differently. Most household pet owners find who Pedi Paws is really user-friendly and uncomplicated. You are able to enable a animal to lay on your lap although you cut his or her's nails. This creates a comfortable position for a pet pup while his or her's nails are being trimmed. If this does not work, take into mind turning. You'd like your dog or cat or feline to always be comfy, but still well secure.

21. Nov 2014, 12:06 CET | Link

Life-long career and doing work for one interviewer our general working life can be described as thing from past. With our current fast-paced overseas economy, careers not to mention industries certainly change not to mention come not to mention go instantaneous.

25. Nov 2014, 09:16 CET | Link

Great tip. I have just recently started my blog and am really enjoying leaving comments on other blogs. JEE ADVANCED

17. Dec 2014, 14:24 CET | Link

Fitness is much more than looking good. Fitness also entails longevity and overall quality of your life. You need to mentally train yourself to commit to a completely healthy lifestyle that enables you with the ability to make certain changes in order to better take good care of yourself.These helpful fitness tips should guide you to take appropriate action in your fitness journey.

Keep your exercise routine interesting by including a wide range of exercises. This will keep you focused and help you keep coming back for more every day. what is the grow taller 4 idiots program

17. Dec 2014, 16:06 CET | Link

You can always try to purchase used books to save money. The cost of textbooks you need to buy can be outrageous. If you are already paying a fortune for college, then it's likely that you are needing to save as much money as possible. Shop around at online bookstores to look for previously used books. what is the text your ex back system

18. Dec 2014, 23:24 CET | Link

Cheers quite definitely for this great document; this is the items that maintains us going through out most of these morning. unsecured long term loans