javacc help needed

[Rene Engelhard]

Hi,

the recently accepted flutejava and flute-1.3-jfree packages use a
javacc generated parser - but they currently ship one pre-generated
which is not really the ideal way.

I don't feel comfortable uploading those to unstable with a parser not
being able to rebuilt/fixed if needed; this in turn holds some packages
up from being uploaded to unstable which in turn hold up OpenOffice.org
2.3.x being uploaded to unstable.. :/

When removing the generated files, re-building the parser and trying the
build it fails, though (not at the &6 ;) ) when trying to build the
stuff:

http://zyklop.dyndns.org/~rene/flute-1.3-jfree_20061107-2_amd64.build
http://zyklop.dyndns.org/~rene/flutejava_1.3-3_amd64.build
which both boil to "Unhandled exception type ParseException".

Is there anyone javacc-knowledgeable who wants to look and tell me what
I am/upstream is doing wrong and how to regenerate the parser?
(apt-get source flutejava/flute-1.3-jfree; look for FIXME ;) )

Regards,

Rene

[Sanghyeon Seo]

2007/11/5, Rene Engelhard <re...@debian.org>:

> When removing the generated files, re-building the parser and trying the
> build it fails, though (not at the &6 ;) ) when trying to build the
> stuff:
>
> http://zyklop.dyndns.org/~rene/flute-1.3-jfree_20061107-2_amd64.build
> http://zyklop.dyndns.org/~rene/flutejava_1.3-3_amd64.build
> which both boil to "Unhandled exception type ParseException".
>
> Is there anyone javacc-knowledgeable who wants to look and tell me what
> I am/upstream is doing wrong and how to regenerate the parser?
> (apt-get source flutejava/flute-1.3-jfree; look for FIXME ;) )

Upstream modified ParseException.java after it was generated. Even the
generated file says you can! ("You can modify this class to customize
your error reporting...")

In the original modifed file, ParseException extends CSSException
which extends RuntimeException, so it is an unchecked exception. But
unmodifed ParseException extends Exception by default, which makes it
a checked exception, but methods throwing ParseException doesn't
declare to throw it, resulting in compile error.

So you can regenerate files, and then modify ParseException.java as
upstream did. import org.w3c.css.sac.CSSException; and replace the
class ParseException is extending.

--
Seo Sanghyeon

--
To UNSUBSCRIBE, email to debian-ja...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Michael Koch]

Hello,

On Mon, Nov 05, 2007 at 10:49:29AM +0900, Sanghyeon Seo wrote:
> Upstream modified ParseException.java after it was generated. Even the
> generated file says you can! ("You can modify this class to customize
> your error reporting...")
>
> In the original modifed file, ParseException extends CSSException
> which extends RuntimeException, so it is an unchecked exception. But
> unmodifed ParseException extends Exception by default, which makes it
> a checked exception, but methods throwing ParseException doesn't
> declare to throw it, resulting in compile error.
>
> So you can regenerate files, and then modify ParseException.java as
> upstream did. import org.w3c.css.sac.CSSException; and replace the
> class ParseException is extending.

Thats close to the worst things library developers can do...

This makes me really scared about this. Depending on such a library in a
distro is like depending on dynamite to not explode.

Cheers,
Michael

[Paul Cager]

Michael Koch wrote:
> Hello,
> On Mon, Nov 05, 2007 at 10:49:29AM +0900, Sanghyeon Seo wrote:
>> In the original modifed file, ParseException extends CSSException
>> which extends RuntimeException, so it is an unchecked exception. But
>> unmodifed ParseException extends Exception by default, which makes it
>> a checked exception, but methods throwing ParseException doesn't
>> declare to throw it, resulting in compile error.
>

> Thats close to the worst things library developers can do...
>
> This makes me really scared about this. Depending on such a library in a
> distro is like depending on dynamite to not explode.

I would say it's not _entirely_ the library developers' fault. JavaCC
has always had a rather inconsistent use of Exceptions - ParseException
(thrown for syntactic errors) extends Exception, but TokenMgrError
(thrown for lexical errors) extends Error. It's not surprising users get
in a pickle. Having said that, I would certainly think it would be
better to trap the (unchecked) TokenMgrError and convert it to a
(checked) ParseException.

(And sometimes it is quite appropriate for a ParseException to be
treated as a RuntimeError - e.g. if you are using the parser on
known-good input. I've not checked if that's the case for flute).

The next release of JavaCC should make things a little more logical:
https://javacc.dev.java.net/issues/show_bug.cgi?id=12

Thanks,
Paul.

[Michael Koch]

Hello Paul,

On Sun, Nov 11, 2007 at 10:08:13PM +0000, Paul Cager wrote:
> I would say it's not _entirely_ the library developers' fault. JavaCC
> has always had a rather inconsistent use of Exceptions - ParseException
> (thrown for syntactic errors) extends Exception, but TokenMgrError
> (thrown for lexical errors) extends Error. It's not surprising users get
> in a pickle. Having said that, I would certainly think it would be
> better to trap the (unchecked) TokenMgrError and convert it to a
> (checked) ParseException.
>
> (And sometimes it is quite appropriate for a ParseException to be
> treated as a RuntimeError - e.g. if you are using the parser on
> known-good input. I've not checked if that's the case for flute).
>
> The next release of JavaCC should make things a little more logical:
> https://javacc.dev.java.net/issues/show_bug.cgi?id=12

Thanks for this explanation. This explains some of the problems.
Unfortunately it doesnt make it better.

Our problem is that that some user of flute might depend on one way and
another might depend on the other way. We dont really want to have
multiple copies of flute in the archive.

Cheers,
Michael