Re: Re: Re: Re: Release of ASM4

if we decide to rename the package, we have several choices:

org.objectweb.asm4
org.ow2.asm4
org.ow2.asm

the first two choices would start a series with asm5, asm6, etc. The 
third one would be a unique renaming, in preparation for jigsaw

Eric

30/07/2011 16:36, Eugene Kuleshov wrote:
> Remi,
>
>    It is not that I want to rename the package. But what is usually
> happening is that library developers go trough several iterations:
>
> * dependency on the latest ASM is added and everything works
> * some project uses this library with some other library using older
> version of ASM and report bugs to the project or even give up on using
> the library. So, developers have to use jarjar or repackage ASM
> sources (ie AspectJ) to deal with the issue.
> * as a result some applications have from 3 to 5 copies of the same
> ASM classes in the application classpath
>
>    Personally I don't particularly like the idea of repackaged and
> redistributed ASM jars, nor use of jarjar for these purposes.
>
>    I also don't think JVM Lang Summit auditory was representative for
> hitting the above iterations.
>    Also, it will be several year before jigsaw will be used in
> practice, yet we have the issue at hands now. Though maybe it is
> already late for trying to address it now.
>
>    regards,
>    Eugene
>
>
> On Sat, Jul 30, 2011 at 10:24 AM, Rémi Forax<[email protected]>  wrote:
>> On 07/30/2011 03:43 PM, Eugene Kuleshov wrote:
>>>
>>>    It is also a good time to change the package name. The API has
>>> changed significantly and there is enough of earlier versions of ASM
>>> around used by various libraries to create conflicts.
>>>
>>>    regards,
>>>    Eugene
>>
>> Hi Eugene,
>> I know that you really want to change the package name
>> but talking with several users at the JVM Summit last week,
>> the idea is not popular.
>> Most of them either manage their dependencies to have only
>> jars that use one version of ASM (maven to the rescue)
>> or they use jarjar.
>>
>> Also some Oracle guys say that they may want to include ASM next
>> as an internal dependency of the JDK 8 using jigsaw,
>> the default module system that will be introduce in JDK 8.
>> Knowing that this module system will resolve all the dependency problems
>> we currently have, I think it's better to wait now and come
>> with two versions (one still 1.3 compatible and one 1.8 +module compatible)
>> for the next release.
>>
>> Rémi
>>
>>> On Sat, Jul 30, 2011 at 9:10 AM, Rémi Forax<[email protected]>    wrote:
>>>>
>>>> Now that the JDK7 is out. I think it's time to release ASM4
>>>> (and starts to think what ASM next will be, jigsaw/module support anyone
>>>> ?).
>>>>
>>>> Is there anybody that think that there is still a bug
>>>> in the trunk that is a blocker or can we the release ASM4 ?
>>>>
>>>> Rémi
>>>>
>>>> On 07/30/2011 12:47 PM, Eric Bruneton wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> thanks for this patch, I've committed it in the SVN repository
>>>>>
>>>>> Eric
>>>>>
>>>>> 12/07/2011 15:20, Ivo Anjo wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm currently working on a project that heavily relies on the
>>>>>> tree.analysis.Analyzer class to understand and modify classes.
>>>>>>
>>>>>> As you might know, when creating the control flow graph for exceptions,
>>>>>> ASM calls analyzer.newControlFlowExceptionEdge(int insn, int
>>>>>> successor),
>>>>>> and uses its boolean return to decide if it should consider the edge
>>>>>> valid or not.
>>>>>>
>>>>>> By default, this method simply returns "true". Because of the rules the
>>>>>> JVM specification uses to decide which exception handler is active --
>>>>>> for example if you add to the beginning of the exception table of a
>>>>>> method an entry that covers the entire method, and catches
>>>>>> java.lang.Throwable, none of the other handlers can ever be executed --
>>>>>> this simplification might detect control flow edges that would never be
>>>>>> possible.
>>>>>>
>>>>>> To implement the same rules the JVM uses, I do this:
>>>>>>      protected boolean newControlFlowExceptionEdge(int src,
>>>>>> TryCatchBlockNode tcb) {
>>>>>>
>>>>>>          for (TryCatchBlockNode handler : getHandlers(src)) {
>>>>>>              if (handler.equals(tcb)) return true;
>>>>>>              if (isSubTypeOf(tcb.type, handler.type)) return false;
>>>>>>          }
>>>>>>
>>>>>>          throw new AssertionError();
>>>>>>      }
>>>>>>
>>>>>> That is, I check if the current try catch block being "visited" is
>>>>>> subsumed by some other that came before it (since getHandlers() gives
>>>>>> me
>>>>>> an ordered list, which is in the same order as the JVM uses).
>>>>>>
>>>>>> Unfortunately, the current code for newControlFlowExceptionEdge only
>>>>>> supplies the src and dst; basically, the current instruction and
>>>>>> insns.indexOf(tcb.handler).
>>>>>> This is unsufficient information to perform this analysis -- especially
>>>>>> since newControlFlowExceptionEdge might be called multiple times for
>>>>>> the
>>>>>> same handler, so it is very hard to know which handler is being
>>>>>> referred
>>>>>> to just by using the src and dst -- my first approach to this was
>>>>>> counting the number of calls to newControlFlowExceptionEdge, and then I
>>>>>> discovered that there can be multiple calls for the same block.
>>>>>>
>>>>>> This patch, then, adds a new method -- protected boolean
>>>>>> newControlFlowExceptionEdge(int src, TryCatchBlockNode tcb), which by
>>>>>> default delegates to the older newControlFlowExceptionEdge (which I
>>>>>> suggest be deprecated, or even removed for ASM 4). Even so, the two
>>>>>> methods can easily co-exist, and older code will still work perfectly;
>>>>>> and a simple one-line change inside analyzer.analyze, since the code
>>>>>> already knows that the current trycatchblock is.
>>>>>>
>>>>>> Hope it is acceptable, and thanks in advance,
>>>>>> Ivo Anjo
>>>>
>>>>
>>>> --
>>>> You receive this message as a subscriber of the [email protected] mailing list.
>>>> To unsubscribe: mailto:[email protected]
>>>> For general help: mailto:[email protected]?subject=help
>>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>>>
>>>>
>>
>>
>>
>> --
>> You receive this message as a subscriber of the [email protected] mailing list.
>> To unsubscribe: mailto:[email protected]
>> For general help: mailto:[email protected]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>>

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws