Java desktop links of the week, July 5

Wow, July already. Time sure is flying these days. This week we have news for Swing, JavaFX and Griffon. As always, please feel free to flick me an email or a tweet to let me know of any news you want included. Let’s get on with the news!

Swing

JavaFX

Griffon

That’s it for another week folks. Catch you in a weeks time.

5 thoughts on “Java desktop links of the week, July 5”

  1. Yes it is. JavaFX can change the API, without a code change to the API. Luckily best practices can circumvent this.

    1. No, JavaFX can’t change the API – only the developer can do that – by changing the implementation or the API signature itself. If they change the implementation of an API that does not explicitly type the API, then they’re asking for trouble. If they follow best practices (by always typing public API) then JavaFX can’t change it. If they don’t follow best practices then JavaFX tries to help them out, but it can’t prevent the problem from ever occurring. If you’re doing API design in any language, you’re best served to follow best practices, JavaFX is no exception.

      Frankly I think it is a redundant complaint. Once you appreciate the need to always type your public API, you just do it. And then you make off with the benefits of implicit typing inside your implementation.

      The alternative complaint will come from the designers and scripters (that JavaFX is targetted at) that “it isn’t smart enough – it should try to guess the return types and parameter types of overridden functions”. I would hate for the language to introduce more rules that drives them away from the language.

      Personally I think the balance between the two camps is pretty much spot-on. Like I said, I find implicit typing to be very useful, and would be sad to see it go. I use it all the time, and it makes my code more readable, and the IDE continues to provide auto-completion, etc as it knows the types.

      1. I understand the reason behind the choices made, but it does not mean that I think it was wise. For me predictability is the most important aspect of software; I have too often fought dynamic code (last time was migrating JFXtras to JFX 1.3 and running into the “I know what to do with a null” behavior of JFX).

        To react your argument: any piece of software that another piece of software interacts with, has an API. It does not matter if that API is explicit or derrived, public or private. If such an API can change without effectively making a change to the code that makes up the API (which is possible in JFX because the return type can be derrived from another method call), it becomes -in my book- unpredictable: I change something on the left and something on the right changes as well.

        That said, this is an opinion matter, especially considering the targeted audience. Luckily the compiler does try to catch a lot of these situations and I have to option to do strict typing. So I’m very content to be typing return statements and types all over the place. 🙂

        1. I like implicit typing on some situations. Implicit function typing is a bad idea, and I don’t find it to increase readability, you’ll have to read the whole function until you understand what type it is returning.
          Null pointer relaxing is even worse.
          Don’t get me wrong I like JavaFX very much but these two things should be changed, and the sooner the better.
          Ideally one could specify some compiler flags to switch on/off this behaviors, this would leave the 2 sides pleased, if there are 2 sides to this.

          1. Agree. Implicit typing is great for variables-that-get-assigned-a-value-on-declaration, I use it there a lot. I feel that could be the best balance between strong and weak typed.

Leave a Reply