How to run a Java program in a Windows build?

[John Williams]

I'm trying to land a change that involves running a Java command from a Python script a build time, but the command fails on the "win-msvc-rel" Commit Bot with this message:

'java' is not recognized as an internal or external command,

operable program or batch file.

I looked around a bit abound found some code using distutils.spawn.find_executable("java") to locate the JVM before running it, but that didn't solve the problem in my case.

Does anyone know of a good cross-platform way to run a Java program at build time? Here is the change I'm trying to land.

[Dirk Pranke]

Running java at build time on all platforms isn't currently supported (perhaps obviously, as you've discovered). Java is only unconditionally allowed in the Android build.

It looks like you're trying to run closure, which isn't something we do on Windows right now. Is this something that can be only run on Linux, e.g., are you doing this just for typechecking? Or do you really need the scripts to be compiled for the product?

It may be that we need to finally figure out a path to using closure for all platforms ...

-- Dirk

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CALaH6Dvfh_PcxuU1FtiPjXtGUBjKADRVOU97fb6%3DLkLMSnU5yA%40mail.gmail.com.

[John Williams]

We're basically using the compiler for three things: type checking, inlining intrinsic functions, and assembling the source files into modules based on the dependency graph.

I'll look into using the Node-based version of the compiler since that seems like the cleanest solution if it works.

If necessary, we could forgo type checking on Windows, supply implementations of the intrinsics, and write a script to traverse the dependency graph and concatenate the source files. I'd rather avoid doing that if possible, though, because duplicating the functionality of the compiler seems pretty gross to me.

[Dirk Pranke]

Let's move this discussion into crbug.com/805011 . I agree that duplicating the compiler is gross and should be avoided, and there are real needs for Closure, but we also have historically tried very hard to avoid Java, so we need to figure out what the right thing to do is here and have a consistent story.

-- Dirk

[Demetrios Papadopoulos]

On Tue, Jan 23, 2018 at 1:24 PM, Dirk Pranke <dpr...@chromium.org> wrote:

Let's move this discussion into crbug.com/805011 .

Is this the right bug? Seems unrelated to me, or I am just not understanding the relation. Also there is this older bug about running Closure compiler on windows.

 

I agree that duplicating the compiler is gross and should be avoided, and there are real needs for Closure, but we also have historically tried very hard to avoid Java, so we need to figure out what the right thing to do is here and have a consistent story.

In the long run, I would like to migrate most of our type checking (and development) to TypeScript and TSC (typescript compiler), which does not require any Java and has many other advantages. I know there are others who might be supportive of this vision but this is a whole other story though, and will require a lot of effort (and discussion + enough consensus) to get there.

 

-- Dirk

On Tue, Jan 23, 2018 at 1:15 PM, John Williams <j...@google.com> wrote:

We're basically using the compiler for three things: type checking, inlining intrinsic functions, and assembling the source files into modules based on the dependency graph.

I'll look into using the Node-based version of the compiler since that seems like the cleanest solution if it works.

Node-based Closure compiler has its own set of problems (not all JSC flags are supported, not great performance, at least last time I checked). See previous findings here, which led us to use Uglify instead.

Overall my suggestion is to explore the possibility of being served by the existing tools that other JS code in Chromium already uses (see WebUI's tool dependencies here).  Basically, use closure compiler for type-checking only, which happens on its own dedicated bot , and use Uglify to produce the concatenated JS binary.

Thanks,

Demetrios

[PhistucK]

Looks like you linked to the wrong issue. :O

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTBWA%2BbPjeB_9eCrKaPZHupeZBdrsGEfQj5zfL8ViLKRRg%40mail.gmail.com.

[Dirk Pranke]

On Tue, Jan 23, 2018 at 1:52 PM, Demetrios Papadopoulos <dpa...@chromium.org> wrote:

On Tue, Jan 23, 2018 at 1:24 PM, Dirk Pranke <dpr...@chromium.org> wrote:

Let's move this discussion into crbug.com/805011 .

Is this the right bug? Seems unrelated to me, or I am just not understanding the relation. Also there is this older bug about running Closure compiler on windows.

Whoops, sorry, wrong bug. I had also forgotten about the older bug, so I'll de-dup them and we can just use crbug.com/628971.

 

 

I agree that duplicating the compiler is gross and should be avoided, and there are real needs for Closure, but we also have historically tried very hard to avoid Java, so we need to figure out what the right thing to do is here and have a consistent story.

In the long run, I would like to migrate most of our type checking (and development) to TypeScript and TSC (typescript compiler), which does not require any Java and has many other advantages. I know there are others who might be supportive of this vision but this is a whole other story though, and will require a lot of effort (and discussion + enough consensus) to get there.

 

-- Dirk

On Tue, Jan 23, 2018 at 1:15 PM, John Williams <j...@google.com> wrote:

We're basically using the compiler for three things: type checking, inlining intrinsic functions, and assembling the source files into modules based on the dependency graph.

I'll look into using the Node-based version of the compiler since that seems like the cleanest solution if it works.

Node-based Closure compiler has its own set of problems (not all JSC flags are supported, not great performance, at least last time I checked). See previous findings here, which led us to use Uglify instead.

Overall my suggestion is to explore the possibility of being served by the existing tools that other JS code in Chromium already uses (see WebUI's tool dependencies here).  Basically, use closure compiler for type-checking only, which happens on its own dedicated bot , and use Uglify to produce the concatenated JS binary.

Great, let's pursue some of that investigation on the bug.

-- Dirk

[Christopher Lam]

dpapad@: FYI, I'm working on slowly making closure compiler type checking work on the normal bots through GN, so that we can get rid of GYP and get type checking for generated Mojo interfaces for WebUI. It'll take a while as I'm pretty slammed with my primary project. Please keep me in the loop for advancements in this area, as all of this will likely be my focus next quarter.

[Demetrios Papadopoulos]

On Tue, Jan 23, 2018 at 8:26 PM, Christopher Lam <cala...@google.com> wrote:

dpapad@: FYI, I'm working on slowly making closure compiler type checking work on the normal bots through GN, so that we can get rid of GYP and get type checking for generated Mojo interfaces for WebUI. It'll take a while as I'm pretty slammed with my primary project. Please keep me in the loop for advancements in this area, as all of this will likely be my focus next quarter.

Will do. Quick question though: Is the type-checking you are working on executed as part of building Chrome, or is it behind its own GN targets, that only trigger if one manually builds that target. Asking because it would slow down builds a lot if Closure Compiler was invoked by default, and it would make development cycles much slower (especially for WebUI dev).

[Christopher Lam]

The plan is to have it as a separate GN target, which runs on the normals bots (you can try it by compiling webui_closure_compile on a linux chromeos build). Apparently having custom bots like we do for Closure is deprecated anyway.

The grand scheme of things is to have Mojo generate WebUI function bindings instead of using chrome.send. Mojo only runs on GN, so we can't get Closure to run using Mojo-generated dependencies until we're migrated over.