Walter Gabrielsen Iii

Oh, you got JavaFX to work for you. Then you don't need this advice:

The latest version of JavaFX is here: JavaFX (openjfx.io)

And, the guide to getting started with JavaFX is here: Getting Started with JavaFX (openjfx.io/openjfx-docs/)

Pardon me if I use the older Threading methods, ie not the concurrent utilites, since I'm mostly a Java ME programmer. Here is an example of how synchronization and the wait() / notify() methods work:

First you should have a locking Object and a condition (boolean? int? whatever you want) to keep track of things (You might also add your own stuff too):private final Object waitLock = new Object(); // synchronize on this. private boolean isEndOfThread; // lets us end this thread quickly.

Here is how to set up run():synchronized(waitLock) { //while this is NOT the end repeat these actions (for also works)- loop is optional. while(!isEndOfThread) { if(?) {} // Check if it's time to do something. try { // try to wait. waitLock.wait(50); // this wakes up every 50ms - time is optional? } catch (InterruptedException ie) { // check if its time to stop and return? } } }

This would go in an update method (start/stop):synchronized(waitLock) { // Set an updated condition here. // now wake up a waiting thread. waitLock.notify(); }

This would go in an "end the thread" method:synchronized(waitLock) { // It's time to set an "end of thread" condition. isEndOfThread = true; // now wake up all/any of the threads to end them. waitLock.notifyAll(); }

Since the problem isn't obvious, you need to open the Java console where you can find any error messages of problems that happen when your browser tries to run the Applet.

It looks like you're using Ubuntu, from your screen shot, so perhaps you may find this useful: How to show java plugin console.

Have you considered what character encoding you need for the String and the Network Connection? If you have so much trouble with bytes perhaps you're sending the wrong bytes? Maybe you need just straight US-ASCII instead of Unicode?

Jayesh A Lalwani wrote:Also, applets look "out of place" in a page that has HTML elements. The way Java renders the controls doesn't look like the way browsers renders the same controls. And, you cannot use stylesheets which breaks the pardigm that web development that is moving towards. The elements on the page should only define what to show the user. How the element looks is controlled by the stylesheet. If you want to change the look & feel, all you do is update the stylesheet and your entire site changes. You can't do that with an applet. You have to incur additional development cost to modify each applet that you developed

How interesting I should write this down. I know that Java doesn't do CSS stylesheets because it has its own internal 2D drawing system. Just about all it can do, under high security, is poll its own param tags.

But Applets do have a link to the outside world. I wonder if it could be possible to use advanced CSS Selectors and Generated content, or Javascript DOM, or a server-side script to send in style information to Java.

Of course it would be extra work for the programmer to map css to Java 2D and set up the dynamic but it is possible.

Thank you so much! You've given me something to think about and add to my list of need to do things to make a high quality app.

Also, I think that your "isPaused" boolean is unsafe for multi-threading and that you should consider whether to mark it as volatile or use an java.util.concurrent.atomic.AtomicBoolean instead.

Okay, let's break your code down into smaller parts. Can you tell me why this won't work?

synchronized(this) { Thread.sleep(); }

[spoiler]Hint: What does Thread's sleep() description say about monitors, aka locks?[/spoiler]

Also, Swing has only 1 thread to do both GUI updates and Event handling.

You must use the Swing thread to do GUI updates, but take the heavy computations out of your Event Listeners or it can freeze the GUI.

It sounds like you haven't decided how your game will work yet, and you keep moving the goal post farther and farther making things harder on yourself with more work.

TimerTask's running speed depends on your CPU and the randomness of thread scheduling.

TimerTask is no more or less accurate to schedule than anything else in Java. Java isn't a real-time system so you should expect a few milliseconds of delay in either direction.

Actually there are some other places... I looked through my old Java ME bookmarks/favorite links list and here are some links in no particular order, and not checked for duplicate links with the person who posted links earlier in the thread:

Random Class -- a tip on how to use the Random class with really, very old phones using MIDP 1.0 (MIDP 1.0 didn't have a random number generator in java.lang.Math yet).

Book - Mobile Phone Programming using Java ME (J2ME) Just anoter book or something.

Java ME (J2ME) -- just another variation of the above book with chapter references?

Character Encoding Issues and the Mobile Web -- Something to do with character encoding and using your app around the world.

Focus on Java Mobility -- just an article on Java ME.

Java ME & Java Card Technology Documentation -- just Oracle's opening page for various types of Java ME (other than Java SE).

Java Platform Micro Edition Software Development Kit -- online help file from the Java SDK 3.0.

How can I reduce the memory footprint of my J2ME application -- one of the tips from the Java ME section of the "Java Tips" website.

Java Verified: Docs, FAQs and Other Info -- tells you how to get your MIDlets signed via submission to a testing company.

JBenchmark -- tests and scores java-enabled phones for performance.

The Lurker's Guide to Optimizing MIDP apps (2002-7-7) article about how to optimize your app.

M3G development tools -- this company makes tools to create 3D compatible things for Java ME.

[url=http://www.developer.nokia.com/Community/Wiki/MIDP%27s_User_Interface_Hierarchy:_Event_Handling]MIDP's User Interface Hierarchy: Event Handling[/url] article by Nokia developer.

Java API Specifications -- Nokia developer offers download links to some popular MSA APIs and some of Nokia's proprietary APIs.

Mobility Technical Articles-- Oracle's saved articles by Sun Microsystems from Java ME's earlier days.


More stuff from Sun Microsystems saved by Oracle:
Sun Mobile Device Technology - Reference
The Java ME GUI APIs at a Glance (Ignore MIDP 3.0, Oracle dropped it.)
Understanding J2ME Application Models
What are the defined J2ME system property names?
Whitepaper: Sprint /Sun Recommended Deployment Process for Java ME Technology-based Applications


Even more stuff:
J2ME Tutorial, Part 1: Creating MIDlets
Java Connected Limited Device Configuration -- an early look at CDLC the (non-graphical, graphics being MIDP) underpinning of Java ME.
Is MIDP a layer on top of CLDC -- explains the parts of Java ME.
Learning Path: MIDlet Life Cycle
-- a 2D/SVG package for Java ME/SE. (Another? Java ME+MSA already has SVG support.)
Using wait(), notify() and notifyAll() -- okay, not a Java ME tutorial, but these three methods, plus the Thread, Timer, TimerTask, and Runnable objects/interfaces, plus keywords synchronized (methods and blocks) and volatile are about all you get as far as multi-threading in Java ME.

After the book you just need to test your programming skills, until you're happy, inside of an emulator: Netbeans, Java ME SDK, or one of the brand specific Java ME developers kits.

The only other place to go is to read the guides of major cell phone brands. These would be on the developers websites (not the main websites). Use a search engine for terms such as "nokia developer", sony-ericsson, and others to find these developer sites.

Yes, Most guides skip examples on the core API of Java ME. Java ME is very, very tiny, organized, and easy to browse compared to Java SE.

These Java ME guides assume you've already been overly prepared for anything inside of the Java ME API by any, even the most basic, Java SE guides and tutorials that you've come across.

This book focuses on the MSA's optional packages. There are going to be several packages, classes, and interfaces in each optional package so you need to know what to focus on and what to ignore, and yes usually it really is just one or two methods and/or classes.

Server-side scripting takes place on the server. Its results appear on the web page. My answer is general because the actual dynamic interaction between the webpage and the server depends on the language you choose to use, how you set up the controls on the web page, and how users interact with your page, Since often web hosts support several languages there is no one right answer.

You said that your website has Java on the server side, do know how you could use that?

You can also look at the tutorials for a few Server-side languages at W3Schools Online Web Tutorials, under the "Server Scripting" section.

You can also look things up on the Documentation sites of whatever language you're thinking about using, example PHP Documentation site.

Tim Moores wrote:

Walter Gabrielsen Iii wrote:I still maintain that consumers were, in the past few years, buying Macs from Apple with very old versions of Java pre-installed on them.

Let's look at the facts of that, then. Java 5 came out in 2004, and was available beginning with OS X 10.4 which came out in 2005. Java 6 came out in 2006, and was available beginning with OS X 10.5 which came out in 2007. Java 7 came out in 2011 and is indeed so far not available in a released version for OS X - Java 6 still has to do; that can't possibly be what you mean, can it? So which are these "very old versions" "in the past few years" you speak of?

Yes, Apple placed new Java releases to go with its release of new versions of Mac OS X. And Apple hates its customers and drops its support for older Mac OS X versions whenever it releases a new one. You need the new OS to use the new Java version -- If you got an older Mac OS X version on your iMac you might be forever trapped using the version that came with your system (unless you buy the new version of Mac OS X). Also Mac OS comes with previous versions of the Java engine inside of its system folder so if just one of them has a weakness attackers could exploit it.

After looking it up on everymac.com -- the site that lists tech specs for all Macs ever made, My old iMac that I bought new in the Apple web store in 2003 it turns out that it was actually the Summber 2001 iMac model (which was still the latest iMac model at the time I bought it) it came with Mac OS 10.1 and which I later upgraded to Mac OS 10.2 which afterwards had in its system folder: both Java SE 1.3 and 1.4. I couldn't upgrade Java beyond that because it required a later version of Mac OS X.

I can't tell by looks what model my Aunt's iMac was, based on appearance, because all of the big-screen iMacs on everymac.com from about late-2007 to the newest iMac on Apple's website today all looks the same to me. I'm going to say she bought it around 2010-ish and it came with Mac OS 10.4 so it should have had at least Java SE 5 -- it might have been a refurbished model. It did also come with Java 1.4 in the system folder.

That Java 5 was actually available in 10.4 -- That's actually good for me to know since I base my programming decisions on compatibility, ability to port to Java ME, and my experiance with web standards (where it takes about 3-5 years (sometimes even 10 years) for new technology to reach the mainstream market not just geeks who update their plug-ins and OS regularly). I've seen how people who don't know about technology, and sometimes even those who do, usually end up with old technology even when they go out to buy a new computer.

Jayesh A Lalwani wrote:Are there any specific examples of things that can be done better in Swing?

In a word: Threads. I don't know how far other client-side scripts have advance, but, at least years ago, Java's main advantage for interactive content was its native support for multi-threading.

On the other hand, Applets are known keyboard traps (you can tab into Applets but not out of them) which is a problem for creating accessible web content that relies on keyboard-only access.

That's why Applets should only ever be used on their own specialty pages where the Applet is, in fact, the main purpose of the page -- That way people can always browse away from the page or, as a last resort, close the browser window to escape from the Applet.