The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Why do developers have problems shipping Swing applications?

That's the topic of a blog entry by Joshua Marinacci, a new hire on the Java core Swing team at Sun.  Lots of interesting replies.  The most common complaint seems to be centered around the difficulty of installation (JRE versioning, packaging, etc).  Another, one that I definitely agree with, is the difficulty of using Swing.  Many things that people think are impossible with Swing in fact *are* possible;but it's often non-trivial and not necessarily covered in your "Intro to Swing" text. And then there's Java's layout managers (see my jdivider thread on Design of Software for a good solution out of THAT hole). Good reading here from many people who ship Swing apps (yes, people DO actually do this ;) ):

http://weblogs.java.net/blog/joshy/archive/2005/03/why_dont_you_sh.html

-Crimson
Crimson Send private email
Sunday, May 08, 2005
 
 
Why don't they make it clearer that the only thing that makes sense is to ship the legal minimum JRE with the app?

This advice should be printed in every book and article on Swing. Maybe Sun should make it their motto: "Ship your own JRE."
Tayssir John Gabbour Send private email
Sunday, May 08, 2005
 
 
And "I can't believe it's not JGoodies!"
Tayssir John Gabbour Send private email
Sunday, May 08, 2005
 
 
I tried Java for one project & my overall impression was negative. Here are my reasons (as briefly as possible). You will indeed be more productive than in C++, until you bump into the necessity to do something the Java language designers decided not to let you do, then all your productivity gains go up in smoke as you try to circumvent the obstacle. In my case, my app was receiving data over the LAN from embedded devices. Naturally, this data is C structs packed into UDP packets. Java gives you no way to cast a ptr to a buffer as a ptr to some kind of structure, so I had to stop & code up a hierarchy of packet classes complete with serialization methods that access the data via streams. This was very time consuming.

My second complaint is closely related to the first: my app wasn't that big, but before long I found myself with my nose to the ground like a bloodhound, trying to follow the trail of my own code. And I write *VERY* clean code--even non-programmers can follow my C. After thinking about it, I figured out why--Java is overarchitected. It forces you to implement a hierarchy of packet classes when all you needed was typedef struct. It forces you to implement an inner class when all you needed was a callback function. Before long, you can't see the building for the scaffolding.

IMHO, the Java designers are designing down to their users by creating a language meant primarily to stop us morons from hurting ourselves, and only secondarily to get any work done. As I've mentioned in other threads, I've started using Python + wxPython + C for my PC apps & am much more pleased with that. Python gives you a choice of paradigms (procedural, functional, & object-oriented) whereas Java makes you try to solve every problem via the creation of new types.

So there it is. Some will disagree violently, but that's my opinion, and you know what they say about opinions... :-)
John Foxx
Sunday, May 08, 2005
 
 
BTW, when I say "non-programmers," I don't mean your aunt Grechen, I mean e.g. a hardware engineer who had a C or Pascal course back in college. (Just want to make that clear)
John Foxx
Sunday, May 08, 2005
 
 
John,

"Naturally, this data is C structs packed into UDP packets. Java gives you no way to cast a ptr to a buffer as a ptr to some kind of structure,"

"And I write *VERY* clean code--even non-programmers can follow my C."

I'm not exactly sure that those two statements do match. Sure, it is fast and simple - but non-portable and dangerous as hell. Okay for a one-time Hack'n'Slash, but definitely nothing for production code. It might be that even non-programmers can follow it - but it not "clean" in any way.
Don't
Monday, May 09, 2005
 
 
John:

Kinda hard for me to get a handle on your difficulties as I'm not familiar with your project details.  But I know that you can certainly cast things in Java. :)

And statements like "It forces you to implement an inner class when all you needed was a callback function" indicate that you just may not be used Java's way of doing things.  Of course callback functions can't be done since Java doesn't have function pointers, but their functionality can be done with inner classes.  People who only know C/C++ and think Java should be exactly the same will encounter stumbling blocks like this once they delve into the language.  There is some thinking required, though the language syntax makes you think it should behave in like C/C++ in every way.

Anyway, I for one, find Java's cross platform networking support to be easily among the strongest things about the language, but I see YMMV.  Did you do any Swing related things or was this just a rant against Java in general? That's cool.  I'm open to those too. :)

A lot of Java seems overarchitected and I can appreciate that sentiment.  Sometimes it really IS overarchitected.  In other cases, it's just a case of Sun's programmers exposing everything so that you can do whatever it is you need to do...at first it can be overwhelming, especially when some of the exposure applies to like 2% corner cases.
Crimson Send private email
Monday, May 09, 2005
 
 
Some people are happiest viewing Java as an assembly language: an awkward language to write in, but a wonderful target to compile to.

So I heard a presentation a couple weeks ago by a guy who wrote a compiler that produces READABLE Java. (From near-CL.) And he has a reverse-compiler too.
http://weitz.de/eclm2005/java-for-lispers.pdf

There should be a video of his talk, but it's not up...
http://weitz.de/eclm2005/

He doesn't tell his clients the Java was produced by a compiler. When others modify/add to his Java, he compiles it back to near-CL and works on it, then recompiles his work back into Java. They just shrug it off by thinking that he's a perfectionist who reworks other people's code to his liking. ;)
Tayssir John Gabbour Send private email
Monday, May 09, 2005
 
 
To Don't:

Yes, you are correct, this is not a type-safe thing to do, but in the embedded world it's a common & necessary thing to do, because the guys who are writing the embedded side tend to create a lot of complex structures which change rapidly & often in the exploratory phase of a project, so taking care to pack these structures right is by FAR the lesser of the evils. (This is not hard--just put n-byte entities on n-byte boundaries). Writing a hierarchy of packet classes complete with serialization methods is technically the right thing to do, but in the environment I describe, you will never get it done. That is the essence of my complaint. The unsafe way is necessarily common practice in certain problem domains, and those of us who live in those domains know how to deal with it. I need to be able to make that decision for myself.

To Crimson:

I understand inner classes. What I'm trying to say is that Java, in my experience, forces you to do simple things in elaborate ways. There's an optimal point with this (as with everything else), where you make the code less readable, not more. All I'm saying is I want the choice of which paradigm to use as a solution for a given problem, not have one forced on me by someone who doesn't understand my problems.

One thing I liked about Java was the standardized socket model--getting spoiled on that (and the automatic memory management) was what made me not want to go back to C++. Also, I did not find the Swing classes counterintuitive--they were no better or worse than any other widget library I've used, and the documentation is thorough. I thought the API was well designed, in that methods are called names you'd expect, and they generally behave as you would expect them to, which places Swing head & shoulders above MFC (no surprises there).
John Foxx
Monday, May 09, 2005
 
 
Oh yeah, another thing: one idea I plan to play with (because I will need it eventually) is a function in Python which takes a structure description and a bag of bytes, and returns a newly-built structure conforming to the description, using the bag of bytes as data. And if I REALLY get ambitious, I'll make a front-end that knows how to create descriptions from C struct declarations. That way you only have to write it once, rather than rewrite a custom method for each type.

Isn't metaclass hacking cool?
John Foxx
Monday, May 09, 2005
 
 
John,

Isn't that what the Python struct module already does?
Chris Tavares Send private email
Monday, May 09, 2005
 
 
I'm still a Python greenhorn, but I think the struct module only does what the Java stream classes do--e.g. knows how to read 4 bytes out of a bag of bytes & turn them into an integer. I'm after an automatic object-serializer that can operate on any kind of object. If the struct module does that, it would be wonderful. If not, it's also possible that there's a module out there somewhere that would at least get me halfway there. I haven't dug into it yet because I'm up to my @$$ in other alligators, but when the time comes, I won't reinvent the wheel, I promise.
John Foxx
Monday, May 09, 2005
 
 
John Foxx:

Well, inner classes and the lack of function pointers is just a fundamental difference.  I don't know if I'd say it's worse.  It's a tradeoff for getting rid of the headaches associated with pointers.  This particular tradeoff is worth it IMO.

As for the Swing classes....well, that all depends on how far into the rabbit hole you go. :)  I don't think it's counter intuitive either per se, but I do think the learning curve can be steep.  Again, this all depends on how complicated the Swing app is.  Early on, there's some easy stuff that's super easy to do.  Tutorials and most books tend to cover examples like these.  But the next level is at a pretty steep plateau and it's pretty easy to get fooled into thinking everything is just as simple as it was early on.
Crimson Send private email
Monday, May 09, 2005
 
 
Side note: Have you tried not to switch from C++ to Java? I don't know about standardized socket librareis, but bounds-checked standard containers, strings and some other helper classes of type initialization-is-allocation-destruction-is-deallocation make life pretty easy and one can make public interfaces almost completely pointer-free. Of course, it depends upon your problem area, and the java standard library covers a lot of other things beside sockets.
Andrei Send private email
Tuesday, May 10, 2005
 
 
Actually, now I am doing all my GUI stuff with wxPython, with some C modules for the low-level stuff. I'm a total Python newbie but it's going well so far. I never went so far as to integrate a garbage collector into C++, so I can't speak about that. There are several of them out there; I know Mozilla is using one as a leak detector.

About Swing: yes, I only did one project with it, and the GUI part of it wasn't very complicated. It's entirely possible that there are land-mines in Swing that I didn't go far enough to step on. My knowledge of Swing is admittedly shallow. All I can say is that I didn't have too much difficulty just diving in.
John Foxx
Tuesday, May 10, 2005
 
 
OK, so Java isn't the best language for your situation.

News flash: no language is best for everything.  Java has its strengths, it just so happens that reading C structs from across a LAN isn't one of them.
T. Norman
Sunday, May 15, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz