Build in netbeans uses source target other then 1.1

[GoogleCodeExporter]

What steps will reproduce the problem?
1. If there is a Java source file with import java.io.*; and some code is 
referring to java.io.ByteArrayInputStream class.
2. Compile the codename1 project.
3. And send the project for j2me build.

What is the expected output? What do you see instead?

Ideally the build should get compiled, but on build server it gives error:
can't find referenced class java.io.FilterInputStream

What version of the product are you using? On what operating system?
I am testing with the private beta version of codenameone in Mac OS X using the 
following file:
CodenameOne_Mac_20120218.dmg 

My OS is Mac Lion. (Version 10.7.3)

Please provide any additional information below.

It seems, the -pre-compile target is overridden in the generated build.xml file 
in the netbeans codenameone project. This file has source and target for the 
javac target set to 1.1 and it generates the class files in build/tmp dir. 
However later the do-compile target compiles the source files again and 
generates the files in build/classes dir. 

the class file generated in the build/tmp dir does not contain reference to 
classes not supported in CLDC1.1 aPI. However for the same source file, the 
class file generated in build/classes dir contains reference to the unsupported 
java.io.FilterInputStream class and hence this class file fails during server 
build.

Original issue reported on code.google.com by nir...@nvsoft.com on 3 Mar 2012 at 12:06

[GoogleCodeExporter]

I ran into this issue but I am a bit at a lost of how to properly workaround 
it. 
The workaround is just not to use the close method which is the major culprit. 
Use com.codename1.io.Util.cleanup() which will close any resource without 
throwing any exception. 
I would love to offer a better and more portable solution but the problem isn't 
with the -target but rather with the bootclasspath. Netbeans lets us customie 
the bootclasspath (through undocumented means) but that breaks debugging (a 
rather important feature). 
I think this will work properly with the Eclipse integration which according to 
Chen has better support for "weird" classpath hacks like ours.

I'm marking this as accepted since it is a bug and I do want to fix it, I would 
appreciate ideas on the matter.

Original comment by shai.almog on 4 Mar 2012 at 7:54

• Changed state: Accepted

[GoogleCodeExporter]

Hi Shai,

Regarding the work-around, I tried changing the "-pre-compile" target in the 
codename1 generated build.xml file to compile and generate the class files in 
build/classes directory. So the change here is instead of using the "build/tmp" 
dir, use the "build/classes" dir. This way, later when netbeans build file 
(build-impl.xml) finds that the class files are already there for the source in 
the build/classes dir it does not recompile them. This way I am able to get the 
build to work on the build-server. 

This may not be to correct solution, but as a temporary workaround it would 
allow the build to succeed on server without changing the source code.

Thanks,
Nirmal

Original comment by nir...@nvsoft.com on 5 Mar 2012 at 6:00

[GoogleCodeExporter]

That workaround unfortunately breaks debugging and lots of other features 
within the Netbeans. 

However, thinking in this direction I have a workaround in the build XML I can 
think of that might actually work.

Adding the target:
    <target name="compileJ2ME_RIM">
        <mkdir dir="build/classes" />
        <javac destdir="build/classes"
            source="1.1"
            target="1.1"
            bootclasspath="CLDC11.jar"
            classpath="${javac.classpath}:${build.classes.dir}">
            <src path="${src.dir}"/>
        </javac>        
    </target>

And then changing the RIM/J2ME build to server targets as such:

    <target name="build-for-rim-device" depends="clean,copy-rim-override,compileJ2ME_RIM,jar,clean-override">
        <codeNameOne 
            jarFile="${dist.jar}"
            displayName="${codename1.displayName}"
            packageName = "${codename1.packageName}"
            mainClassName = "${codename1.mainName}"
            version="${codename1.version}"
            icon="${codename1.icon}"
            vendor="${codename1.vendor}"
            subtitle="${codename1.secondaryTitle}"

            targetType="rim"
            sigtoolDb="${codename1.rim.signtoolDb}"
            certPassword="${codename1.rim.certificatePassword}"
            sigtoolCsk="${codename1.rim.signtoolCsk}"
            />
        <delete>
            <fileset dir="build/classes" includes="**/*.class"/>
        </delete>
    </target>

    <target name="build-for-j2me-device" depends="clean,j2me-native-theme-init,copy-j2me-native,copy-j2me-override,compileJ2ME_RIM,jar,clean-j2me-native,clean-override">
        <codeNameOne
            jarFile="${dist.jar}"
            displayName="${codename1.displayName}"
            packageName = "${codename1.packageName}"
            mainClassName = "${codename1.mainName}"
            version="${codename1.version}"
            icon="${codename1.icon}"
            vendor="${codename1.vendor}"
            subtitle="${codename1.secondaryTitle}"
            targetType="me"            
            />
        <delete>
            <fileset dir="build/classes" includes="**/*.class"/>
        </delete>
    </target>
    <target name="-pre-init">
        <property name="application.args" value="${codename1.packageName}.${codename1.mainName}"/>
    </target>

I'm assigning the issue to Chen so he can integrate it into the plugin.

Original comment by shai.almog on 6 Mar 2012 at 1:30

[GoogleCodeExporter]

Issue 73 has been merged into this issue.

Original comment by shai.almog on 7 Mar 2012 at 9:56

[GoogleCodeExporter]

I gave this a try for issue 73 but got the same error.  I had to make a 
modification to your build snippets above, appears you have some new j2me theme 
targets:

Where you have:

<target name="build-for-j2me-device" 
depends="clean,j2me-native-theme-init,copy-j2me-native,copy-j2me-override,compil
eJ2ME_RIM,jar,clean-j2me-native,clean-override">

I used:

<target name="build-for-j2me-device" 
    depends="clean,copy-j2me-override,compileJ2ME_RIM,jar,clean-override">

Original comment by 1815...@coolman.ca on 7 Mar 2012 at 6:58

[GoogleCodeExporter]

Original comment by cf27...@gmail.com on 12 Mar 2012 at 9:58

• Changed state: Fixed