<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: The Return of SQLcl&#8217;s SCRIPT Command	</title>
	<atom:link href="https://www.salvis.com/blog/2026/07/25/the-return-of-sqlcls-script-command/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.salvis.com/blog/2026/07/25/the-return-of-sqlcls-script-command/</link>
	<description>Database-centric development</description>
	<lastBuildDate>Mon, 27 Jul 2026 11:04:19 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0.4</generator>
<atom:link rel="hub" href="https://pubsubhubbub.appspot.com"/>
<atom:link rel="hub" href="https://pubsubhubbub.superfeedr.com"/>
<atom:link rel="hub" href="https://websubhub.com/hub"/>
<atom:link rel="self" href="https://www.salvis.com/blog/2026/07/25/the-return-of-sqlcls-script-command/feed/"/>
	<item>
		<title>
		By: Philipp Salvisberg		</title>
		<link>https://www.salvis.com/blog/2026/07/25/the-return-of-sqlcls-script-command/#comment-287374</link>

		<dc:creator><![CDATA[Philipp Salvisberg]]></dc:creator>
		<pubDate>Mon, 27 Jul 2026 11:04:19 +0000</pubDate>
		<guid isPermaLink="false">https://www.salvis.com/blog/?p=21049#comment-287374</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.salvis.com/blog/2026/07/25/the-return-of-sqlcls-script-command/#comment-287373&quot;&gt;Rvo&lt;/a&gt;.

Thank you for your kind words and for sharing your findings! The tip about the dbtools/launch directory is particularly useful. I’ll look into it. I’m glad the formatter continues to work well for you across these tools and versions.]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.salvis.com/blog/2026/07/25/the-return-of-sqlcls-script-command/#comment-287373">Rvo</a>.</p>
<p>Thank you for your kind words and for sharing your findings! The tip about the dbtools/launch directory is particularly useful. I’ll look into it. I’m glad the formatter continues to work well for you across these tools and versions.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Rvo		</title>
		<link>https://www.salvis.com/blog/2026/07/25/the-return-of-sqlcls-script-command/#comment-287373</link>

		<dc:creator><![CDATA[Rvo]]></dc:creator>
		<pubDate>Mon, 27 Jul 2026 10:52:55 +0000</pubDate>
		<guid isPermaLink="false">https://www.salvis.com/blog/?p=21049#comment-287373</guid>

					<description><![CDATA[Thank you so much Philipp, you&#039;ve made my day!

I had been looking for a way to do that (without success so far), and then came your excellent article &#038; accompanying Github repository. Not only does this enable to have Javascript back in SQLcl, but also (after tinkering a bit) in good old SQL Developer Classic, including its latest incarnation (26.2), without the requirement of installing GraalVM (which is important these days because sadly, due to Java licensing issues, in many corporations it has become forbidden to download Oracle JDKs). It&#039;s a huge relief that I can continue to use the Trivadis PL/SQL formatter (or should we call it the Salvisberg formatter?) without being stuck forever on SQL Developer (Classic) 23.1.1.

As regards the SQL Developer for VS Code extension, I have found that, if instead of landing the GraalJS jar files into the dbtools/sqlcl/lib directory, they are put directly into the dbtools/launch directory, then Javascript become available both in the embedded sqlcl and in SQL worksheets (tested on 26.2.0). Of course I have to start VS Code through a wrapper script to set the required system properties through JAVA_JDK_OPTIONS, in order to silence the various warnings.

And I fully agree with you: this is fine power-user hackery, but Oracle should definitely have Javascript built-in as it used to be.

Thanks again!

Best regards,]]></description>
			<content:encoded><![CDATA[<p>Thank you so much Philipp, you&#8217;ve made my day!</p>
<p>I had been looking for a way to do that (without success so far), and then came your excellent article &amp; accompanying Github repository. Not only does this enable to have Javascript back in SQLcl, but also (after tinkering a bit) in good old SQL Developer Classic, including its latest incarnation (26.2), without the requirement of installing GraalVM (which is important these days because sadly, due to Java licensing issues, in many corporations it has become forbidden to download Oracle JDKs). It&#8217;s a huge relief that I can continue to use the Trivadis PL/SQL formatter (or should we call it the Salvisberg formatter?) without being stuck forever on SQL Developer (Classic) 23.1.1.</p>
<p>As regards the SQL Developer for VS Code extension, I have found that, if instead of landing the GraalJS jar files into the dbtools/sqlcl/lib directory, they are put directly into the dbtools/launch directory, then Javascript become available both in the embedded sqlcl and in SQL worksheets (tested on 26.2.0). Of course I have to start VS Code through a wrapper script to set the required system properties through JAVA_JDK_OPTIONS, in order to silence the various warnings.</p>
<p>And I fully agree with you: this is fine power-user hackery, but Oracle should definitely have Javascript built-in as it used to be.</p>
<p>Thanks again!</p>
<p>Best regards,</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
