I was pretty exclusively a Java developer for twelve years before making the switch to Scala. Yes, it was difficult to learn some of the syntactical differences, but now that I have I don't want to turn back. No, this is not a baited question to get a flame-war going, but an honest attempt to get some real feedback by those that believe Scala is more difficult than Java.

Let me lay some ground-rules before we get this discussion going though. First, complex topics in Scala are complex, there's no debate there, but that doesn't make Scala more difficult than Java, there are just more possibilities to what you can accomplish. I say that the argument cannot be made that Scala is more complex if there is not a side-by-side comparison to Java code that is much simpler to understand. This means we have to leave the advanced concepts of implicit conversions, multiple inheritance, and so much more that Scala can do, but are features that bring it beyond the capabilities of Java. Yes, of course you can make an argument that in switching to a language like Scala you will eventually run into these scenarios, but I am speaking purely of the introductory programmer and the "difficulties" between Scala's syntax versus Java's.

Now, can someone give me a scenario of code in Java that would be more complicated to understand in Scala?

I would consider myself pretty competent with Scala at this point, but there is still so much I have yet to learn. Something I always used to do in Java was to work my way one class at a time through the JavaDocs of the language I am attempting to do with Scala now as well.

I've just run across the Either class in the ScalaDocs and really like the idea.


The idea is that you may have two different return types that may result from one method. Classically that is solved with all sorts of hackery or returning the common superclass to the two and then doing an instanceof check, but in Scala the Either class provides a much more elegant solution:

object Test {
 def main(args: Array[String]): Unit = {
  numOrString("5") match {
   case Left(s) => println("String: " + s)
   case Right(i) => println("Integer: " + i)
  }
 }
 
 def numOrString(s: String) = {
  try {
   Right(s.toInt)
  } catch {
   case exc: NumberFormatException => Left(s)
  }
 }
}

I'm not really sure how practical this example I wrote is, but my method "numOrString" takes in a String and attempts to convert it to an Int. If it can return an Int it does so or it returns a String. By use of the Left and Right subclasses of Either you can define which type of result you are sending back. Finally, with Scala's awesome matching you can easily determine which type of result you got.

Programmer ADD: The (often external) push to work on many projects at a time rather than focusing on and accomplishing one task at a time.

I currently work for a small company and unfortunately that means I'm constantly being pulled in many directions. There just aren't enough people to do everything, but lately I've started noticing the effect this has had on the quality of work I do. Since I'm constantly pushing to finish up what I'm working on in order to start on the next project on my plate I often don't take the time really necessary to quality check and test the functionality I've added or changed. This results in work that is not as well thought out as it should be, and not as well executed as I would like.

I can definitely point a finger to my boss for pushing the amount of work I have to accomplish in a given time-frame, but realistically even when I've worked for larger companies this has still been more-or-less true of all development work I've done. As developers we're constantly being pushed for deadlines and getting bugs fixed. This might be great from a management perspective on "work accomplished", but I think this really has a negative impact on the company in the long-term as we aren't really given the time necessary to nurture our projects to write solid and well-tested code, but just enough to get the job done. The result? Code that eventually has to be repaired or updated at twice the effort as it would have taken to do it right in the first place.

This is basically just a rant as I see the quality of my work declining as deadlines push me to do more than I can safely accomplish, but it also raises my curiosity if this is something most other developers deal with as well?

I've been a user of Eclipse for many years now and when I saw there was a free t-shirt to be had by reviewing the newest release there was only one choice to make. :)

The download is exactly the same as all previous releases but the first thing that struck me was the startup time. Granted I have no plugins installed yet, but Eclipse was up in just a few seconds and that already has me excited. Performance has always been the biggest problem in Eclipse and if they've made major strides in that direction I'm a happy camper.

Granted this is RC4, but immediately after downloading and unzipping I checked for updates and it spend the next 5 minutes downloading a pretty large update to the Eclipse SDK and made me restart when it was done. Again, RC4, so lets just hope the actual releases are up-to-date. :)

Installing MercurialEclipse and the Scala plugin went smoothly and I went to pull down Sgine (http://sgine.googlecode.com) and all was fine except Scala can't seem to build the project correctly. My guess is this is a bug in the Scala plugin with Helios.

After spending a bit more time with it I haven't really seen much difference in 3.6 and 3.5 apart from some performance improvements. However, performance alone is a very worthwhile feature.

Well, this is a great title for this post not only as it's the first blog post I've made here in seven months, but I've also had the song from Portal stuck in my head lately. :)

Looking at my blog it would be easy to classify me as MIA but I've actually been quite busy in the open-source and have even been blogging quite a bit lately, just not here, but I'll get to that in a minute.

First of all, my very basic last post talking about the entry-level learning I was doing with Scala was quite fitting as my last post as very shortly after that post I made a complete shift from Java to Scala programming. With this came the abandoning of lots of open-source projects I've either created (like jSeamless) or been a developer on (like jMonkeyEngine). I believe so strongly in Scala that I've shifted everything I possibly can to Scala.

Second, with the shift I've made to Scala and all the projects I've abandoned as a result, one new project has come to being that, in many ways, embodies much of the vision I've had for several projects I've left behind. That project is called "sgine" (Scala Engine). I've been developing on it for a while now and have made some major strides recently and finally wanted to make a re-appearance on my blog to hopefully start posting here again.

Now, at the beginning of this post I said that I've been blogging elsewhere. If you go to http://www.sgine.org you'll see that it's a blog filled up with posts regarding updates to the engine I've been developing. I'm really excited about this project and though many people have accused me of abandoning Java...and realistically that's pretty much what I've done...I haven't a regret for switching to Scala, it's such an incredibly powerful language and has renewed my vigor in programming. For anyone considering looking into a new language I cannot recommend it enough.

Lately I've been learning the ins and outs of the Scala language and I have to say, having programmed in Java for the past several years, that Scala is scratching where I itch. It is a lot to grasp and mind opening, but all-in-all I see Scala as what Java could have evolved to if they would have just been willing to ditch some backwards compatibility and fix some stuff rather than just adding more and more work-arounds.

Anyway, that's not the point of this post. I wanted to post some cool loop examples I've been playing with in Scala.

In Java we have the standard incrementing for-loop:

for (int i = 0; i < 10; i++) {
    ...
}

In Scala we have something similar, but I believe more elegant:

for (i <- 0 until 10) {
    ...
}

However, with Java 1.5 we got the enhanced for-loop when we don't care about indexes:

for (String s : listOfStrings) {
    ...
}

In Scala we do something similar, but with a more consistent syntax:

for (s <- listOfStrings) {
    ...
}

Or, we can go a step further with Scala since it's a functional language we can get rid of the for loop entirely and use a friendly method available to us called "foreach" and pass each entry to another method:

listOfStrings.foreach(doSomething);

def doSomething(s:String):Unit = {
    ...
}

To me this is of significant appeal because we don't end up with a bunch of embedded for-loop blocks in our methods we focus more on modular functionality to deal with the results of the iteration instead.

From the outside looking in it would appear that jSeamless is all but dead, but if you've been paying attention to SVN commits you'll notice there's been quite a lot of activity for the past several months. I have somewhat abandoned what small community I had with jSeamless 1.0 in an effort to "start over" with what I believe is the next generation of UI development. I know there seem to be more web frameworks these days than there are developers using them, but I believe that jSeamless 2.0 has several things going for it that goes outside the scope of any UI framework available today. I know that's an ambitious statement, and I hope in this post to back it up enough to push the point home.

So, from a high-level, here are a few of the major features to look forward to in jSeamless 2.0:

Properties

As discussed in previous blog entries the plain old java beans ideology is one that does not lend itself to extensibility and re-use, so the introduction of Properties into the UI framework creates some amazing possibilities with surprisingly elegant results.

Binding

Binding is one of those buzz-word features that both Flex and JavaFX boast and one of the major reasons JavaFX claims to need its own language is because binding is just plain ugly in Java. However, in jSeamless, with the use of Properties, to bind the 'x' position of component2 to the 'x' position of component1 this can be accomplished with the following single-line elegant line of code:

component1.location.x.bind(component2.location.x);

Yes, that's all you have to do to get real-time property binding.

OpenGL

One of the biggest reasons jSeamless 1.0 delved into the realm of Flash/Flex was because Swing was so incredibly slow and lacked many of the niceties professional developers have come to expect from their frameworks. OpenGL not only solves this problem, but laughs in the face of any other competing graphical framework as it boasts FPS rates in the thousands when Flash struggles for framerates in the hundreds. OpenGL is by far the fastest graphical API available on all the major operating systems. Beyond the fact it spits on all the competition, it adds complete 3D capabilities to the landscape of capabilities people can utilize in their UIs. I could spend several pages elaborating on the features that OpenGL brings to the table, but the best example is just to look at the capabilities of any modern game.

States

Similar to the States support in Flex, jSeamless introduces a similar, but far more powerful, concept in its framework. There are default states associated with basic components like Button (over, pressed, focused, etc.) but they can be modified, removed, and since they use Property references the activation of a State in one Component can modify the appearance of another Component.

No Effects

Yes, this sounds like a disadvantage rather than an advantage, but through my extensive use of Flex in jSeamless 1.0 it became very evident that Effects in their common state add more complexity and frustration than benefit to any complex application. The primary cause of this is what is known as "effect fighting". This occurs when you have two effects that are attempting to modify the same values on the same component toward different ends. In an environment where you want modularity this can be a common occurrence because you have no way of easily determining whether an effect is currently being enacted on the property you wish to enact an effect on, nor do you have the ability to gracefully handle that scenario. You end up with a component jumping around like it can't really decide where it wants to be on the screen. Beyond that, having to create an instance of an effect per scenario leads to a lot of code and having to monitor different scenarios (effect causing something to change, or a direct modification). Finally, you run the risk of something concurrently simply trying to set the value and it being overridden by an Effect in progress. After careful consideration the decision was made to leave Effects out entirely in favor of a new concept associated with every Property called PropertyAdjusters.

Property Adjusters

PropertyAdjusters, as the previous point states, is the alternative to Effects in jSeamless. This offers a simple, concise, and asynchronously mindful methodology of "adjusting" a property to some target. For example, rather than creating something like a MoveEffect, setting the start and end values, setting a duration, and playing it upon a Component you simply do something like this:

component.location.x.setAdjuster(new EasingPropertyAdjuster(Easing.LINEAR_IN, 5.0f));
component.location.x.set(500.0f);

That will apply an EasingPropertyAdjuster for every time the "set" method is invoked on that Property until the PropertyAdjuster is removed. This allows you to style your animations completely independent of the programmatic changes that happen elsewhere. Also, if you ever want to bypass a PropertyAdjuster you can simply invoke "setNow" on the Property to get you immediately to your destination regardless of any PropertyAdjuster that might be set. What's particularly nice about this is if half-way to 500.0f you make a call "set" passing 100.0f it will smoothly take the change and apply it to the animation in progress thus eliminating effect fighting and reducing the complexity of animations in programmatic UI development.

Easings

Simply put, easings are an algorithm that defines the path from one numeric value to another given a specific length of time. Rather than moving a box from left to right smoothly easings give you the ability to have it bounce into the new location.

For example, Easings simply add a polish to animations to move your application's effects from cheesy to professional. jSeamless supports all easings that Flex currently supports along with the ability to create your own with a simple to use interface to define the algorithm.

JMC Support / Media

If you are not familiar with JMC (Java Media Components) it is because it's not really talked about very often by itself. It is a media framework for Java that allows playing video and audio in many formats (FLV, H264, WMV, etc). Sun has blindly been pushing JavaFX which contains this very awesome new API, but they seem to be doing their best to block people from taking advantage of the functionality without buying into JavaFX lock, stock, and barrel. A few people like myself have spent a lot of time finding ways to make use of JMC in Java without the JavaFX dependencies and I have to say it has been very much worth the effort.

Swing Integration

It would be foolish to assume such a small endeavor like jSeamless could really garner the capabilities of a long-lived UI framework like Swing in the short-run. To that end there has been a lot of work done to provide Swing integration directly in jSeamless so all those custom components your application may need to take advantage of can still be used if you should decide to make the switch.

100% Java Framework

In jSeamless 1.0 the viability of Applets was nil, the ability to use OpenGL in the application was problematic (the whole Security Trust dialog), and the performance of Swing was lacking to put it mildly. All these things led to the decision to use Java on the back-end as a remote controller to a Flex front-end. The developer using jSeamless 1.0 only ever had to write Java code, but everything displayed in a Flex client. This was a cool idea, but in the years since that decision was made Java has come a long way. Applets have had new life breathed into them, Sun is magically trusted (JOGL signed JARs), and the world is our playground with the use of OpenGL. All of this was done in Java 1.6 update 10. It was this release of Java that made me have to rethink the whole concept of Java in the browser and Java on the desktop. jSeamless 2.0 has abandoned any ties to anything but straight Java (excepting of our JNI bindings to OpenGL via JOGL of course).

Scalable UI

With the introduction of OpenGL we now have the ability to define a "working resolution" that is not the same as the actual resolution. What this means is that you define your UI as an 800x600 statically defined UI and via the use of vector graphics (one of the very powerful features of jSeamless) have the content dynamically scale up to much higher resolutions "seamlessly" to the user. To them it appears that the UI was developed specifically for their screen size, but to you the development was much easier as you can utilize static pixel values that will get scaled dynamically to the proper resolution.

FXG and SVG Support

If you've never heard of FXG don't feel bad, it's a new feature Adobe has introduced with the new CS4 versions of their applications. It is designed as an XML-based format to portray vector and raster graphics exactly the same as they appear in Illustrator, Photoshop, etc. What is particularly cool about this is that not only does jSeamless have the ability to import FXG files, but the layer names and vector graphics are kept intact during the import. This means a graphical designer can create elements and name them in Illustrator, export it to FXG, you can then import the FXG file, and access the elements by their names and manipulate them directly.

Though not quite as cool, a still very useful feature is the ability to import SVG paths into jSeamless vector graphics.

Size and Location Support Percentages

A big frustration in Swing layout management has always been the pixel values you must put into location and size to determine where and how large your Component should be. This leads to a lot of boilerplate code to center, right-align, or arbitrarily place a component at a specific position based on percentage rather than pixel.

Flex did a much better job here by defining the ability to size components with a pixel or percentage. However, in jSeamless we're going for something much more powerful. We not only give size pixel and percentage values, we also allow defining of x and y location as pixel or percentages. Beyond that, we define an "alignment" to determine what point the percentage should be snapped to. Take this example:

component.location.x.set("50%");
component.location.x.align.set(HorizontalAlign.CENTER);

This sets the x location of the component to be 50% of it's parents size and then uses the CENTER alignment to make 50% represent where the component's "center" is giving us the ability to perfectly center the component within the parent without any boilerplate code.

Advanced Event System

One of the most powerful features of jSeamless 1.0 was the extremely powerful and flexible event system. It took many of the new concepts introduced in Flex, coupled them with a powerful multi-threaded ideology, and threw in a lot of new concepts nobody else had ever seen before to create what I humbly consider to be the best UI event system ever created. :)

Okay, yes, that's a pretty bold statement, but it's at least the most powerful event system I've ever seen in use anywhere...and I've used a lot of UI frameworks. With jSeamless 2.0 the same system was largely kept, but updated, performance improved significantly, and some additional features were added to hopefully take a great event system to the next level.

I would really like to get into specific details about the event system here, but as this post is already running long I'm going to have to make a special post to talk just about the event system in jSeamless as it's just too broad.

Vector Shapes

I've alluded to this already a few times, but jSeamless 2.0 is very centralized around vector graphics to allow scalable UI development, which is particularly beneficial in a 3D environment as content may scale up or down significantly depending on the current usage and perspective.

Suffice it to say, the support for vector graphics required to fully support the FXG format is a pretty broad range of features.

Fully Thread-Safe UI Framework

One of the major goals of jSeamless all along has been thread-safety. This is one area where Swing has always been a big disappointment. The need to use a SwingUtilities.invokeLater any time you want to make any changes to a component made code ridiculously ugly and frustrating to work with. Further, the single-threaded event system leading to a locked UI thread (by ignorant coders of course) is one of the primarily reasons people still think Swing responsiveness is poor at best. jSeamless 2.0 ran the same potential problems with OpenGL as it is required to be run in a single-thread, but all of jSeamless has been written to be thread-safe and hide any single-threaded functionality that must be handled directly in the OpenGL thread. To that end, we also introduce some very interesting multi-threaded rendering capabilities that allow components to render themselves in separate threads before pushing into the OpenGL stack.

jSeamless Google Code Project:
http://code.google.com/p/jseamless/

jSeamless 2.0 Branch in SVN:
http://jseamless.googlecode.com/svn/framework/branches/2.0/

jSeamless Forum:
http://forum.captiveimagination.com/index.php/board,14.0.html

This is definitely not an exhaustive list of features and functionality that jSeamless 2.0 provides. This is simply the functionality already being provided in the pre-alpha version of the framework. My goal in this post is hopefully to garner some interest and potentially some developers who might be interested in joining the project. The project is coming along quite well, but it is largely developed by a lone developer...me. I can always use another perspective and more help to bring this framework to its logical conclusion.

If you have any interest in joining the jSeamless project please contact me.