Er, yes... dev-ruby :) Fixed now.

You probably mean dev-ruby/rails, right? :-)

If you're already a java pro, but you find yourself enjoying ruby on rails - please give Grails (and groovy) a spin, you'll love it:

http://grails.org

http://jasonrudolph.com/resources/20070123_PSUG_Getting_Started_with_Grails.pdf


http://infoq.com/minibooks/grails

Just forgot to actually commit the version bump of xfce4-mount... forgive me...

I take back my last comment - *where* are the ebuilds for 4.4 was probably a better question :) (Thanks for all the xfce lovin'!)

emerge: there are no ebuilds to satisfy ">=xfce-extra/xfce4-mount-0.4.8".
(dependency required by "xfce-base/xfce4-extras-4.4.0" [ebuild])


;) See? We want to try it, honest!

Congrats on your new appointment. I am a long time XFCE user myself. (-:

Great, been waiting for that since the first beta. Thanks for putting it in the tree so fast!

I don't know how to better explain things without rehashing over what has been said already.

I suppose one of the key points is that you will run into problems if you try to compile generation-1 packages with >virtual/jdk-1.4, particularly when you have other packages depending on that package not having 1.5 or later bytecode.

Whether or not you will use Java 1.4 is kind of irrelevant. This is because for now, our build system needs 1.4 around to build some packages. It similar asking why you would need gcc on your Gentoo system if you never plan on compiling anything (from the perspective of a user of the gcc command). Since we do compile from source, you would need gcc to be able to build anything, because our build system necessitates it. It is not dissimilar for Java 1.4.

But in reality, given enough time, all packages will be migrated and stabilized, with unmigrated revisions getting dropped. Once that is done, it will only be packages which inheritly require Java 1.4, or have issues with any other version of Java. Hopefully, those will be packages on the fringe, and if we have the source, we should be able to fix them.

About updating unmigrated packages to depend on =virtual/jdk-1.4* specifically instead of >=virtual/jdk-1.4 (or whatever)... we believe that that time is better spent on just migrating the offending package.

Are you coming for FOSDEM?

Yep! I plan on it. Also seems like I signed up to give a talk on Java in the Gentoo devroom as well.

autocrat wrote:

Any chance of you getting a grails ebuild into the tree - that would complete the link!

Last time I looked, grails's dependency tree has a number of things we haven't even touched as far as packaging efforts go. Not to say it is impossible, but will take a bit of time and energy.

( Also - I notice the groovy ebuild requires sun-jmx, which, #1: has fetch restrictions, and, #2: is built into java 1.5 and greater, so not stricly needed if running groovy on a >= 1.5 jvm. Any chance of adding a -jmx USE flag for groovy or having the ebuild detect the java-config, and do the appropriate thing if >= 1.5? )

We've been using USE=java5 to mean 'Use Java 1.5, and all the libraries that are available with it.' This is used for at least tomcat. So that's one option.

Another option is using mx4j for the jmx implementation. This is probably a better general solution, as it would let you use it with Java 1.4.

> What is one unique advantage that Groovy has over -- say -- jython or jruby?

* the syntax is much, much closer to java.

( there you go, one unique advantage, which was already mentioned in the blog that you're responding to )

* compiles to java bytecode via groovyc, and therefore, once compiled thusly, becomes indistinguishable from a java class file

( jruby will have the above sooner or later, but currently groovy does this _now_ )

> Groovy has just been a long painful road to bringing nothing interesting to the table.

Painful? In what way were you involved with the development, design or implementation of groovy?

Brings nothing interesting to the table? Perhaps it doesn't bring anything to your particular table, that's fine, use something else.

> I just wish Groovy would stop wasting people's time.

I wish people would stop wasting people's time with useless comments. Your comment brings nothing interesting to the table. Name one unique advantage your comment has over other similarly negetive comments?

I prefer working with groovy over ruby or python because I enjoy its syntax much more. Plus I only need to learn _one_ standard library - the jdk. Plus I can go back and forth between java and groovy extremely easily with no discordance. Plus groovy has dynamic typing in addition to complete and optional static typing. Plus groovy is the second official standard language for the Java VM - the first being java itself. Plus after assesing both Ruby on Rails and Grails, I personally feel more comfortable with how Grails does things over Rails.

There's already two books released on groovy and one on grails.

Groovy is more targeted toward java shops and programmers who want to have a seamless and transparent migration path to a fully object-oriented, dynamic language.

THanks a ton for getting groovy into the gentoo portage tree! I was using the rc ebuilds and was very happy to the 1.0 release out so quickly - much appreciated!

Any chance of you getting a grails ebuild into the tree - that would complete the link!

( Also - I notice the groovy ebuild requires sun-jmx, which, #1: has fetch restrictions, and, #2: is built into java 1.5 and greater, so not stricly needed if running groovy on a >= 1.5 jvm. Any chance of adding a -jmx USE flag for groovy or having the ebuild detect the java-config, and do the appropriate thing if >= 1.5? )

The java interfaces thing was also thought up by myself in implementing groovy @ my job. It is easier for the less agile guys to look @ the java interfaces. They also spell out exactly what inputs/outputs are needed and they help quell the overall uneasiness of some people to grasp a weak typed lang.

horray groovy! Here is one advantage. Not everyone is well versed in scripting langs. The guys on my project that want to start writing in groovy can immediately use things such as not needing to define getters/setters (therefore reducing the codebase, but doing nothing else fancy). Then they can write pure java for whatever they need and I can show them how to do redo some of the java they wrote in the groovy files. slowly and slowly, they become less dependent on the compiler and more dependent on documentation, api contracts, and elegant, concise code. It is an excellent tool for teaching people scripting whilst still having a language just as powerful as jython or jruby. again, horray groovy.

Granted, 'being dynamic' would apply to jython and jruby.

Being as similar as it is to Java syntax gives you a great migration path to start using it. This means you can mostly copy and paste a Java file into a Groovy file, fix a couple syntax errors (usually they are for loops, array construction, and annotations), and hey, you're using Groovy. This isn't to say that only this Java syntax is supported. In reality, you could say Groovy is a superset of the syntax, with plenty of less-terse-than-Java syntactical sugar that one would come to expect from a dynamic language.


Because it does generate bytecode, and can be compiled down to plain old class files. This is huge, as you can start using it in the middle of otherwise Java project.

Just did some fact finding, and it does seem like jython does that latter point as well. Regretfully, jython hasn't been updated in a while, and it's kind of stuck being at python 2.2.

JRuby is a much more active project (Sun having employed the two primary developers recently sure helps!). But, it doesn't seem to sport that feature. You can only interact with existing Java code, ie you can't extend the classes, and it doesn't compile down to bytecode.

Those points are nothing to do with Groovy. What is one unique advantage that Groovy has over -- say -- jython or jruby? The others are well-developed dynamic languages that have worked well for a long time, now, with the same bullet points except for syntax. And some of the most compelling advantages to those dynamic languages are escaping from the torturously-verbose syntax that java imposes. Groovy has just been a long painful road to bringing nothing interesting to the table.

Thanks for packaging it, though. Seriously. It's good that people have options. And you, nichoj, are awesome, as this Gentoo-loving java dev knows from first-hand experience.

I just wish Groovy would stop wasting people's time.

Are you coming for FOSDEM?

http://wiki.debian.org/Java/DevJam/2007/Fosdem

hello,

nice explanation, but ... I do not understand why should I install Java 1.4 even when I do not plan to use any of the old code?

see, I am not an Java expert ... I was asked by a friend to set-up a server for testing his project - this is a new project, from scratch, no need to support older Java

then I do not understand the need for older Java? - if this is a requierement of some specific package, then why does not the package report "I need Java 1.4", why the error message is written just like "you have to have Java 1.4 in Gentoo"?

... this is confusing for me - if the problem is only a few unmigrated packages, how can you know that I will need one of these and that I need to pull all the ballast of the older Java copy?

Here is an easy way to set JAVA_HOME to the system JVM:

export JAVA_HOME=`sudo java-config -O`

@Kim

I just added a note, that you should remove any package.keyword and package.mask entries you have related to the new Java stuff, and to stop using the migration overlay if you were using it. Aside from those points, there shouldn't be any thing else involved with switching to the stable version.