Vl - GWT to Appengine - JPA Issues

-- Appengine and JPA ---

One of the things that bugs me about GWT's appengine JPA support is the fact that owned many-to-many relationships are not possible.

The only way to break this issue would either be to use unidirectional relationships (not always a suitable option) or to create a Mapping class much like a Mapping table.

Of course, creating such a class and correctly connect it with appropiate one-to-many relationships is not easy either.

Conclusion: For all simpler usecases I will use unidirectional connections:

Examples:

AgeGroups and Competitions: Competition -> AgeGroups, as the other way round is only needed to associate agegroups to a competition, a very seldom usecase.

Events and Competititions: Event -> Competition. Hierarchically seen, its quite common to list the competitions for an event, but not to which events a competition belongs.

Competition - Participants. A mapping class must be created anyway because of the special values. The following Relationships can be found in the participation class:

unidirectional OneToMany: Each P. belongs to an event, but the events do not need to know all participations

bidirectional OneToMany: Each P. belongs to a competition, an each competition knows all of its participants

Luckily, that seems all. I feared that many to many would pose much more problems.

Still questionable is the construct participation: Maybe it would be easier to create a join object for competition and event, but on the other hand, it should be enough to restrict that via the ui and the daos.

-- GWT and JPA --

If it works as specified, combining JPA and GWT should be no problem. I either must declare a new package for the JPA-Classes (as they are not available on the client if packed in the server package) or i must find out how to create a "shared" repository with classes not connected to either the client or the server.

The last one would be cleanest solution, but I think it will be - at least for the beginning - also the most unlikely. There should be no problem for the server if everything is packed into the client package - at least i hope so.

The great advantage of these things is that I can use exactly the same objects on both the client and the server without any problems. This is extremely elegant and ensures maximum compatibility with both the database server and the javascript GUI.

VL - GWT to Appengine

A new experience i wanted to make was wether it would be possible to create a gwt application based on an appengine server, which is capable of being deployed to "offline servers".

More exactly: I want to create an application which natively runs on the appengine server with multiple users but also offers to option to create "deliverables" of the datastore and an additonal jar which could be integrated into a "normal" appserver like a jboss for situations where an internet connection is either not possible or where it would be too risky too depend on both the internet and the appengine to be reachable.

The application is question is a re-implementation of a very old program dos, VL (VolksLauf). The program in question should be able to register data and participants for various running competitions taking place at the same day. For this task, a humble worker has to enter all participant registrations (currently manually) into the system about 1 week before the event starts. During the event, the program is used to retrieve the time lists and calculate the rankings as well as printing the records.

What I want is a gwt-based frontend (just a simple java gui) with powerful data input mechanisms, import filters and exports in the form of a record printer. The backend should be an appengine application with mandate-separated datablocks. In other words, multiple users can use the app at once with completely independent data. However, since the google accounts do not work offline, there must also be an offline solution usable on a "normal" webserver. This offline solution is just an export of the database with the user data only (no data from the others) and a much simpler account management (if any). This could be used for events where either internet is not possible or to reduce the dependence no both a good connection AND the appengine. It would be a catastrophe if there would be no connection at the critical day.

After the event, the data could be restored on appengine by re-importing the deliverable and overwriting all former data of the user that way.

Well.. we will see wether i have the endurance to finish the entire application or if just create some gwt widgets and then give up. Currently, I am taking care mostly of the application skeleton on the client.

JScala - Using Java the Scala Way??

As the last entry has pointed out, I will now try to find out wether Scala is, despite is complexity, ever to be considered as an _imperative_ heir to the java throne. My next few entries will rotate around this issue.

If scala should be the heir, then at least the following points must be fullfilled:
- It must be easy enough of the everyday programmer: Easy to use, and its complexity hiding until needed.
- It must focus on imperative programming and using mainly the JDK. (I am looking at you, immutable and functional scala "List"!)
- Even though the syntax might differ, most usual constructs, like singletons should be easily to identify by someone who is at least familiar with the java way.
- No unreadable short expressions (another one in the face of functional p. Short is not always better)
- There must be a simple subset defined which helps doing imperative tasks and esp. patterns for imperative programming in java (seeing that most things, even loops require the functional way in the background)
- Good IDE support
- Support for Checkstyle and Code Formatting
- Good documentation
...

Many points on this list seem hard to achieve: esp.: how to hide the functional complexity at least partially from non-functionals. Seeing that even the for-lop requires some method calls and many things are not solved by keywords but rather by overloadable Operators (by its core just even more methods), there clearly must be some patterns which make it easy for the beginner.

Also, programmers more experienced in functional programming maybe should learn how to write their objects in a way in which not too much functional aspekts are leaked by their API. Honestly, I am sceptical wether such a step would even be possible with Scala, but maybe it is.

With the next articles, I will try very hard to find out wether it could ever be the new java for the masses. If it were, then I would predict that we have reached a new chapter of humanity. Functional Expressions, The possibility for any kind of DSLs and still pure OO just seems too good not at least to give it a try. A sceptical one, though ;-)

Alternatives to Java: Scala

When talking about a successor for the throne of javal, many people, like Groovy "inventor" James Strachan, say it will be scala.

Scala seems to merge the expressive power of the dynamic languages while still being statically typed. Even more, it allows you to program in an imperative way while being in its core a functional language. Lastly, it seems to have an exact "magicless" syntax developed by academics which is, by the way, capable to be completely re-defined for forming Domain Specific languages. Hey, and with many different kinds of Object Patterns (like the infamous Singleton) its even more objectoriented than java itself and lacks the need for a static keyword as well.

Sounds insane? Well.. it is. To be exactly, its main problem for java developers might be the fact that its functional, not imperative at its core. The imperative features more or less seem to be just thrown in for convienience and to make it easier to solve problems which are hard at functional level.

Still, to grasp the point again it can be used in conjunction with java, imperative programming is possible and its statically typed with countless syntax gifts to the power programmer. For me, its not even a question wether it was designed for functional programming. Nearly all programmers nowadays and as I suggest, at least for next two decades, will code imperative. So a lot of features which help you coding "the scala way" are nice to have but..

In the next few entries I will try to find out not wether functional programming is better, No! I want to find out if scala is suitable as a java-like language which offers closures as a bonus! Also, I want to find out wether the immense complexity of the language could be put to good use without programming geniusses:
If scala should ever be heir to the java throne, then it has to be used in an imperative way, maybe even in conjunction with the java libraries etc.
So.. I know have the following goal: Trying to find out wether

Alternatives to Java: Why Groovy isn't it

Do not get me wrong: When I wanted to leave Java and glanced at Groovy, I really liked it. The powerful syntax, the dynamics, CLOSURES, everything. Groovy is a brilliant language in many parts, no question about it. However, there are IMHO some dramatic downsides.

It would list them as the following:
- Dynamic classes, methods and attributes
Definitely a nice feature for some people, but for the static man as me how even shuns overloaded methods as a failure of java, dynamic methods and classes are just an akward evil with little to none advantages. Of course I can make dynamic method names, but I think they do not offer you much you really need. There are always clean and short ways around this issue, and its impossible to explain to beginners.
- Shiny Magic
And again I'm on the "Static is Good Road" which blindfolds me for the greatness of dynamic languages and their different ways to influent my current code. But really, a lot of things happening in groovy seem to much magic for me, comparisions etc. And I do not like magic which could result in strange run time exceptions about which my compiler will never have a damn idea.
- Performance
While groovy 's performance is perfectly ok for a scripting language and brilliantly for this use case, its too complex and powerful to create very fast code for large applications on the jvm, i would say. This is of course a thing thats hard to judge in detail, but it could really be a problem. On the other hand, who would manage a large software problem with a dynamic language?
- Dynamic Languages are hard to support via IDE
Not a problem, just a conclusion. If you write dynamic languages, an IDE cannot really support you as most pitfalls are hidden in areas where a compiler cannot find them. So you have to stick with your brains. Of course, this is not a failure of Groovy. NO, far from that. Its just my personal problem (as i like IDEs) and the luxury of stuff like syntax analyzation and code completion.
To be exactly, without code completion, writing Java code would be impossible painful. Groovy on the otherside, is very simple to write right out of the box, but its hard to support it much more. Dynamic typing might be the one problem, but much more important is the fact that method completion is very hard to implement, as there are so many dynamic things.

The final point is also the killer argument. Groovy was never intended for replacing java, as statical and dynamic languages are for completely different use case scenarios. See also the performance backlash from which groovy suffers.
However, as long as the main language is as crappy as Java is, Groovy is the nice and brilliant script language to support it. Its in most parts well designed, and its more java than jruby is. Beanshell does not count, as it's just interpreted java with minimal sugar.

Alternatives to Java

Having summarized why I do not like java AND IN THE FULL KNOWLEDGE THAT IT WILL BE ONE OF NO 1 LANGUAGES LIKE THAT FOR THE NEXT TEN YEARS, I will begin to dream now.

Of a world where either java changes or a new star arises and replaces the good old horse.

*Blink*

Hey, I am dreaming! So lets forget about the "java changes" part. There are some language features (like exceptions, arrays, primitives and == comparing referential equality) which just cannot be changed anymore without forcing the programmers to update their old code, so java will never become fully elegant. I guess the foremost point which we could reach which the old lady are operator overload and closures in the future. But seeing how java 7 will be, even these simple things might be hold off forever.

So I will delve into something else and look at possible alternatives, which could in the future replace java. This will not be a full look onto all possible languages. To be exactly, it will be unfair and restricted to two alternatives:
First groovy, as its very powerful but still close to who java reads and feels.
Second scala. This one is completely different but has nearly all features dynamic languages have while still being static.

I have choosen them for two different aspects:
- Groovy is very close to java, while being as powerful as Ruby,
- Scala is syntatically far of java but it has a unique features. It combines dynamic Typings powers with a real static typing, and integrates java code in a very tight manner.

For these reasons, I excluded JRuby, Rhino, Jython and the like, as their are all neither static typed nor close to java. At least one of them should be fullfilled to inherit some of javas powers.

Note: Experts might now say thats it not worth to look at scala, as it's intended as a functional language and thereby farer off java than any other of the listed languages. Well, I am NOT planning to scala Scala in the scala way. Instead, I will concentrate all my efforts on reviewing it as an imperative language with functional benefits.

Why Java Sucks

Of course this list here isn't just by me and you will find it elsewhere, but i guess its still entertaining. Guess you will find a comparable list also in your local scala and groovy guide.

A first comment: This list is not intended to say "the designers of java were wrong. Instead there are some decisions which arguably proved false in the aftermath, some plain language quirks, and some fields were the language is definitely missing a thing or two.

Part 1 - Not so nice Ideas (or: the designer was wrong)
- Primitives are not Objects.
This is just the problem with the fact that java Objects are all references, while the rest are valuetypes. Guess they could have gotten around this problem which causes bad effienciency and übercrappy syntax in pre java 5 by just making a virtual "base object" which is not instanciable but from which the "reference object" inherits as well as the virtual final "value objects" (int, char, ...). The only restriction would have been the fact that creating arrays of "base object" would have been impossible (as it has no defined length and access method). Of course this is just an idea where billions of other might have been just as well.
- Checked Exceptions
This is not really a rant, but a saddening nod. They had been a nice idea, which did not work out, as the designer of C# pointed out when being asked why he excluded them. I strongly support his position, although i really like them in the rare situations where they are used correctly. Nowadays, however, java has annotations which could provide exactly the same feature. Also, the way how subclassed had to deal with exceptions when overriding methods was not very elegant.
- Generics
This is a biased thing - Now java has generics, but no reification, as C# has. On the one hand, this really sucks, on the other hand this makes way for individual implementations of this feature in other languages which run on the jvm, like scala. This might make up for the performance loss, and the advantage of analysing the current generic class like in C# is not real an advantage (to me, its just the same antipattern as most instanceof checks are). There is however STILL ONE BIG BIG DOWNSIDE, and you know it. Arrays again?
- Method Overloading
While Operator overloading is not possible, method overloading is. I regret this, deeply, as it was one of the features that was nearly squeezed out. However, it did not. I guess that a lot of people will tell me now how important method overloading is and that is able to design elegant API's with methods like print, or the common methods of class Array. Ok, there are cleary some places where this method would be very useful.
The problem is imho, that method overloading has two problem domains: First, it is not possible to overload also the return value (which is a bit inconsistent, as this forces many getter methods for collections to explicitly define individual return types). And second, mostly its just used for default parameters, which could also be defined much more elegant - IF java had them...
Also, theres a gazillion of problems with method overloading which could result to the caller of the method to do crazy stuff like actually typecasting an object to get the right method, and it could be quite confusing. Also, reflection is much more complicated, as the method name alone is not sufficient. This alone could also result in even more problems if java had default parameters, as parameter lists might then even be more complicated to deal with.
In short: Its a nice feature with not-so-nice interactions and problems, and its crap that is impossible with return values.

Part 2 - Plain Crap
- Arrays and Collections
What are arrays? A kind of strange pseudoclass for containing multiple values (which is at least typecastfree in java 4). I like arrays (j4), but its still strange that they have no kinds of convienience methods directly attached to them to convert them to their collection correspond (the list) and vice versa. To me more exactly: The folks at sun should have just put a litte thought into how to integrate collections and list. I know there are static convenience methods, but this is OO, right?
- Exception hierarchy
Checked exceptions would IMHO a bit less messed up, when they were not so strangely inherited. To be exactly, the problem is the (misleading named) RuntimeException, which inherits from Exception. Not intuitively and strange, and it also makes catch Exception impossible for almost all cases without a seperate catch RuntimeException. This is clearly a very early design problem which was impossible to fix later.
- Limited-to-useless type inference
Its nice and such that java is statically typed, but its really dumb that there is no way to loosen the declaration restriction for local (thereby harmless) variables, to make code more beautiful: It would be completely sufficiently to omit the type of local variables in their declaration (using a keyword like var instead) as they type could be automatically read out by the compiler during the first initialization. This would enable this like declaring anymous inner classes and use their methods at least in local contexts, (see the scala blogs and tutorials about this problem). Also, the main use of this would be to make code less verbose:

var a = "hello";
String b = "hello";
var c = new FileOutputStream("hi")
FileOutputStream d = new ....

and so on. It also omits the usual question, wether the List or ArrayList base type should be used, as the compiler knows anyway. This is not even a feature which they could not easily introduce, i guess they just do not want to..


Part 3 - Missing features
- No Operator overload
Ok, it prevented stupid people doing stupid things, horray. It also prevented intelligent people doing perfectly credible things. Just think about how ugly it is in java to compare Strings for equal. Note that i am not talking about full operator overload like C++ has (not talking of Scala), i would have just appreciated sugar like == deriving from equals and the like. At least the == Operator is unfixable (and with him the core java ugliness of equals), but some others like + - * / are still possible to allow in future versions.
- Weak case selection
Just another one which directs into the face of operator overloading, a weak syntax. Just as it is not possible to use == naturally on strings, it isnt as well to use it in Case statements, thereby encougaring ugly int comparisons and nested-if loops. At least Java 5 enums proved a small solution here. I still prefer QBasic, my first programming language, here...
- No Closures
Inner classes were designed as a way to show that a pure object oriented language do not need function pointers and the like, as inner classes are a convienent way to circumenvent this problem. The desingers couldn't have been more wrong, although the classes were a noble approach to stay pure OO - if there were just a syntax construct to turn them into closures without 5 lines of overhead, i would even agree...

This is just a small list, maybe I will post some more in the future. This list is for java 5 of course. Every half-minded human should now that java 1.1-1.4 (which i have to deal with at work) are just disgusting.

Java - All hail to the successor of COBOL

I am not an expert in trekking down all hypes about which i read recently.

There always seemed to be a new better web framework in the past years. There always seemed the better and faster enterprise solution for your java coding. There always was the brand new IDE which made coding java even easier.

And since Ruby: There always seemed to be a better language than java. Honestly, i do not give much to the opionion of others and try to make my own mind. But the huge amount of useless syntatic salt and the very low expressiveness of the language is amazing to any experienced developer. I will explain that by my own experiences with languages:

The past..
At first this just was an article I read in a java magazine about a brand new language called "Groovy" which told me about the "problems" my then supposed workhose for ever on, java, had. At the time, I tried that nice new thing to become modern and cool developer - Only to stumble back to my old tools, when realizing the lack of IDE-Support, a built-in problem of dynamic languages, cost me more times then the more powerful language would give.

2 years later...

• After one year, I began to hate frameworks for the fact that many of them make coding harder and not easier (stupid non programmatic syntax). I began to pray for simple coding in java again..
  
• In the same year, I began using javascript and after some weeks, i used the hell out of anonymous functions. Then my prayers for java turned into curses when thinking about the fact that a dynamic , browserincompatible and horribly designed language (thinking about === for comparisions, i.e. and millions of flaws integrated by MS) was actually more fun and challenging to use than my former favorite pet.
• Also in the same year, I read everything about reflection, inner classes and desperately searched for a way to make closures work without 5 lines of inner-class-clutter to turn java into a more suitable tool.
• From then to now on, I am forced to code in Java 4 - and my workhose turned into an ugly and unfriendly bitch which neither understand how to do something repeatedly without 2000 words and It had a serious memory problem in the case that it could not remember that a set of 5 Apples consisted of ... 5 Apples without telling her again and again

Nowadays, I am a realistic in that case that i know that i have to stick with that bitch, but still looking desperatly for business-ready alternatives. And when I see all the shiny stuff microsoft enabled with C# on an nearly equal plattform i begin to realize the secret intend in sun's unwillingness to change anything since 5.0:

They just want to create "COBOL OF THE FUTURE" (COTF),
a rock in terms of lines of code and libraries, but more and more ackward for the programmers struggling for more expressiveness.

init()

Hi and hello everyone... Hm.. Deutsch... Englisch..

Guess I will just start in English for sole fun. My posts are not really intended for much public viewing anyway, and if i ever will post interesting stuff in here it will surely be only for the tech-interested (In other words, people who know how to read what I'm typing.

See ya some time with more interesting content. Guess I will start by looking at some features of "modern" programming languages like java (the stupid generics implementation and the weak inner classes as a substitute for closures have begun to bug me over time).