We Keep Coding

Play Framework Forms (Java)

I'm checking out the Play! Framework, using Java (don't want to learn a new framework and a new language at the same time - I'll incorporate Scala as I learn that), and so far it's awesome.
I'm having a bit of difficulty with forms though. I'm still stuck on the first part here and, as far as I understand, I somehow need to get an instance of FormFactory or something related, however I have no idea in which package it might be located, or whether formFactory is also another magic method (like ok).
Any pointers would be appreciated!
EDIT Here's my code:
package controllers;
import com.google.inject.Inject;
import play.data.FormFactory;
import play.api.data.Form;
import play.mvc.*;
public class User extends Controller {
#Inject
FormFactory form;
final static Form<model.User> userForm = form(model.User.class);
public Result post() {
model.User user = userForm.bindFromRequest().get();
return ok("The form was received!: " + user);
}
}
The play.data package doesn't exit for me. Maybe I did an incorrect install? To be clear, I did start this project from IntelliJ

One issue is that your form should not be static as there is no way to initialize it before FormFactory is injected.
According to docs this call
Form<model.User> userForm = form(model.User.class);
should be
Form<model.User> userForm = form.form(model.User.class)
as form is method of FormFactory.
If the package is missing from class path its some configuration issue or wrong play version. A working project can be usually obtained through activator.

CompilationTestHelper is either not found or its access discouraged

I want to write some tests for my compiler but can't get past an error.
I'm following an example from 'Implementing DSL with Xtext and Xtend' by L. Bettini (great book btw). I've downloaded the code for the 'entities' DSL from https://github.com/LorenzoBettini/packtpub-xtext-book-examples and the tests in EntitiesGenerator.xtend work great.
If I write a test for the default DSL (MyDsl) using the same code, I've got an error:
org.eclipse.xtext.xbase.compiler.CompilationTestHelper cannot be resolved to a type.
or, if I add org.eclipse.xtext.xbase.junit (2.4.1) to the list of required plug-ins, I get
Discouraged access: The type CompilationTestHelper is not accessible due to restriction on required project org.xtext.example.myDsl.tests
I can allow access to it, but then get a runtime error anyway. If I try to add org.eclipse.xtext.xbase.lib as well, only org.eclipse.xtext.xbase.lib.source appears in the list. I don't know it that matters. In any case, adding it doesn't change anything.
What do I need to do to make it work?
I'm using Juno with Xtext 2.4.1., Java 1.7.
The content of the test class:
package org.xtext.example.myDsl.tests
import com.google.inject.Inject
import org.eclipse.xtext.junit4.InjectWith
import org.eclipse.xtext.junit4.XtextRunner
import org.eclipse.xtext.xbase.compiler.CompilationTestHelper // error here
import org.xtext.example.myDsl.MyDslInjectorProvider
import org.junit.Test
import org.junit.runner.RunWith
#RunWith(typeof(XtextRunner))
#InjectWith(typeof(MyDslInjectorProvider))
class MyDslGeneratorTest {
#Inject extension CompilationTestHelper
#Test
def void testGeneratedCode() {
'''
Hello some1!
Hello some2!
'''.assertCompilesTo(
'''some content''')
}
}
Thank you in advance!

the xtext guys mark stuff that may be changed NOT as api. this is why you get this warning.
it should work anyway. (although it is meant to be used for xbase languages only)
P.S: you have to add a dependency to jdt.core too

javax:javaee-api-6.0 contains non-abstract classes with no method body

I am fairly new to Java EE and when I look into the compiled code (I could not find the source code for javax:javaee-api-6.0), I notice this class.
package javax.servlet;
import java.util.EventObject;
public class ServletContextEvent extends EventObject
{
public ServletContextEvent(ServletContext paramServletContext);
public ServletContext getServletContext();
}
However, the same class in javax:javaee-api-7.0 is this.
package javax.servlet;
import java.util.EventObject;
public class ServletContextEvent extends EventObject
{
private static final long serialVersionUID = -7501701636134222423L;
public ServletContextEvent(ServletContext source)
{
super(source);
}
public ServletContext getServletContext()
{
return (ServletContext)super.getSource();
}
}
The also happens to ServletException in the same package (there might be more, as I didn't go through each of them).
Assuming Java Decompiler gave me what the source code looks like, from a pure java grammar point of view, I can't understand why the 6.0 classes are not abstract (or, not interfaces).
Question 1. Why are the classes in 6.0 not abstract or interfaces?
Question 2. Why is the implementation changed in 7.0? Did people realize the 6.0 version would cause trouble when you compile code with javaee-api?
The reason I ask is because I actually got compile errors when using javaee-web-api (which has similar classes as javaee-api, see this) in Intellij IDEA (12.1.4). The error looks like this:
Internal error: (java.lang.ClassFormatError) Absent Code attribute in method that is not native or abstract in class file javax/servlet/ServletContextEvent
So Question 3. Is there a way to avoid this in Intellij IDEA?

Did people realize the 6.0 version would cause trouble when you
compile code with javaee-api?
Yes, one of the problmes is that you cannot use those classes when running tests. See this Arquillian FAQ and Adam Bien's blog post.
Is there a way to avoid this in Intellij IDEA?
See the links above. The solution is not specific to Intellij IDEA.

Does com.day.cq.search.impl.SimpleSearchImpl expose an addPredicate() method?

I need to filter some pages so that they won't appear in search.
For that there is a method called
addPredicate(new Predicate("mytype", "type").set("group.4_group.1_property", "jcr:content/cq:template"));
This method is not present in com.day.cq.wcm.foundation.Search. I'm not sure in which API this addPredicate method is present.
In the CQ5 docs, it is said that this method is implemented in SimpleSearchImpl, which is present in the package com.day.cq.search.impl.SimpleSearchImpl. However, when I try to import that package, it throws an error saying that package is invalid.
If SimpleSearchImpl is not the required class for addPredicate method, can you please tell me what is the class that is needed for the method addPredicate?

The com.day.cq.search.SimpleSearch interface is exported from the cq-search bundle, but not the com.day.cq.search.impl.SimpleSearchImpl implementation class.
You can see a list of the exported packages here:
http://localhost:4502/system/console/bundles/com.day.cq.cq-search
You can get a reference to a SimpleSearch implementation by adapting a Resource or using a SCR reference.
Alex Klimetschek gave a great presentation on [using the QueryBuilder API]http://www.slideshare.net/alexkli/cq5-querybuilder-adapttoberlin-2011) as an alternative to the SimpleSearch approach, this might be useful for helping to understand predicates.

Removing class ambiguity without being overly verbose

I have a Java library that I am working on with a directory structure which looks like the following:
/com
/example
/LibX
Server.java
Client.java
Now, from a project which is using the above classes, it seems to me that importing com.example.LibX.* and using Client client = new Client(...); is a bit ambiguous, as "Client" could mean anything. Therefore, I tried the following, only to receive "package not found" errors:
import com.example.*;
LibX.Client client = new LibX.Client(...);
It is possible to do what I described? Or is there another way to remove the ambiguity without using com.example.LibX.Client?

Java packages are not hierarchical, even if they may sometimes look like it. You can't import a "tree" of packages, as you're suggesting. You either need to import a specific package with a wildcard, or you import the specific class name, or you use fully-qualified class names in your code directly.
The following isn't ambiguous, and is considered best practice:
import com.example.LibX.Client;
...
Client client = new Client(...);
In a world where IDEs can organise your imports for you, there's no reason not to state them all explicitly.

Your concern about ambiguity is unnecessary - if you have an ambiguous reference your class won't compile -
e.g.
import java.util.Date;
import java.sql.Date;
public class Test {
private Date date;
}
won't compile. So if you can compile the class then by definition you don't have an ambiguous reference.
Incidentally LibX.Client is a bit confusing. Usually classnames are capitalized, package names lowercased, so if you did that (if LibX was a top-level package and you were giving the full name) it looks more like an inner class reference, as in Andy's response above.

It's possible if you're willing to group Client and Server as static nested classes.
public class LibX {
public static class Client {
//...
}
public static class Server {
//...
}
}
Now you can import mypak.LibX and then do new LibX.Client(). This has the unfortunate drawbacks of forcing you to group your classes and also creating the additional empty LibX class.

There's no such mechanism like what you described. Your only other possibility is to use single class imports:
import com.example.LibX.Client;