5 ms·

I came here to write sth like "still in Java... :/" but I can't even check it, the site seems to be hugged to death.

by t0mk 11y ago

Alupis 11y ago
> I came here to write sth like "still in Java... :/" And the problem with that is...?
- FooBarWidget 11y ago
  Typical issues surrounding Java projects: - High startup time. Anything bigger than a hello world takes seconds, more typically tens of seconds, to start. My Jenkins setup takes 3 or 4 minutes before it is fully initialized. Even starting the JVM in client mode doesn't help much. I know, it's a server, and startup time doesn't matter once it's running, but it feels annoying. - High memory usage. Heaps in the 1-2 GB range are not uncommon. This can probably be tweaked but as a user who is not a Java expert, figuring out how to do this (and figuring out what value is safe) is frustrating. - XML configuration files. XML was hip in 2004 but these days it is frowned upon and users generally don't like it. This is technically not Java's fault (and I'm sure newer projects use something else) but it is something traditionally heavily associated with Java projects. - Non-Unixy feel. Lots of things just behave like they're not really native.
  - jacques_chester 11y ago
    Jenkins is not my cup of tea, but in its defence: 1. High startup time is amortised over long run times. Jenkins is a general CI server, not an interactive build tool. 2. High memory usage is true, though again tolerable given the role and importance Jenkins will assume in any sane project.
  - Alupis 11y ago
    > - High startup time. This is really not a problem. If you're starting and stopping your Jenkins often, you're really doing it wrong. Jenkins is a server, and really should only get restarted when there's been an update. Not to mention, other large servers that are not Java still take time to startup... there's a lot going on during initialization. > - High memory usage. Perhaps more of an issue for some, but again, Jenkins is a build server, and should be on it's own hardware/vm, with it's own dedicated resources. If you're trying to squeeze by with 1GB of ram, you can, but you should expect the obvious results. The more complicated your builds, the more resources they're consume. Compiling GCC usually takes 1-2GB ram by itself. I don't consider this a problem. > - XML configuration files. If you're using Jenkins properly, you should not have to interact with any config files. Sure, if you're running it behind Tomcat or something, you'll need to dip into the configs, but not liking Jenkins because it has XML config files is shallow and superficial, in my opinion. > - Non-Unixy feel. Lots of things just behave like they're not really native. I'm not sure what to expect from a deliberately cross-platform system. Of course it's not "native Unix-like". But neither is any software written to support OS's that are not Unix-like. And again, you manage and use Jenkins from a web interface, so if you're on the command line, you're doing it wrong. (as an aside, Jenkins has native support for running shell scripts, which I make heavy use of... can't get any more unix-like than that).
    - pswenson 11y ago
      the config is a huge problem, not just because of XML files. Jenkins (pre 2.0 at least) job configs have huge problems with config drift and doesn't play well with configuration management tools. Trying to automate jenkins job configurations requires using the terrible job config xml format and a poorly designed rest API which breaks all the time when you add in a plugin or plugins get upgraded.
      - oblio 11y ago
        Then this should be a life saver for this scenario: https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin Jenkins has a ton of issues but with a bit of careful plugin selection it provides a ton of bang for your buck.
        ecnahc515 11y ago
        The new integrated DSL to replace that plugin is going to be great. Unfortunately, managing jenkins plugins themselves via config management/orchestration is still surprisingly difficult.
        abayer 11y ago
        fwiw, this is very much on the roadmap - https://issues.jenkins-ci.org/browse/JENKINS-31094 https://issues.jenkins-ci.org/browse/JENKINS-31094 - don't know when it'll land, but it will be done. =)
  - mark242 11y ago
    "Heaps in the 1-2 GB range are not uncommon." Is this really still a complaint in 2016? Your phone has that much RAM. Honestly if you're worried about Java heap size, spin up a t2.medium instead of a t2.small for your build pipeline. Running Jenkins on a Raspberry Pi is probably not a great idea if you're writing any serious application.
    - ascotan 11y ago
      Actually it's becoming more of a complaint in 2016 with rise AWS instances that pay by the container size and with the rise of languages like go, etc. which have smaller runtime sizes and are more compatible with cloud computing environments like docker. The JVM adds something like 400MB to every layer of a docker container resulting in multi gigabyte containers. Additionally the memory requirements for running a JVM put you immediately into the t2.medium range which will cost you 4X cost over a t2.nano for simply choosing to run Java instead of something with a smaller runtime footprint.
      - mark242 11y ago
        Don't run production code on a nano. Don't run production code on a nano. Don't run production code on a nano. I don't care what language you're using, if you find yourself saying "well, I could run on a nano" just stop.
      - Alupis 11y ago
        > The JVM adds something like 400MB to every layer of a docker container Perhaps this is the "writing on the wall" that containers aren't what you should be using to deploy your app. Just because it's the "latest craze" doesn't mean it's the best solution for the task at hand.
    - t0mk 11y ago
      In the simplest case, Jenkins is just polling and cloning git repos, and then spawning some tests. This plus config parsing and web frontend is not a 1GB RAM job.
      - deleted 11y ago
  - dmytroi 11y ago
    I would agree on some of your points : few minutes initialization times and 1-2 GB heaps may sound not that bad, and when we are talking about product that just provides a fancy, over engineered way to run bunch of shell scripts (considering jenkins doesn't integrate sandboxing from the box) ... honestly there is no excuse to spend 2 gigs of ram just to run shell scripts with web UI. It would be much better in a long term to improve energy/resource efficiency of software like this, just to make it more sustainable and reliable. Edit: configuration-as-code feature is available in jenkins 1.x with job dsl plugin [1], I'm using it at work, because managing 50+ jobs by hand was just insane. Nowadays we just have few dsl files :) [1] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
  - incepted 11y ago
    > High startup time. Anything bigger than a hello world takes seconds Oh, no! Seconds? Like five? Seven? For a process that you start less than once a day? Unacceptable. > High memory usage. Heaps in the 1-2 GB range are not uncommon. So... what? Spend an additional $30 on your build server and add 8Gb to it. Problem solved. > - XML configuration files. XML is fine. As opposed to Groovy, IDE's do a great job at offering auto-completion on it. But if Groovy is your bag, you can use that too. > - Non-Unixy feel. I have no idea what that means and I've been using UNIX for about thirty years now.
- t0mk 11y ago
  In my opinion Using XML is always wrong. If you want to automate Jenkins setup with sth like Docker or Ansible, you have to touch the configuration, and that means dealing with XML, which makes me cry. There are many ways to do configuration reasonably. Not so related to Java but hand in hand, as somebody else put it: "Java is a DSL to convert large XML files to stack traces". It's impossible to debug, and its plugins are impossible to debug. If it would be in a scripting language, you could see what's going on easily, maybe print debug messages, and wouldn't have to clone-edit-compile-(deploy)-run in order to debug. When some Jenkins plugin doesn't work out-of-the box, I straight up give up on it, because I know there's no simple way to interactively dive into the code. Based on my experience, I really tried. YMMV.
farresito 11y ago
It works for me.

I came here to write sth like "still in Java... :/" but I can't even check it, the site seems to be hugged to death.

by t0mk 11y ago

I came here to write sth like "still in Java... :/" but I can't even check it, the site seems to be hugged to death.

Alupis 11y ago

> I came here to write sth like "still in Java... :/" And the problem with that is...?

FooBarWidget 11y ago
Typical issues surrounding Java projects: - High startup time. Anything bigger than a hello world takes seconds, more typically tens of seconds, to start. My Jenkins setup takes 3 or 4 minutes before it is fully initialized. Even starting the JVM in client mode doesn't help much. I know, it's a server, and startup time doesn't matter once it's running, but it feels annoying. - High memory usage. Heaps in the 1-2 GB range are not uncommon. This can probably be tweaked but as a user who is not a Java expert, figuring out how to do this (and figuring out what value is safe) is frustrating. - XML configuration files. XML was hip in 2004 but these days it is frowned upon and users generally don't like it. This is technically not Java's fault (and I'm sure newer projects use something else) but it is something traditionally heavily associated with Java projects. - Non-Unixy feel. Lots of things just behave like they're not really native.
- jacques_chester 11y ago
  Jenkins is not my cup of tea, but in its defence: 1. High startup time is amortised over long run times. Jenkins is a general CI server, not an interactive build tool. 2. High memory usage is true, though again tolerable given the role and importance Jenkins will assume in any sane project.
- Alupis 11y ago
  > - High startup time. This is really not a problem. If you're starting and stopping your Jenkins often, you're really doing it wrong. Jenkins is a server, and really should only get restarted when there's been an update. Not to mention, other large servers that are not Java still take time to startup... there's a lot going on during initialization. > - High memory usage. Perhaps more of an issue for some, but again, Jenkins is a build server, and should be on it's own hardware/vm, with it's own dedicated resources. If you're trying to squeeze by with 1GB of ram, you can, but you should expect the obvious results. The more complicated your builds, the more resources they're consume. Compiling GCC usually takes 1-2GB ram by itself. I don't consider this a problem. > - XML configuration files. If you're using Jenkins properly, you should not have to interact with any config files. Sure, if you're running it behind Tomcat or something, you'll need to dip into the configs, but not liking Jenkins because it has XML config files is shallow and superficial, in my opinion. > - Non-Unixy feel. Lots of things just behave like they're not really native. I'm not sure what to expect from a deliberately cross-platform system. Of course it's not "native Unix-like". But neither is any software written to support OS's that are not Unix-like. And again, you manage and use Jenkins from a web interface, so if you're on the command line, you're doing it wrong. (as an aside, Jenkins has native support for running shell scripts, which I make heavy use of... can't get any more unix-like than that).
  - pswenson 11y ago
    the config is a huge problem, not just because of XML files. Jenkins (pre 2.0 at least) job configs have huge problems with config drift and doesn't play well with configuration management tools. Trying to automate jenkins job configurations requires using the terrible job config xml format and a poorly designed rest API which breaks all the time when you add in a plugin or plugins get upgraded.
    - oblio 11y ago
      Then this should be a life saver for this scenario: https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin Jenkins has a ton of issues but with a bit of careful plugin selection it provides a ton of bang for your buck.
      - ecnahc515 11y ago
        The new integrated DSL to replace that plugin is going to be great. Unfortunately, managing jenkins plugins themselves via config management/orchestration is still surprisingly difficult.
        abayer 11y ago
        fwiw, this is very much on the roadmap - https://issues.jenkins-ci.org/browse/JENKINS-31094 https://issues.jenkins-ci.org/browse/JENKINS-31094 - don't know when it'll land, but it will be done. =)
- mark242 11y ago
  "Heaps in the 1-2 GB range are not uncommon." Is this really still a complaint in 2016? Your phone has that much RAM. Honestly if you're worried about Java heap size, spin up a t2.medium instead of a t2.small for your build pipeline. Running Jenkins on a Raspberry Pi is probably not a great idea if you're writing any serious application.
  - ascotan 11y ago
    Actually it's becoming more of a complaint in 2016 with rise AWS instances that pay by the container size and with the rise of languages like go, etc. which have smaller runtime sizes and are more compatible with cloud computing environments like docker. The JVM adds something like 400MB to every layer of a docker container resulting in multi gigabyte containers. Additionally the memory requirements for running a JVM put you immediately into the t2.medium range which will cost you 4X cost over a t2.nano for simply choosing to run Java instead of something with a smaller runtime footprint.
    - mark242 11y ago
      Don't run production code on a nano. Don't run production code on a nano. Don't run production code on a nano. I don't care what language you're using, if you find yourself saying "well, I could run on a nano" just stop.
    - Alupis 11y ago
      > The JVM adds something like 400MB to every layer of a docker container Perhaps this is the "writing on the wall" that containers aren't what you should be using to deploy your app. Just because it's the "latest craze" doesn't mean it's the best solution for the task at hand.
  - t0mk 11y ago
    In the simplest case, Jenkins is just polling and cloning git repos, and then spawning some tests. This plus config parsing and web frontend is not a 1GB RAM job.
    - deleted 11y ago
- dmytroi 11y ago
  I would agree on some of your points : few minutes initialization times and 1-2 GB heaps may sound not that bad, and when we are talking about product that just provides a fancy, over engineered way to run bunch of shell scripts (considering jenkins doesn't integrate sandboxing from the box) ... honestly there is no excuse to spend 2 gigs of ram just to run shell scripts with web UI. It would be much better in a long term to improve energy/resource efficiency of software like this, just to make it more sustainable and reliable. Edit: configuration-as-code feature is available in jenkins 1.x with job dsl plugin [1], I'm using it at work, because managing 50+ jobs by hand was just insane. Nowadays we just have few dsl files :) [1] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
- incepted 11y ago
  > High startup time. Anything bigger than a hello world takes seconds Oh, no! Seconds? Like five? Seven? For a process that you start less than once a day? Unacceptable. > High memory usage. Heaps in the 1-2 GB range are not uncommon. So... what? Spend an additional $30 on your build server and add 8Gb to it. Problem solved. > - XML configuration files. XML is fine. As opposed to Groovy, IDE's do a great job at offering auto-completion on it. But if Groovy is your bag, you can use that too. > - Non-Unixy feel. I have no idea what that means and I've been using UNIX for about thirty years now.
t0mk 11y ago
In my opinion Using XML is always wrong. If you want to automate Jenkins setup with sth like Docker or Ansible, you have to touch the configuration, and that means dealing with XML, which makes me cry. There are many ways to do configuration reasonably. Not so related to Java but hand in hand, as somebody else put it: "Java is a DSL to convert large XML files to stack traces". It's impossible to debug, and its plugins are impossible to debug. If it would be in a scripting language, you could see what's going on easily, maybe print debug messages, and wouldn't have to clone-edit-compile-(deploy)-run in order to debug. When some Jenkins plugin doesn't work out-of-the box, I straight up give up on it, because I know there's no simple way to interactively dive into the code. Based on my experience, I really tried. YMMV.

farresito 11y ago

It works for me.