aspose file tools*
The moose likes Java Micro Edition and the fly likes target release conflicts with default source Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Mobile » Java Micro Edition
Bookmark "target release conflicts with default source" Watch "target release conflicts with default source" New topic
Author

target release conflicts with default source

Martin Felando
Greenhorn

Joined: Jun 10, 2004
Posts: 5
Building "HelloToolkit"
javac: target release 1.1 conflicts with default source release 1.5
com.sun.kvem.ktools.ExecutionException
Build failed

I need help in defining the problem and solution, any suggestions would be appreciated.
Jason Fox
Ranch Hand

Joined: Jan 22, 2004
Posts: 114
Could you post your javac commands / build script? In the meantime, are you compiling with the -target 1.1 flag?
Martin Felando
Greenhorn

Joined: Jun 10, 2004
Posts: 5
Here's my source code, it's from "J2ME Game Programming":

import javax.microedition.midlet.MIDletStateChangeException;
import javax.microedition.lcdui.*;

/**
* An example used to demonstrate how to access, and then display, a property
* value set within a JAD file.
*
* @author Martin J. Wells
*/

public class HelloToolkit extends javax.microedition.midlet.MIDlet
implements CommandListener
{
protected Form form;
protected Command quit;

/**
* Constructor for the MIDlet which instantiates the Form object
* then uses the getAppProperty method to extract the value associated with
* the "Message" key in the JAD file. It then adds the value as a text field
* to the Form and sets up a command listener so the commandAction method
* is called when the user hits the Quit command. Note that this Form is not
* activated (displayed) until the startApp method is called.
*/
public HelloToolkit()
{
//create a form and add our components
form = new Form("My Midlet");

//display our message attribute
String msg = getAppProperty("Message");
if (msg != null)
form.append(msg);


// create a way to quit
form.setCommandListener(this);
quit = new Command("Quit", Command.SCREEN, 1);
form.addCommand(quit);
}

/**
* Called by the Application Manager when the MIDlet is starting or resuming
* after being paused. In this example it acquires the current Display object
* and uses it to set the Form object created in the MIDlet constructor as
* the active Screen to display.
* @throws MIDletStateChangeException
*/
protected void startApp() throws MIDletStateChangeException
{
// display our form
Display.getDisplay(this).setCurrent(form);
}

/**
* Called by the MID's Application Manager to pause the MIDlet. A good
* example of this is when the user receives an incoming phone call whilst
* playing your game. When they're done the Application Manager will call
* startApp to resume. For this example we dont need to do anything.
*/
protected void pauseApp()
{
}

/**
* Called by the MID's Application Manager when the MIDlet is about to
* be destroyed (removed from memory). You should take this as an opportunity
* to clear up any resources and save the game. For this example we dont
* need to do anything.
* @param unconditional if false you have the option of throwing a
* MIDletStateChangeException to abort the destruction process.
* @throws MIDletStateChangeException
*/
protected void destroyApp(boolean unconditional)
throws MIDletStateChangeException
{
}

/**
* The CommandListener interface method called when the user executes
* a Command, in this case it can only be the quit command we created in the
* consutructor and added to the Form.
* @param command
* @param displayable
*/
public void commandAction(Command command, Displayable displayable)
{
// check for our quit command and act accordingly
try
{
if (command == quit)
{
destroyApp(true);

// tell the Application Manager we're exiting
notifyDestroyed();
}
}

// we catch this even though there's no chance it will be thrown
// since we called destroyApp with unconditional set to true.
catch (MIDletStateChangeException me)
{
}
}
}

Your question: "In the meantime, are you compiling with the -target 1.1 flag?" In all honesty Jason, I don't understand the question. When I saw "1.5" I thought of my Java(TM) 2 Runtime Environment, Standard Edition
Version 1.5.0

My thinking is that I have to restart my setup, that I've incorrectly setup my path, crosspath, or reinstall my environment and tools. I have Studio Mobility 6, explored it for the first time today. I want to make sure I have Mobility 6 setup properly and if I can't execute a midlet in the Toolkit I know I'm in trouble.
Jason Fox
Ranch Hand

Joined: Jan 22, 2004
Posts: 114
I've had similiar problems in the past, though mine revolved around getting the preverifier to work, but the error message was very similiar, in any case, try compiling with the 'target -1.1' flag and see if that helps. Let me know.
Martin Felando
Greenhorn

Joined: Jun 10, 2004
Posts: 5
Thank you, Jason. I switched to my Toolkit 2.0 and CLDC 1.1 and saved the source flag in Toolkit 2.0 and successfully built and ran HelloToolkit.

Quick question: I downloaded Polish, I use Windows XP. Is Polish something I could find useful to integrate with Studio Mobility 6 and the Toolkit? Polish needs Ant/Apache. Any thoughts on Polish?
 
jQuery in Action, 2nd edition
 
subject: target release conflicts with default source