[groovy-user] is it possible to tell groovy itself to compile for 1.5
Yegor Bryukhov
in Netbeans you can specify for each project what version of java to
compile for, so even if Netbeans is run using 1.6, you can still
produce jars for 1.5.
With groovyc executed form NB, it seems to use the java version used
to run Netbeans, one can only specify version for nested javac calls
in joint compilation.
So I have to start Netbeans using 1.5 to get 1.5 code.
This is a bit inconvenient (and NB 6.1 is much slicker under 1.6 :)
Is there a way to specify the target version in groovyc ant-task?
--
Best regards,
Yegor
__________________________________________________________
Yegor Bryukhov,
Research Associate
Center for Algorithms and Interactive Scientific Software
City College of New York
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Danno Ferrin
<javac source="1.5" target="1.5"/>
</groovyc>
------------------------------------------------------
I'm Danno Ferrin, and I approved this message.
Yegor Bryukhov
> <groovyc ... your stuff>
> <javac source="1.5" target="1.5"/>
> </groovyc>
>
as far as I understand, it will only instruct javac about the target
version for .java files,
I want the same thing for groovyc for .groovy files
Jochen Theodorou
> On Mon, Mar 17, 2008 at 3:21 PM, Danno Ferrin <danno....@shemnon.com> wrote:
>> <groovyc ... your stuff>
>> <javac source="1.5" target="1.5"/>
>> </groovyc>
>
> as far as I understand, it will only instruct javac about the target
> version for .java files,
> I want the same thing for groovyc for .groovy files
do you mean if the bytecode generated by groovyc is for a java4 or java5
VM? Then no, there is no such switch, and currently no such switch is
needed as long as you do not use generics or annotations. Or define an
enum in Groovy.
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
Stand Trooper
timo
Jochen Theodorou
> So what if you do use generics or enums in your Groovy code?
then the code generated becomes java5 bytecode based code, because you
can not define an enum in java4 bytecode or make real use of generics in
a java4 VM.
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
---------------------------------------------------------------------
Stand Trooper
thx blackdrag
timo
Randall R Schulz
> Stand Trooper schrieb:
> > So what if you do use generics or enums in your Groovy code?
>
> then the code generated becomes java5 bytecode based code, because
> you can not define an enum in java4 bytecode or make real use of
> generics in a java4 VM.
Then I take it the class file version number is chosen accordingly?
> bye blackdrag
Randall Schulz
Yegor Bryukhov
I run NB using java6 but the target for the is java5. I have a groovy
class DecimalRenderer extending
javax.swing.table.DefaultTableCellRenderer.
When I try to run it, NB uses java5, and I get an exception:
java.lang.NoClassDefFoundError: java/awt/Component$BaselineResizeBehavior
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2395)
at java.lang.Class.getDeclaredMethods(Class.java:1763)
at org.codehaus.groovy.reflection.CachedClass$1.run(CachedClass.java:149)
at java.security.AccessController.doPrivileged(Native Method)
at org.codehaus.groovy.reflection.CachedClass.getMethods(CachedClass.java:146)
at groovy.lang.MetaClassImpl.populateMethods(MetaClassImpl.java:268)
at groovy.lang.MetaClassImpl.fillMethodIndex(MetaClassImpl.java:215)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2469)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getGlobalMetaClass(MetaClassRegistryImpl.java:248)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.access$100(MetaClassRegistryImpl.java:45)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl$LocallyKnownClasses.getFromGlobal(MetaClassRegistryImpl.java:112)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl$LocallyKnownClasses.getMetaClass(MetaClassRegistryImpl.java:88)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl$MyThreadLocal.getMetaClass(MetaClassRegistryImpl.java:356)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:260)
at org.codehaus.groovy.runtime.InvokerHelper.getMetaClass(InvokerHelper.java:728)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.initMetaClass(ScriptBytecodeAdapter.java:792)
at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1094)
at org.codehaus.groovy.runtime.InvokerHelper.invokeStaticMethod(InvokerHelper.java:800)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeStaticMethodN(ScriptBytecodeAdapter.java:212)
at com.caiss.stat.utils.groovy.DecimalRenderer.<init>(DecimalRenderer.groovy)
BaselineResizeBehavior seems to be java6 class, if I use java5 to run
NB, then everything goes smoothly.
From this I conclude, that when groovyc is executed with sdk6, the
results are different from when it is executed with sdk5.
--
Best regards,
Yegor
__________________________________________________________
Yegor Bryukhov,
Research Associate
Center for Algorithms and Interactive Scientific Software
City College of New York
---------------------------------------------------------------------
Danno Ferrin
Also, what static method might it be calling? (i notice it's missing a line number, could be a class field initializer)
This feels more like a NB support issue than a groovy compiler causing the problems, it's a question of what NB is providing to the groovy runtime (such as a class lib that uses BaselineResizeBehavior). Full dumps of the ant execution includeing classpaths would be enlightening. Are you using the 6.1 groovy support? Could be some issue with the daily code that hasn't been exercied quite enough to expose the errors.
--Danno
Jochen Theodorou
> On Monday 17 March 2008 16:54, Jochen Theodorou wrote:
>> Stand Trooper schrieb:
>>> So what if you do use generics or enums in your Groovy code?
>> then the code generated becomes java5 bytecode based code, because
>> you can not define an enum in java4 bytecode or make real use of
>> generics in a java4 VM.
>
> Then I take it the class file version number is chosen accordingly?
yes
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
---------------------------------------------------------------------
Jochen Theodorou
> Well, here is what I observe:
> I run NB using java6 but the target for the is java5. I have a groovy
> class DecimalRenderer extending
> javax.swing.table.DefaultTableCellRenderer.
> When I try to run it, NB uses java5, and I get an exception:
If it where a bytecode version problem, then the message would be no
NoClassDefFoundError, but an error with an message like this:
bad class file: [...] class file has wrong version 49.0, should be 48.0
[...]
> BaselineResizeBehavior seems to be java6 class, if I use java5 to run
> NB, then everything goes smoothly.
Danno is the expert here...
> From this I conclude, that when groovyc is executed with sdk6, the
> results are different from when it is executed with sdk5.
being executed with sdk6 and generating code for a special sdk are two
different issues. The normal code has no special java6 features that are
used automatically. We have a plugin mechanism for java5, so the code
runs on java4 too...
Yegor Bryukhov
> I am confused, do you run the compiled class within the context of netbeans
> or is this the behavior of the compiled class outside of the context of
> netbeans as a whole? Are you using the
>
It's a behavior of a custom Netbeans Platform application, my Groovy
classes are a part of it.
> Also, what static method might it be calling? (i notice it's missing a line
> number, could be a class field initializer)
missing line number is the way Groovy 1.5.4 prints it, as far as I
understand, it must be the class constructor invoking
DefaultTableCellRenderer's constructor, there are no field
initializers in my class.
Observation: DefaultTableCellRenderer is a subclass of JLabel,
according to Sun, in jdk6, that problematic BaselineResizeBehavior is
a nested class of JLabel (???). Could it somehow be inlined?
Does it matter what JDK groovyc saw while compiling groovy files? I'm
confused because my class only uses DefaultTableCellRenderer which
exists in both JDKs and BaselineResizeBehavior is a detail of internal
implementation of DefaultTableCellRenderer, why does it come up at
all?
>
> This feels more like a NB support issue than a groovy compiler causing the
> problems, it's a question of what NB is providing to the groovy runtime
> (such as a class lib that uses BaselineResizeBehavior). Full dumps of the
> ant execution includeing classpaths would be enlightening.
http://yegor.org/ant-dump-modelImpl.zip has 4 files - the results of
"ant -debug" and "ant -verbose" on my module with JAVA_HOME set to
jdk5 and jdk6
I'm totally confused after looking into these files myself, I don't
know enough about this area :(
> Are you using
> the 6.1 groovy support? Could be some issue with the daily code that hasn't
> been exercied quite enough to expose the errors.
>
Actually I've overriden the netbeans default javac-based compile task
to use groovyc instead, see
http://www.netbeans.org/nonav/issues/showattachment.cgi/58456/groovy-compile-impl.xml
Danno Ferrin
Does it matter what JDK groovyc saw while compiling groovy files? I'm
confused because my class only uses DefaultTableCellRenderer which
exists in both JDKs and BaselineResizeBehavior is a detail of internal
implementation of DefaultTableCellRenderer, why does it come up at
all?
In this instance, JDK 1.6 added some public basline methods that depend on new JDK 1.6 classes in the signature.
So, solutions aren't very good unless you can get NetBeans to fork the ant build with a 1.5 JVM. None of the versions of groovyc floating around in SVN support this case either, Ant running on JDK 1.6 but needing to compile against 1.5 class files. This may be JIRA worthey to specifty a forked JVM to the groovyc task.
One last posibility is if you could put the 1.5 JDK rt.jar in the classpath of toe groovyc task. It may prevent the JLabel from the primordial class loader from being instantiated and reflected, but the other core java classes may present issues.
Yegor Bryukhov
> that a groovy file is compiled against does matter, a whole lot. The reason
> being Groovy adds a bunch of convenience methods to the compiled class to
> call every possible method on the class and its parents, there are deep
> desing based reasons as to why the Meta-Object Protocol needs this, short
> answer there is no way this would change in the 1.5 line and extremely
> unlilely to change before a 2.0 release (remember, 1.7, 1.8, and 1.9 are
> also on the roadmap).
I see.
> So, solutions aren't very good unless you can get NetBeans to fork the ant
> build with a 1.5 JVM. None of the versions of groovyc floating around in
> SVN support this case either, Ant running on JDK 1.6 but needing to compile
> against 1.5 class files. This may be JIRA worthey to specifty a forked JVM
> to the groovyc task.
well, it's not really a big problem for me, it was mostly out of curiosity.
(And if not for Mac OS X compatibility, I would not even bother with java5)
But I do think that there has to be a warning somewhere saying that
Groovy-produced bytecode is not guaranteed to be backward-compatible
with respect to used JVMs.
Is the last part of the previous sentence a good enough summary for JIRA issue?
--
Best regards,
Yegor
__________________________________________________________
Yegor Bryukhov,
Research Associate
Center for Algorithms and Interactive Scientific Software
City College of New York
---------------------------------------------------------------------
Danno Ferrin
> Ok, did some digging. The short answer is that the version of a library
> that a groovy file is compiled against does matter, a whole lot. The reason
> being Groovy adds a bunch of convenience methods to the compiled class to
> call every possible method on the class and its parents, there are deep
> desing based reasons as to why the Meta-Object Protocol needs this, short
> answer there is no way this would change in the 1.5 line and extremely
> unlilely to change before a 2.0 release (remember, 1.7, 1.8, and 1.9 are
> also on the roadmap).
I see.
> So, solutions aren't very good unless you can get NetBeans to fork the ant
> build with a 1.5 JVM. None of the versions of groovyc floating around in
> SVN support this case either, Ant running on JDK 1.6 but needing to compile
> against 1.5 class files. This may be JIRA worthey to specifty a forked JVM
> to the groovyc task.
well, it's not really a big problem for me, it was mostly out of curiosity.
(And if not for Mac OS X compatibility, I would not even bother with java5)
But I do think that there has to be a warning somewhere saying that
Groovy-produced bytecode is not guaranteed to be backward-compatible
with respect to used JVMs.
Is the last part of the previous sentence a good enough summary for JIRA issue?
Jochen Theodorou
[...]
> well, it's not really a big problem for me, it was mostly out of curiosity.
> (And if not for Mac OS X compatibility, I would not even bother with java5)
> But I do think that there has to be a warning somewhere saying that
> Groovy-produced bytecode is not guaranteed to be backward-compatible
> with respect to used JVMs.
> Is the last part of the previous sentence a good enough summary for JIRA issue?
I Java you have, if you want to ensure that a class compiled with java5
does run under java4 provide the class files for java4 instead of java5
(hint: cross compiling). In Groovy it is more or less the same, but with
the major difference that any nonprivate method may cause such a
problem. That is by design. We are not lucky about that, but I currently
see no way around this problem. We could try to hide it more, but if
certain features are used, then there is no way around it. If the
reflection API would be a bit less restricted or if certain bytecodes
would be less restricted we would have ways around the issue, but that
is currently not the case.
so you can fill an JIRA issue, i is just that you should not expect any
action on this soon. We just have no idea to avoid this kind of issue atm
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
---------------------------------------------------------------------
Yegor Bryukhov
> action on this soon. We just have no idea to avoid this kind of issue atm
>
oh, that's totally ok, I'm sure you have more useful thing to spend time on.
Actually, I don't expect it to be fixed at all, the only reason to
file a JIRA issue is to keep records.
--
Best regards,
Yegor
__________________________________________________________
Yegor Bryukhov,
Research Associate
Center for Algorithms and Interactive Scientific Software
City College of New York
---------------------------------------------------------------------
Jochen Theodorou
>> so you can fill an JIRA issue, i is just that you should not expect any
>> action on this soon. We just have no idea to avoid this kind of issue atm
>
> oh, that's totally ok, I'm sure you have more useful thing to spend time on.
> Actually, I don't expect it to be fixed at all, the only reason to
> file a JIRA issue is to keep records.
sure, go on, I just wanted to warn you that resolving this issue is not
to be expected in the near future... if ever.. there might be a solution
for jdk7, but this depends on so many things that I can not make any
promises
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
---------------------------------------------------------------------