guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#32947] Add java-xalan.


From: Julien Lepiller
Subject: [bug#32947] Add java-xalan.
Date: Tue, 22 Mar 2022 19:18:11 +0100
User-agent: K-9 Mail for Android

On March 22, 2022 6:45:15 PM GMT+01:00, Maxime Devos <maximedevos@telenet.be> 
wrote:
>Maxime Devos schreef op vr 18-03-2022 om 21:07 [+0100]:
>> I've been reading the source code, not seeing anything
>> ‘suspicous’ (malware etc.) so far (I'm currently at
>> xalan-j_2_7_2/src/org/apache/xalan/templates/FuncKey.java, 25%).
>
>Now I'm at 42% (src/org/apache/xalan/xsltc/compiler/XPathLexer.java).
>I've found two binaries (*):
>
>  * src/org/apache/xalan/xsltc/compiler/XPathLexer.java
>  * src/org/apache/xalan/xsltc/compiler/XPathParser.java
>
>They appear to be generated by a lexer and parser generator --
>apparently it's named ‘java_cup’?  Given that they are in the 'xsltc'
>part, which is currently unused in the java-xalan package IIUC, I
>believe it would be sufficient to just delete these two files.

To add to your comment. I've encountered java_cup in tge past. It's not 
bootstrappable as far as I can see. It has a dependency on jflex and itself, 
and jflex requires itself and java_cup. I looked at the first commit of jflex, 
and it already depends on itself (but not cup). According to the devs, chey 
used a hand-written lexer that was too aweful to commit, and so we can't 
rebuild jflex.

If someone is interested, they would have to write a lexer for an early version 
of jflex :)

>
>(*) Here I mean 'binaries'='generated, not source code' -- it's still
>.java and not .class.
>
>Greetings,
>Maxime.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]