19. Jan 2015
16. Jan 2015
15. Jan 2015
12. Jan 2015
06. Jan 2015
17. Dec 2014
12. Dec 2014
10. Dec 2014
09. Dec 2014
03. Dec 2014
02. Dec 2014
21. Nov 2014
13. Nov 2014
03. Nov 2014
To celebrate the new release of JBoss Tools, I'm going to walk through some of the features of JBoss Tools that are interesting to Seam developers.
There are two perspectives that are of interest for people using Seam: the Seam perspective and the Hibernate perspective:
The Seam perspective features some very useful wizards in the New menu:
The first thing you'll want to do is create a Seam Web Project, by following the wizard:
Next, create a Seam Action:
All Seam components are easily accessible from the Seam Component View:
Even better, they're autocompleted whenever you start typing an EL expression:
Even property names are autocompleted (JBoss Tools is even smart enough to understand generic types!):
We can run our application from the Run menu, or from the Servers View. JBoss Tools automatically deploys changes incrementally, a /big/ improvement over the Ant-based solution used in seam-gen:
The most impressive feature of JBoss Tools is the visual page editor, which does a great job of previewing complex Facelets pages with RichFaces controls, standard JSF controls and even Facelets templating:
Of course, autocomplete and hyperlink/F3 navigation to Seam components and Seam component properties also works in the visual editor:
There is a visual editor for web.xml:
And one for components.xml:
Autocomplete and hyperlinking/F3 work here too:
If we use Seam Generate Entities, we can reverse engineer an application from a database schema, or from existing entities:
And, switching to the Hibernate Perspective, we can browse the entities via a treeview:
Or via a full visualization of the mapping:
Update 16.11: The update site is now in-sync with CR1 too, Use http://download.jboss.org/jbosstools/updates/development in Eclipse.
This release brings JBoss Tools very close to a final release, but to get there we are going to need help from the community to test out the release. If you haven't already done so, please try out JBoss Tools and if you find any issues bring them up in the forum or open issues in JIRA.
We have also started doing some small movies to show of the functionallity in JBoss Tools and Red Hat Developer Studio.
The following shows the steps to create a JBoss Seam project with JBoss Tools and how to run and edit the project.
While there are many things I like about the Java language, the lack of unsigned types has always bothered me.
According to Gosling, they were too complicated:
Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex.
Ironically this kind of hand-holding tends to introduce other complexities that are often more difficult to deal with than the original solution. In this particular case, leaving out unsigned types doesn't stop the need to work with unsigned data. Instead, it forces the developer to work around the language limitation in various unusual ways.
The first major problem in this system is that byte is signed in Java. Out of all of the code I have ever written, I can only think of a select few situations where I needed a signed byte value. In almost all cases I wanted the unsigned version.
Let's look at a very simple example, initializing a byte to be 0xFF (or 255), the following will fail (note: this works in C#, since they made byte unsigned):
byte b = 0xFF;
Java will not narrow this for us because the value is outside the range of the signed byte type (>127). We can, however, work around it with a cast:
byte b = (byte) 0xFF;
If we are clever and know twos compliment we can use a negative equivalent of our simple unsigned value:
byte b = -1;
This is just the tip of the iceberg though. A common technique used in search and compression algorithms is to precompute a table based on the occurrence of a particular byte value. Since a byte can represent 256 values, this is typically done using an array with the byte value as an index, which is very efficient. Ok so you might think you can do the following:
byte b = (byte) 0xFF; int table = new int; table[b] = 1; // OOPS!
While this code will legally compile, it will result in a runtime exception. What happens is that the array index operator requires an integer. Since a byte is specified instead, Java converts the byte to an integer, and this results in sign extension. Again, 0xFF means -1 for a signed byte, so it gets converted to an integer with a value of -1. This, of course, is an invalid array index.
To solve the problem, we must use the bitwise-and operator to force the conversion to occur in the correct (yet unintuitive) way like so:
table[b & 0xFF] = 1;
This technique gets ugly quick. Take a look at composing an int from 4 bytes (Ugh!):
byte b1 = 1; byte b2 = (byte)0x82; byte b3 = (byte)0x83; byte b4 = (byte)0x84; int i = (b1 << 24) | ((b2 & 0xFF) << 16) | ((b3 & 0xFF) << 8) | (b4 & 0xFF);
These issues have in turn lead to odd API workarounds. For example, look at InputStream.read() , which according to its docs is supposed to return a byte, but instead returns an integer. Why? So it can do the & 0xFF for you.
We also have a DataOutput.writeShort() and DataOutput.writeByte() that take integers instead of the their respective types. Why? So that you can output unsigned values on the wire. On the reading side we end up with four methods DataInput.readShort(), DataInput.readUnsignedShort(), DataInput.readByte(), and DataInput.readUnsignedByte(). The
unsigned versions return converted integers instead of the described type names.
To add to the confusion, we also have 2 right shift operators in this signed only mess. The
unsigned right shift operator, which treats the type as if it were unsigned, and the normal right shift, which preserves the sign (essentially acts like divide by 2). If we want to get the most significant nibble value of an integer we need the unsigned version.
int i = 0xF0000000; System.out.printf("%x\n", i >> 28); // Returns ffffffff! System.out.printf("%x\n", i >>> 28); // Returns f, as desired
So I ask all of you, was all of this hassle worth leaving out the simple and well understood
unsigned keyword? I think not, and I hope anyone who considers doing this in another language they are designing learns from it. At least C# has.
Matt Raible lists his picks of
the top web frameworks for deploying on the JVM:
- Struts 2
What I think is most interesting about this list is simply how /different/ each of these frameworks is from each other. A couple of years ago, any list of the top web frameworks would have featured a bunch of metoo-ish action-style-MVC frameworks, with maybe one or two component-style-MVC frameworks thrown in. I /could/ summarize this list by saying that the balance seems to be shifting in favor of component-oriented approaches, but I don't actually think that this is the real story here.
You see, the component frameworks listed actually have much more that is /different/ about them than they have in common. And the same is true of the two action-style frameworks.
So the real story is that there has been a whole lot of creative thinking going on in the web framework space in the last couple of years (if I recall correct, four of these six frameworks did not even exist three years ago).
For the record, I believe that /any/ of these frameworks is a good foundation for web development, and a big improvement upon what people were using a few years ago.
Now, what I'm really interested to see is what happens next. Will certain projects (for example, Seam and Grails) decide to focus their energies on problems like orchestration, state management, data access and integration, while supporting /multiple view technologies/, and leaving other projects (for example, Wicket, JSF, GWT and Flex) to focus their energy upon the view? Or will each of these projects need to grow independently into a full stack solution?
Clearly, the example of Rails shows that a single project can deliver a full stack solution and that this is attractive to many users. However, it's not clear to me that this approach is as natural in the Java world, where we are more comfortable with choice and with heterogeneous technology environments, and where we are somewhat less inclined toward hero-worship.
The strategy we want to follow with Seam is to support multiple view technologies. We don't yet have a definitive list, but the ones I'm thinking of are JSF, GWT, Flex and potentially Wicket. But we're not kidding ourselves that this is a simple task. Developing and maintaining the level of /deep integration/ that Seam has for JSF is extremely expensive.
So, I've been following this discussion with interest. I'm still confused. All I'm really getting out of the comments on this thread is:
there's some other objects in the system that aren't DAOs or entities. But I knew that already. Clearly, I need to actually read the damn book for myself. Still, it really doesn't fill me with confidence that people who /have/ read the book don't seem to be able to explain (in words or code) the Repository notion coherently. And it looks like everyone has their own private take on what exactly a Repository is all about. This gives me a hint that the idea is not especially well-defined.
What I still need to hear from proponents of this idea is a clear accounting of:
- what problem does it solve?
- how do I tell when I need to use it?
- how do I tell which functionality belongs in the Repository, which on the Entity, and which on the DAO?
- what are the costs of using it?
And I want these folks to take seriously the following question:
Do we /really/ need another stupid layer in our already horribly over-engineered Java applications?
Enough layers already, goddammit! :-)
UPDATE: Fabio Kung has written a nice
of his understanding of the semantics of a repository, and there's nothing there
that I really object to. Except that, what he's describing is pretty much what
my understanding of the DAO pattern has /always/ been. I have never understood
DAO was persistence specific from the point of view of the client. It's just a source of objects. Where it gets those object from is its own
business. I sorta thought that was the whole point...
||Showing 1026 to 1030 of 1237 blog entries||