So after discussing with the Antlr folks, the intention was that the
runtime remain JDK 1.4 compatible. However a few of the runtime classes
unintentionally ended up using generics. At this point its probably not
going to be switched back because these represent public API classes and
there have been a few releases with that API. So its really a question
of whether we want to pursue something like a retroweaver build for
Antlr to generate a 1.4 compatible release.
To your specific question, yes they can in fact co-exist (diff
packages). The issue is my intention, which is to eventually use this
new translation code as the basis for all SQL generation activities so
that this stuff would get used in a variety of places within the code
On Thu, 2009-05-07 at 23:44 +0200, Max Rydahl Andersen wrote:
Did you see my question/objections/inquiry this time ? :)
Max Rydahl Andersen wrote:
> Hi Steve,
> I asked:
> Is antrl3 capable to coexist with antrl2 in the same classloader/app/vm ?
> p.s. your email steve(a)redhat.com bounces with errors.
> Steve Ebersole wrote:
>> OK, my email (hibernate.org
) is finally back. Perhaps just heard no
>> responses because it was down?
>> Any objections?
>> On Mon, 2009-04-20 at 08:54 -0500, Steve Ebersole wrote:
>>> I am working wth Alexandre Porcelli on some major changes to the HQL
>>> translators. Since the changes are drastic we decided to move from
>>> Antlr2 to Antlr3 in the process as Antlr3 offers many benefits over
>>> The only concern I have with the move to Antlr3 is the fact that Antlr3
>>> only works with JDK 1.5+. I had planned on incorporating this work
>>> Hibernate 3.5. The obvious question being the corresponding JDK move
>>> for Hibernate users migrating to 3.5.
>>> Anyone have strong reasons to not do this move in the 3.5 timeframe?
> hibernate-dev mailing list
hibernate-dev mailing list
Steve Ebersole <steve(a)hibernate.org>