J2se 5.0

Smack Smack Dev
1

Do you have plans to update Smack to take advantage of the new features in J2SE 5.0, such as generics?

2

Doug,

Very good question – we’‘ve been talking about it this past week. Jive Messenger will require JDK 1.5 so that we can support TLS through stream negotiation (SSLEngine) and SASL (1.5 has SASL support). We’'ll need to support the same thing in Smack. So, there are two options:

  1. Require JDK 1.5 in Smack.

  2. Hack in support for the above features on top of JDK 1.4. It looks like the JSO library did this, so it should be possible.

It will be a long time before everybody upgrades to JDK 1.5. On the other hand, there’'s lots of advantages to doing so. So, what do you and everybody else think – should Smack 2.0 require JDK 1.5?

-Matt

3

I think it’‘s a good idea, I think generics make code look a lot cleaner. Most developers will probably move up to 1.5 pretty quickly. End users using smack based apps will take a lot longer, but that doesn’‘t matter much; they probably don’'t need the latest version of smack either.

George

4

I am not in favor of requiring JDK 1.5 in the immediate future for purely selfish reasons – most of my development is carried out for FreeBSD and Mac OS X. FreeBSD will probably have a Linux compatibility port pretty quickly if there isn’'t one already, but I have not had a lot of luck with those; a native port is likely to take a while to emerge and stabilize. OS X 10.2.x only supports JDK 1.4.1 and will not get a happy fun upgrade to 1.5.

5

I’‘m with kcounsell, regardless of OSX support for 1.5, I see no compelling reason to move to 1.5 anytime soon. Making changes to an API like Smack to support one or two new “features” in a dot zero release that few people are going to have doesn’'t make a lot of sense to me.

6

Ryan,

The problem is that we may have to move to 1.5 in order to provide full XMPP compliance. Otherwise, there is no elegant solution for SASL and TLS through stream negotiation. If we do move to 1.5 in Smack, it would be under the following conditions:

  • Smack 2.0 would be the release targetted at full XMPP compliance and would require JDK 1.5.

  • We would continue to develop and support Smack 1.x.

  • Jive Messenger will continue to support Smack 1.x for the forseeable future.

I like this model since it preserves use of the library for non-1.5 users while still allowing us to move forward. Thoughts?

Regads,

Matt

7

Hi Matt,

That sounds like a reasonable plan. I appreciate your concern with wanting to ensure that Smack/Messenger remain standards compliant. I guess my displeasure over some of the changes made in 1.5 kind of came through in my last post, but that’'s a discussion for another forum.

Thanks,

Ryan

8

Ryan,

Really, I totally love the changes in 1.5. What things do you not like?

-Matt

9

Really, I totally love the changes in 1.5. What

things do you not like?

Other than the lack of support for OSX?

To be fair, I haven’'t really used it enough to form a strong opinion about it, but…

  1. Generics: You cannot use reflection effectively because the type parameter information is not stored in the compiled class file. There are many ways to circumvent the type “safety” provided by the templates, especially if you are mixing code from older versions.

With java generics you can compile this:

class MyClass<T> {
       T[] anArrayOfT() {
          Object[] arr = new Object[10];
          //add whatever you want to arr.
          return (T[]) arr;
       }
    }

Of course, you cannot assign the return value to a T because it is really an Object, so, where is the type safety? All this is without mentioning that Java generics don’'t provide any performance benefit (which you would naively expect because you believe that you do not have to cast anymore).

  1. Autoboxing: this feature removes clarity from the language. You do not know what is really going on. And you never know when you are going to be surprised.

  2. Annotations: Seeme like this sort of thing should be left out of the language and left tools like XDoclet.

  3. New for: I find that this simply makes the code harder to read. The original, C like “for” construct was very clear and was very understandable both for arrays and collections. Now in order to use a fundamental construct (a “for”) your code has to implement some new interfaces.

10

The plan that Matt laid out to maintain backward compatibility while implementing the XMPP standard strikes a good balance. I appreciate the concern for those of us to haven’‘t or can’'t upgrade

Whatever other issues exist with 1.5, having printf makes me do the happy dance (not in public, mind you – nobody wants to see that). Autoboxing does seem tragic, though.