Saurabh M Sirdeshmukh

Kengkaj Sathianpantarit wrote:About Applets, I don't know why it's not popular, there is nothing wrong with it, except bad marketing, and huge size of JRE.
I've seen many Applets that work very well. And I've seen a commercial Applet that runs on browser and have rich UI long time ago, at that time nobody talks about "AJAX". Applets are so powerful, they are more or less Java applications on web browser.

Sathya/Kengkaj,
With respect to our discussion on JavaFX and applets , I came across the James Gosling interview on web on sidelines of JavaFX launch at JavaOne conference... Below are some excerpts. I would be glad if you guys can throw some more light on what Gosling says on applets and Microsoft v/s Sun lawsuit affecting applets.

Excerpts:

Stephen Shankland (SS):It seems to me this is (JavaFX) returning to the roots of Java, an interactive Web experience. Is that an accurate statement?

James Gosling (JG):It's very much an accurate statement. The applet (small downloadable Java programs) technologies and 2D graphics and Swing (Java graphical interface technology) are all about doing that. Applets are a technology that people have tended not to use for no particularly good reason. There is the legal history with things being a little bit uglier than they should have been...

SS:Microsoft vs. Sun and the antitrust (lawsuit)?

JG:That was really ugly. It really killed the whole applet thing for a bunch of years, but one of the not quite well-understood facts is that applets still work really well.

SS:So why are you guys doing this now? It seems a lot of this action is happening now with Adobe's Flash and perhaps Microsoft's Silverlight.

JG:This is certainly in that space. The Java platform has got a huge installed base, and the depth of what you can do in the Java platform is really huge. If you compare what you can do with Java coded in an applet, it's far more than what you can do with things like Flash. But the issue for us really has been that while the capability was there, it's been difficult to do. So we've been on this mad tear to make the easy stuff easy. We've gotten pretty good at making the hard stuff possible, and over the last couple years we've focused pretty heavily on the enterprise world and making (it easy to build) these giant enterprise apps.

Thanks and looking forward to comments on this forum.

Sathya,
Thanks a Lot...
Just as you mentioned about JavaFX not picking up as expected, It compels me to think where Java team went wrong or rather didn't focus on client side technologies?
I mean Java entered with the bang on the attractive Applet concept some 13-14 years back.. Portability being the key.
Now Sun guys always had vision n thought ahead of times. Don't you think the same guys capable of delivering Applet concept could have come up with the client side technology(runtime) for developing RIAs.They were very much capable, but I think they focused on server side technologies alone like servlet/ejb etc.
No doubt Java is dominant n ultimate choice with many application servers built around it.But as result of neglecting client side technologies,in mean time Flash/Silverlight came up with their runtimes for RIAs. And now they have large developer base n JavaFX has huge task to survive n grow against them.

What do you think?Let me know Sathya n all the other friends over here....

Guys,
cracked the SCMAD exam last week. got 80% score.
Special thanks to Sathya/Ko Ko n all... their book helped pretty much.
I would have liked had there been more focus and in depth coverage of:
-synchronization of repaint cycles and UI system thread issues,
-practical approach for implementing networked mobile apps,especially how to use Push Registry to build client-server apps over web,
-WMAPI in context of Push Registry.
I know the book's primary objective is to let the examinees clear the exam successfully, but the above mentioned details would help clearly understand the concept.

I went through all the Sun Java ME specs: midp 2.0/cldc 1.0-1.1/wmapi 1.1/mmapi 1.1 pretty rigorously.
Also many Java ME links n FAQs on Sun's website helped a lot. Sun's CLDC Hotspot Implementation paper also gives insights into many practical aspects of Java Me platform.
Guys.. I am thinking of getting some expertise in JavaFX along with Java ME.. What you say?

And it really hurts to see Sun being acquired by other company... but I still would have liked IBM acquiring Sun rather than Oracle.
I have been a fan and admirer of Sun's technology, R&D and Engineering vision...

Thanks n Warm Regards to All...

Hey Friends,
I gotta WTK2.5.2.

I have compiled program for CLDC 1.1 as:

C:\WTK2.5.2\bin> javac -bootclasspath ..\lib\cldcapi11.jar Demo.java
I hava java se 1.6.

now I gotta Demo.class file, I wanna run it over CLDC1.1 Reference Implementation i.e KVM alone.
How can I do it, I dont wanna go for MIDlet and Emulator.Wanna test over CLDC alone.
But the problem is where can I find KVM in my installation directory?
thinking that, its may not be coming as a stand-alone in WTK, I am
trying to download from Sun website : http://java.sun.com/products/cldc/.
Do i need to sign any License Agreement?Clicking above link takes me here:
http://www.sun.com/software/opensource/index.jsp.
But i can't find any license/ terms signing links on this page.

OR-

Does jvm of java se allow me something like "Bootpath" to be passed from command-line and so that i can specify the location for CLDC classes to bootstrap classloader.

Thanks.

Hi Sathya,
It's privilege to here from you. Already, using your book for the exam.

What I wanted to say is: if CLDC+MIDP+Optional Packeges(if necessary) are all to be implemented, why only implementation of CLDC is termed as KVM.
Why this overall implementation is not termed as RI for this particular stack?

Another thing: are there any areas you know where we program on bare configuration without using any profile?

Thanks Pretty Much

Hi Folks,
I am preparing for SCMAD exam.
I was deep into the details of CLDC n MIDP implementations.

Across majority Java ME literature, I came across the definition of Configuration as:

The KVM + core library/classes implementation.

n Profile is defined as:

additional apis provided to leverage the features of particular category of devices on top of configuration chosen

.
Now, it only seems logical that the according to the physical properties of the deivce(like ROM/RAM/Display/Processor speed etc) the spec/JCP guys would be deciding the core classes to be included n eventually implemented by the it's RI/JVM.

Now if the JVM implements the configuration, who's gonna implement the additional profile APIs? Obviously, there needs to be an implementation of the profile. But even official Sun specs say that only configuration is the one who bothers about KVM implementation. There's some mismatch. I believe the Configuration n Profiles are pretty tightly coupled. The so called modularization/flexibility of Java ME world is, I believe exaggerated. The reason is:
1. The FAQ on Sun website about MIDP 2.0 implementation says:

The memory footprint for MIDP 2.0 along with CLDC implementation is: 0.8 to 1MB

2.I read paper- 'CLDC HotSpot implementation'(Sun Microsystems). It says that MIDP implementation is integrated with CLDC HotSptot by

Sun Java Wireless Agent

.

This gives me impression that EITHER:
the CLDC+MIDP are often implemented together in a form of KVM
OR:
We need to augment/integrate/attach to the KVM, the implementation of MIDP.
If this is the case, then why all the Java ME literature/spec world only mentions the KVM/JVM in context of configurations.After all, the profile specific APIs are also to be implemented. Typically, what I perceive JVM/RI as:

The piece of software having the mapping of instructions in the from of bytecodes to their corresponding instructions for underlying platfrom+ API implementor+ implementor of other stuff(GC,Thread Management etc.)

.

One of the paragraphs, in it's description of JVM on Wikipedia mentions (http://en.wikipedia.org/wiki/JVM#Bytecode_instructions) :

The aim is binary compatibility. Each particular host operating system needs its own implementation of the JVM and runtime. These JVMs interpret the byte code semantically the same way, but the actual implementation may be different. More complicated than just the emulation of bytecode is compatible and efficient implementation of the Java core API that has to be mapped to each host operating system

.

This is also evident from the expectations of CDC implementations: It asks nearly full-fledged JVM to be implemented. Plus there would be profile APIs atop, so overall RI would be JVM+Profile API/behavior implementations= full JVM for this combination.

Let me know guys. I am waiting for some rigorous discussion on this topic.

Also if devices are getting more n more memory/processor speed, wont it ultimately turn out to be Java SE with some alterations to take care of underlying wireless medium n architecture?

Friends,
I want to know does repaint() call the paintComponent() method internally on the same component we are operating.
Here's the snippet of my code:

class MyPanel extends JPanel{

//som code

//on clicking a button in panel change the panel color

ActionListener aListener= new ActionListener(){

public void actionPerformed(ActionEvent ae){
setbackground(Color.BLUE); // change the color of the panel
repaint();
}
};

//overriden paintComponent
public void paintComponent(Graphics g){
System.out.println("Enter paintComponent()");
super.paintComponent(g);
System.out.println("Exit paintComponent()");
}

}

what i expect is: to have

Enter paintComponent()
Exit paintComponent() on standard output when i click some button on the panel.
I have overriden the paintComponent() n wanna know if repaint() calls it. but i didn't get the above expected output.
Lemme Know
Thanks

Hey Henry, thanks a lot.
and can you please tell me what does the terms: "synchronous" n "asynchronous" in context of exceptions.
and how these terms are expected to be interpreted in background of java threads?
n by the way are you the same Henry Wong, author of Java threads book? privilig to here from you
thanks.

Bert Bates wrote:Hi Guys,

Thanks for the encouragement! We'd really, really like to write an ME book! I just responded in another thread that my guess is the reason ME hasn't taken off is because the phone manufacturers can't seem to agree on any standards, so deploying an app across different phones is such a big pain!

What surprises me is that big companies don't pick a type of phone for their employees, and write apps for that specific phone?

Bert

I belive it's evident from the kind of structure/architecture is there for j2me in terms of configurations and profiles...
but dont you think that ultimately its gonna end up with java SE with many-fold increase in cell-phone processing power and memory capacities.

But I wonder why would it be a issue when java was initially created with this kinda purpose in mind! may be java guys are yet to ascertain the lowest possible n workable uniform api across cluttered fragment of hand-held devices o/s n hardware. but then they have also released spec for Real-time Java! I dont get this.

Guys, I came across many apis suggesting that interrupt() is d best way to terminating a thread execution especially those performing blocking operations. i pretty much agree with it n also helpful for doing any clean-up act before ending thread execution. but what i e wanna ensure from all you guys is: how actually that thread wil end? is it by returning from the run()? becoz stop() n destroy() are to b ultimately avoided...


2nd: i believe I/O in java is synchronous or blocking...if there is just a single thread n it does read() in System.in then it wil definitely block.if i wanna implement it asynchronousely then I can do this reading in another thread while doing some work in current thread?
Is this approach right?
lemme know