Wednesday, February 18, 2004

Re: Code Review

also for gui based apps it is very odd for a cmd/shell window running in the background in which the java command was given. so there also exists a javaw command which will start the gui app without the cmd window

Java was designed with the intention of being run on set top boxes right? Then it moved to the server and applets. I suppose because of this it's not that "client friendly". How often dyou see java apps on the desktop anyway?

these problems are further magnified as in java each class is in a seperate file. (which i think is not the case for .net)

Yup, it's not the case in .NET. In java your packaging structure is interelated with your file/folder structure. That's not such a great thing. You don't have freedom to organize it the way you want. I wonder why they chose to do that.

metadata has been introduced in java 1.5. i do not know if metadata will change this scenario. mohn could tell us more on .net packaging, and probably a lot more on meta-data.

From a little I've read, the meta-data functionality in java 1.5 is basically attributes. So you can add attributes and the jvm will inject code when you compile it.

I wrote some stuff about meta-data in my prev gigantic posts on .NET. Basically, it is some info that will be used by the runtime (clr/jvm). For ex, in .NET, you can include an attribute for Serialization for a class. When you compile your code to intermediate code, the compile will also metadata saying that this class has been marked (flagged) for serialization. The runtime will inspect this metadata at run-time and automatically serialize your class when you want it to. This is something the runtime itself implements. You can also include your own custom attributes and then use reflection to inspect it.

In .NET, everything comes down to an assembly. That assembly - be it .exe or .dll - can contain any number of classes. You deploy and execute that. You can just copy a .exe from one machine to another and execute it. As long as the machines have the CLR, nothing else is required. No registering anything, dll hell etc...

Probably a dumb question... but does every new release of Java update the JVM? Or is it just the class library that gets updated? For java 1.5, I'm pretty sure with attribute functionality, generics etc..., the jvm will have to be updated, but what about for others - like minor updates?

No comments: