Dataphor: How to create a table with a primary key

Creating a table in Dataphor is easy:

create table Debt  
{  
    ID : Integer,

    key { ID },
};

That translates (when using MSSQL as storage) into (if we ask MSSQL to provide us with the SQL DDL):

CREATE TABLE [dbo].[Debt](   
    [ID] [int] NOT NULL 

)
 
CREATE UNIQUE CLUSTERED INDEX [UIDX_Debt_ID] ON [dbo].[Debt] 
( 
    [ID] ASC 

)

It is important to note that D4 does not have the concept of a primary key, and that the “key” keyword results in a unique index, that while for all uses and purposes can work as a primary key, it is not recognized as such by MSSQL. It is possible to have several different “keys” in a Dataphor table.

Scala is not mature enough for Weld

Scala is not mature enough for Weld (or any other reflection related operation). Turns out that one of the feature that make Scala so interesting (closures) is also a source of incompatibility (the internal anonymous class files that generate are invalid)

So, if for example, I have a code like this (inside any method in a class):

val classNames = Conversions.convertList(names).reduceLeft[String] { (acc, n) =>
       acc + ", " + n
}

That generates an inner class that makes Java reflection unusable:

java.lang.IncompatibleClassChangeError: com.googlecode.solder.dwr.WeldContainer and com.googlecode.solder.dwr.WeldContainer$$anonfun$getClasses$1 disagree on InnerClasses attribute
 at java.lang.Class.getDeclaringClass(Native Method)
 at java.lang.Class.getEnclosingClass(Class.java:1085)
 at java.lang.Class.getSimpleBinaryName(Class.java:1220)
 at java.lang.Class.getSimpleName(Class.java:1112)
 at org.jboss.weld.util.Names.typeToString(Names.java:251)
 at org.jboss.weld.util.Names.classToString(Names.java:263)
 at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:151)
 at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:133)
 at org.jboss.weld.resources.ClassTransformer$2.call(ClassTransformer.java:72)
 at org.jboss.weld.resources.ClassTransformer$2.call(ClassTransformer.java:68)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at org.jboss.weld.util.collections.ConcurrentCache.putIfAbsent(ConcurrentCache.java:125)
 at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:67)
 at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:59)
 at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:86)
 at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:134)
 at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:367)
 at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:158)
 at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843)
 at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
 at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
 at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
 at org.apache.catalina.core.StandardService.start(StandardService.java:516)
 at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

Apparently this is a known problem since 2008-08-03 (16 months so far) and AFAIK they are not in a hurry to fix it.

I guess that means I am going to have to start removing Scala from my Weld project. I am sad about this because Scala is IMO a really beautiful language, that feels much cleaner than Java, but if the .class files that it generates are not compatible with the rest of Java... it is just useless for me.

Playing with Weld and Scala to create a new framework for JSPs

Today I built my first "serious" example using Weld and Scala.
You can take a look at it in here.
So far, Weld looks like really good framework, I am still not able to say that it will replace Spring as my "glue framework", but that could certainly become true.
Scala also looks interesting (this also my first "serious" attempt at doing something with Scala), but the support for Scala in Eclipse is very fragile... the plug-in still needs a lot of polishing (no refatoring, no quickfixes, and the syntax coloring and cursor control sometimes goes crazy). I would not recommend the Scala plugin in Eclipse for "real work", but for hobbing is fine. (I wonder if the support for Scala in the Netbeans or the opensourced version of IntelliJ is better).

JPA Myth: EclipseLink and Hibernate are compatible. Not true: Hibernate does NOT follow the JPA Spec

Please take a look at the Hibernate JIRA issue EJB-441, seen it?

Now, please tell me if this is correct:

According to Gavin King (author of Hibernate) the JPA spec the @Column(nullable=false) is just a schema generation hint, and therefore JPA implementations should NOT use it for object level validation.

I think that means that if an entity object with a null property marked with the @Column(nullable=false) is persisted using entityManager.persist() it should crash with a java.sql.SQLException as the root exception, thrown when the "INSERT" statement failed after it was sent to the database by the JDBC driver (as it happens in EclipseLink), and not because some implementation specific mechanism "pre-validated" it and prevented it from reaching the database (as it happens in Hibernate thanks to org.hibernate.engine.Nullability.checkNullability).

Is that correct? Because I don’t know anymore!

Lets say that is correct, does that means that the following is correct too?:

Validation should be entirely the responsibility of the JSR-303, and the properties of an entity should only be checked for nullability before sending to the database if a JSR-303 implementation is there to indicate that.

Is that true? And if it is, then:

What is exactly the difference between @Basic(optional=true) and @Column(nullable=true)? What happens when this 2 are applied to the same property, but they contradict each other? (As in : @Basic(optional=false) and @Column(nullable=true) or in @Basic(optional=true) and @Column(nullable=false)

I could not find a statisfactory answer in the spec documentation, would anyone be so kind as to resolve this issue? Because it Hibernate Forums they have decided that the way to deal with this inconsistencies and contradictions in Hibernate and in the JPA standard is to plain ignore me since May of 2009.

As you can see I tried to raise the issue with 2 JIRAS, forum post and easy to reproduce unit-tests, but nothing seems to work… what should I do then?

How to have an auto incrementing assembly version number (Visual Studio)?

The assembly version did not auto increment… why? if I was using AssemblyVersion correcty? (The “*” indicates which part of the version string you want to have autoincremented)

[assembly: AssemblyVersion("1.0.*")]

Well, it turns out the problem is that I was also using:

[assembly: AssemblyFileVersion("1.0.*")]

All I had to do is comment the line with AssemblyFileVersion in my AssemblyInfo.cs file, and it started working:

[assembly: AssemblyVersion("1.0.*")]
//[assembly: AssemblyFileVersion("1.0.*")]

Can I use JConsole to monitor an application through a firewall?

A fragment of JConsole documentation (bold type emphasis added by me):

The com.sun.management.jmxremote.port management property specifies the port where the RMI Registry can be reached but the ports where the RMIServer andRMIConnection remote objects are exported is chosen by the RMI stack. To export the remote objects (RMIServer and RMIConnection) on a given port you need to create your own RMI connector server programmatically, as described in the section

Mimicking Out-of-the-Box Management Using the JMX Remote API in the Java SE Monitoring and Management Guide.

I actually need to write code to be able to monitor a Java application through a firewall! Talk about an unfinished product! and Sun guys even have the nerve to act surprised angry when  people say that Java is over-engineered.

Simplicity and Hubris: Web vs Enterprise Development

I would find it really funny that most people do not understand the difference between intelligent and control interfaces if would not mean that lots of time and money are wasted trying to make intelligent interfaces work as control interfaces, or Web 2.0 Internet solutions work for Enterprise intranet problems.

It is the typical "since Google/Apple/Facebook/Twitter/SomeFreeAndPublicWebSite uses it for X/Y/Z/Q it should be great for the system I am building" syndrome.

Well, it might be great for them when they are trying to solve the X/Y/Z/Q problem, but as it turns out, many developers do not work at places that build the kind of systems this companies build, and are not trying to solve the kind of problems this companies are trying to solve.

Some people think that since our problems do not seem as technologically  impressive as those targeted by free public websites they must be easier, or that since a solution worked for the super huge public web site X then it should also work for the tiny intranet system we are building, well, the truth is that most of the times this solutions do not help at all. Please don't get me wrong, some of their ideas are usable, but we need to remember that in the dreaded Intranet Enterprise development world rules are very different:

• We do not have huge hardware resources at our disposal
• We do not have a huge budget and the hiring power to get the best and only the best experts to work with us
• Our systems are not of the"just register in this form this once and after this use the site with the mouse" kind, our users hate the mouse, because they are going to be capturing data all day, and for that, the keyboard is king (and the mouse is irrelevant)
• We need to interact directly with "special hardware" (such as scanners, printers, finger print readers etc) and browsers do not know how to talk to those, a browser can not even print with precision without help from Acrobat Reader.
• We need the behavior of our systems to be consistent and always the same (Web Search engine users do not care if the search results present different information or the same information in different order as long as the "relevant" stuff is in the first pages, Enterprise users expect search results to be exactly the same as last time, unless they have done something to alter that, and when they do, the change they expect is predictable)
• Our users want access to their data now, and do not care for excuses like "sorry but there is no access to the super massively great cloud because our infinitum connection/cable modem/whatever is failing"
• Our users want data to be confidential (although they do not even understand the meaning of security and its costs). Having all your data "in the cloud" sounds great, until the country where the clouds exists decides that it wants to apply "economic sanctions" to yours and begins by forbidding you access to the data in the cloud because the company that owns it is controlled by their laws. The day I see Google store its internal mission critical strategic information in Amazon's servers or vice-versa is the day I will believe that the Cloud is a safe place to store that kind of information.
  

All those "Web 2.0" companies have done little to help this stuff (In fact, they have created lots of problems, by forcing us intranet Enterprise developers to use primitive runtime platforms (web browsers) to deliver our applications . It is not that they are evil, it is just that they are not targeting the kind of problems Enterprise developers need to solve. And I hate when I see people recommending approaches that worked fine for this companies for problems that just can not be solved with them.