On Sat, 2004-02-07 at 09:54, Dalibor Topic wrote: > Hi Maczka, > > Maczka Michal wrote: > > > Why would you like to ever recompile java sources when you have jars? > > I can think of a few reasons to do it: > > a) You've made a (necessary) modification to the sources (security > patch, bug fix, performance improvement, new feature, etc.). If you've > got the sources, you might as well use them ;)
In most cases as far as Maven goes this would be done by the project. Whoever found the problem would supply the patch, the project would build a new JAR and deploy it. > b) The JAR doesn't meet your needs, but can be built to meet your needs > with some specific build properties, like enabling the use of some > feature due to known presence of some other artifact. Ant does this a > lot, for example, afaik. There is no conditional compilation in Maven, it leads to unmaintainability. The evidence clearly shown in the history of the Turbine project where optionally compiled modules fell into disuse. > c) The 'default' JAR is too big, you just want the core functionality. > Think of embedded systems, for example. Again, this is something would probably work with a project if you want this to be a standard release. > d) The toolchain used in the build has a bug that shows up in the > generated artifact. This happens ocassionally, I've been recently bitten > by the compiler used to create Eclipse's JARs generating bytecode that > violates the Virtual Machine Specification 2nd Edition. > > e) You want to insert additional steps in the build process to verify > the integrity of the result. External verifiers, static analysis tools, etc. > > f) Licensing issues. The JAR may contain code that you don't want (or > can't) distribute, but which can be stripped out. Think of (L)GPL code > being avoided in JARs on Apache.org. > > g) Adding debugging information. Obvious, I guess. > > h) Targetting a different JDK version. Like building applets for use > with JDK 1.1 runtimes with a 1.4.2 SDK. > > i) Targetting a 64bit or 32bit system (Javac in JDK 1.5 has switches for > this, but I don't know for sure what they do). > > And so on. These are all things that either: 1) You would work with the project by supplying patches in order to make a standard release of something, or 2) You would just build it yourself to modify it, and people do this all the time but you don't need an OS specific packager for this, you just need Maven. > > I always that "the latest proven trend" is to distribute appliction as byte > > code and to let VM do optimisation. > > At least this is what Microsoft is doing with .NET and soon (in few years) > > most of the application for MS Windows > > will be run using CLR VM. IMHO this is a way to go and what Gentoo Linux > > does is simply for > > people who like to have a hobby and have a lot of time for it. > > I see it as a 'culture clash' between pragmatism and idealism. There's nothing stopping you from building from sources. You certainly don't need an OS specific packager for that. > The Windows culture does not see much of a point in having source code > available, the value is in the binaries. If things don't work, you wait > for the vendor to fix them, use something else, or cry. I'd assume that > open source is seen as a cute way to collaborate to produce better > binaries faster. Binaries work most of the time, so tinkering with > source is a waste of time. > > The free software culture does not see much point in having binaries, That simply isn't true if you include most users of OSS to be part of the culture. Most users will take binaries guaranteed. > the value is in the sources. Given the free availability of tools to > rebuild the artifacts and the free availability of associated build > scripts, it is often easy to do the build yourself (on systems like > Gentoo or Fink, that are deeply rooted in the 'source code is more > useful then binary philosophy', To my mind this is not the practice of your typical user of OSS Java software. Users will gladly take binaries. > your experience may vary on other > systems). Binaries work most of the time, but that's just a nice > byproduct of people spending time tinkering with the sources. You're > encouraged to do the tinkering, to learn and and to adapt the progams to > your needs. Again, you're implying something that isn't pure Java. In the vast, vast, majority of cases users don't need to tinker with anything. The JAR just works. > The pragmatic approach is great when you need something fast. The > idealistic approach is great when you need something that can be > customized according to your needs and can grow along with your needs. > Both approaches have their value, despite the ocassional zealous > flame-war on newsgroups. ;) Both are supported in Maven and in fact it is far, far easier with Maven to build from sources in a known way than with things like Ant or Make. > On the other hand, Gentoo is not unique with the 'everything from > source' concept. Other successful projects, like Fink (which brings a > lot of value to the Unix part of MacOSX), do the same. Nor do those > types of systems remain purely devoted to providing just the sources. > Fink offers many pre-built binaries for easy download for those users > that don't want to build the binaries themselves. I think Gentoo does > that too, for the base packages, at least. Of course, because that's what most users want. We're not all 20 something with endless reams of time ;-) I'm not going to sit around all day and wait for Gentoo to build from sources, I'm going to install stock Redhat 9.0, with all its misgivings, and use the time I saved to go outside or more importantly go to the pub! > So systems like Debian, Gentoo, or even Fink don't assume that one > approach will fit all, but provide a combination of the pragmatic and > the idealistic approach: binaries for those that want them, sources for > those that want them. Not a problem. This doesn't even remotely entail the requirement of having a native OS packager be involved. All you need is Maven as far as building most Java projects go. > > Some people are still believing that compilation to native code can increase > > the performance. > > This is simply not true. > > > > Some of the reasons are nicely explained here: > > http://www.idiom.com/~zilla/Computer/javaCbenchmark.html > > Actually, it shows that compilation to native code *can* increase the > performance. It *doesn't necessairly always have to*, but it can, > depending on the code, compilers, etc. It shows that for some > applications, Sun's JDK can run equivalent code faster than a native > counterpendant. For others, it still can't. Maybe it will one day, > though, I don't know. Yah, but myself I don't care. I wouldn't even bother, I would just buy a faster machine as I'm not going to fart around all day to gain a 5% increase in speed. And if I really want speed I'll deploy with JRocket. > OTOH, some people still prefer jikes to javac because of speed. ;) > > > If you want to "recompile" for other reason - to improve start-up time of > > JVM please note that: > > > > a) start-up of JVM time it's getting better and better and with shared > > instnace of JVM it will be also improved > > Sure. Native compilers also keep getting better and better. We all win, > one way or another. ;) > > > b) more and more of the modern applications ( e.g eclipse, idea, maven) are > > distributed as small kernels which are loading plugins. > > And AIIK the compilation to native code can't help much in such cases. > > Not being a gcj developer myself, I unfortunately don't know how well it > copes with that sort of issues. You may want to ask on the gcj developer > mailing lists. I'm sure the GCJ is quite capable seeing some examples like compiling eclipse to binary and having it run. These examples are impressive but still not an overly compelling reason to try and use GCJ. Not for me at least. As advances are made in GCJ, similiar advances will be made in JVMs so the benefit will always be negligible. The only folks who are going to have an advantage are people like the producers of JRocket who have lots of money to throw at a tool that definitely performs faster than the JVM. > cheers, > dalibor topic -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
