Re: Upcoming releases

[Remi Forax]

ASM is backward compatible since ASM 4.

Rémi

- Mail original -
> De: "Jochen Theodorou" 
> À: "dev" 
> Envoyé: Mardi 12 Novembre 2019 23:15:40
> Objet: Re: Upcoming releases

> On 12.11.19 08:14, Cédric Champeau wrote:
>> Just saying that using external ASM is an option now. Back then we had
>> to repackage because ASM wasn't backwards compatible so triggered all
>> sorts of problems when another library used it with a different version.
>> This is not the case now since you always pass in the ASM version in the
>> constructor now, so ASM knows what visitor to use.
> 
> You remember the ASM version this was? Was it ASM 5?
> 
> bye blackdrag

Re: Upcoming releases

[Jochen Theodorou]

On 12.11.19 08:14, Cédric Champeau wrote:

Just saying that using external ASM is an option now. Back then we had
to repackage because ASM wasn't backwards compatible so triggered all
sorts of problems when another library used it with a different version.
This is not the case now since you always pass in the ASM version in the
constructor now, so ASM knows what visitor to use.


You remember the ASM version this was? Was it ASM 5?

bye blackdrag

Re: Problem with org.codehaus.groovy.tools.RootLoader

[Jochen Theodorou]

On 12.11.19 11:58, Kerridge, Jon wrote:
[...]

The problem is that the Groovy version when run as three separate
processes creates the error

org.codehaus.groovy.tools.RootLoader cannot be cast to
jcsp.net2.mobile.DynamicClassLoader.

This error comes from deep in the jcsp library.  DynamicClassLoader uses
the Java(8) SystemClassLoader.

The code is derived from a part of jcsp which deals with class loading
in a parallel system run on multiple nodes on separate workstations.

The idea, which works, is that if a node discovers that it does not have
the required class it can go back down the chain of nodes looking for
the class file which will be automatically transferred to the node, if
it is found.

[...]

RootLoader is supposed to be used when starting Groovy in the console to
provide a stable class loading setup to it. RootLoader is not supposed
to be used in other means, because it actually violates class loading
constraints in that it prefers loading jars from a given directory over
the system/plattform loader.

What seems to happen, according to your description is that the jcsp
library expects a setup with DynamicClassLoaders, so it can identify and
transfer the required classes. Instead it finds a RootLoader and cannot
handle it. When you start Groovy in an IDE the IDE usually takes care of
setting up the classloaders, thus there is no RootLoader involved.

You can use GroovyMain to start a script and take care of the
classloader setup yourself. For example you can just add Groovy and all
the required libraries to the normal classpath and start using the Java
command through GroovyMain. Not as convenient as just starting the
scripts using the groovy command of course

bye blackdrag

[GitHub] [groovy-website] visch commented on issue #15: refinement needed to handle https and iframes

[GitBox]

visch commented on issue #15: refinement needed to handle https and iframes
URL: https://github.com/apache/groovy-website/issues/15#issuecomment-552988181
 
 
   https://groovy-lang.org/single-page-documentation.html is broken again :( 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Problem with org.codehaus.groovy.tools.RootLoader

[Kerridge, Jon]

Hi,

I have come across a problem that I am finding very confusing.

I have a parallel library that is reliable, mounted on jcenter() called jcsp - 
CSP for Java.

I have been wanting to update the library for Java9+ and to use it with Groovy 
3.

But first discovered a problem that first manifest itself earlier this year 
when teaching a parallel processing module.

Prior to this year I had used Eclipse and its Groovy plugin from SpringSource.  
With no problems.
The code was compiled for Java 1.8 and Groovy2.4

I have created a Groovy version and a Java version of the same setup 
respectively:
https://github.com/JonKerridge/GroovyDCL
https://github.com/JonKerridge/JavaDCL

The problem is that the pure Java version does not create the error and runs as 
expected.

The ReadMe in GroovyDCL gives more detail.  There is also a ReadMe in JavaDCL

The problem is that the Groovy version when run as three separate processes 
creates the error
org.codehaus.groovy.tools.RootLoader cannot be cast to 
jcsp.net2.mobile.DynamicClassLoader.

This error comes from deep in the jcsp library.  DynamicClassLoader uses the 
Java(8) SystemClassLoader.

The code is derived from a part of jcsp which deals with class loading in a 
parallel system run on multiple nodes on separate workstations.

The idea, which works, is that if a node discovers that it does not have the 
required class it can go back down the chain of nodes looking for the class 
file which will be automatically transferred to the node, if it is found.

I know that class loaders have changed in Java9+ and was expecting to just make 
the change to the jcsp library from SystemClassLoader  (8) to 
PlatformClassLoader (9+).

I used the standard Intellij built-in Groovy 2.3.11 with Java 8 to keep the 
build as simple as possible.

I have tried the same code for all later versions of groovy with Java 8 and 
Java 12 and get the same error.

Needless to say, the actual example that showed this problem was far more 
complex! I therefore created the two versions referred to above as being the 
simplest means of demonstrating the problem.

Any help or advice very gratefully received.

Jon

Jon Kerridge PhD FBCS FHEA CITP CEng
Emeritus Professor of Computing
School of Computing
Edinburgh Napier University
Merchiston Campus
10 Colinton Road
Edinburgh
EH10 5DT

j.kerri...@napier.ac.uk


This message and its attachment(s) are intended for the addressee(s) only and 
should not be read, copied, disclosed, forwarded or relied upon by any person 
other than the intended addressee(s) without the permission of the sender. If 
you are not the intended addressee you must not take any action based on this 
message and its attachment(s) nor must you copy or show them to anyone. Please 
respond to the sender and ensure that this message and its attachment(s) are 
deleted.

It is your responsibility to ensure that this message and its attachment(s) are 
scanned for viruses or other defects. Edinburgh Napier University does not 
accept liability for any loss or damage which may result from this message or 
its attachment(s), or for errors or omissions arising after it was sent. Email 
is not a secure medium. Emails entering Edinburgh Napier University's system 
are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration 
number SC018373