New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added java version and architecture detection #33
Conversation
What do you think about this approach? |
|
||
callback(null, { | ||
version: stderr.match(/java version "(.*)"/)[1], | ||
arch: stderr.match(/64-Bit/) ? "x64" : "ia32" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't really need this either, so os
call seemed fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is required because what matters for the stack size is not the os architecture but the JRE architecture that's why I detect it here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha, that should help fix some memory issues.
Approach looks good, a few details can be tuned. |
Ok, I made the changes |
In the original ticket we had "If it is, should check if the version is okay." I'm don't remember any java version requirements. @sideshowbarker are there any? http://validator.github.io/validator/ doesn't mention anything. |
Is the question about 32-bit vs 64-bit java versions, or about Java 5/6/7/8 versions? Or both? I do most of my development and testing on 64-bit systems—Debian Linux and OSX. I don't have any Windows systems to test on directly myself but I know that in the past at least others have been able to run it successfully on fairly constrained 32-bit Windows systems. However, I think it requires more memory these days than it did in the past (due I think mostly to me adding support for MathML3 and RDFa and some other things that have made the schema-processing backend more memory-hungry.) But that said, I have one secondary 32-bit Linux (Debian) system with just 500MB or RAM where I continue to test and run it without any problems. So I know it can still be run on a 32-bit system that's relatively constrained (by current standards). As far as Java 5/6/7/8 versions, there are not explicit requirements. I've tested it a lot with Java 6 and Java 7 and it works completely as expected with both. It may still work with Java 5 but I don't have an environment to test that—and regardless I would think (hope) there's nobody that still actually needs to run things under Java 5. As far as Java 8, I've not had time to try it yet. |
Thanks for the details. Sounds like it should work more or less everywhere. I'll land this PR then without a version check. We could add that later if necessary. |
Published as 1.6.0. |
Fixes #29