IcedTea-Web
IcedTea-Web copied to clipboard
AdoptOpenJDK
removal of rhino
Hi! I would like to remove rhino, and substitute it by nashorn. However, that is dead end too. In future, it can be replaced byJS on graal. Generally - all this JS depndencies, are because of https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/networking/proxie_config.html#automatic
What about dropping this feature at all? thoughts?
+1 But we can not simply remove the dependency since it is referenced in Java code. We need to refactor the code, too.
Yes. But the reason why it is in code is questionable. As I wrote, it can be directly replaced by nashorn. But nashorn is deprecated. So ITW will be carying rhino for ever? Or the (sorry for wording) absolutley stupid idea to use javascript to provide proxy settings... For me, I would drop it. ( but in same time somebody will compalin that it was in use in last 100 years) - so my reason for remove it now, is the very intensive of itw rework you are oding. Otherwise I would not dare to suggest it.
yes, I only wanted to say that we need to do more than just remove the dependency from maven ;)
I confirm that it is still in use ... and know some corporation who use proxy pac configuration. When PAC is not picked up (java without javaws) it is a nightmare for us to explain what they must do for them to allow connection to outside ( whitelist etc )
Or the (sorry for wording) absolutley stupid idea to use javascript to provide proxy settings... maybe stupid but usefull in some case and used
Removing this feature is not an enhancement
Maybe replace dependency and postpone the remove from the feature at later time. Maybe add a warning to user if PAC is detected to say it is deprecated before removing in x month ?
Rhino is good enough to handle the PAC. Nashorn has a better performance but that's not critical for interpreting a simple proxy.pac file. If Nashorn was available as a standalone jar smaller than Rhino, then that might be interesting to switch.
I think we have to keep PAC-support, but I will double check. My suggestion is to rewrite the code to be based on JSR 223 (Scripting API). This would make it simple to switch to Nashorn, GraalVM or whatnot in the future.
