301–310 of 402 posts
Earlier quoted context omitted.
Except those lambdas are not as efficient as the standard compliants VMs, as they make use of invokedynamic to generate better code, even inline calls for small lambdas.
Are you sure about that? I've looked at the way invokedynamic generates lambdas, and it's just generating anonymous classes at runtime using ASM. Inlining is from the JIT and applies to anonymous classes as well. I'm pretty sure you can get the exact same results without invokedynamic, you just have a lot more .class files to distribute.
Have you checked this talk at Java ONE?
http://parleys.com/play/5251c164e4b0a43ac1212459/about
Some older slides also available
http://www.slideshare.net/jaxlondon2012/lambda-a-peek-under-...
The #1 thing you need to make Java usable is to abandon the JavaBean conventions. When every field requires 8 lines of boilerplate it's no wonder the code looks ugly (YAGNI, and if you do need it it's two keystrokes in your IDE to "encapsulate field"). public final fields are fine, and can get your data classes something close to readable. I'd stick with maven for the build rather than Gradle; it's completely declara…
Earlier quoted context omitted.
I was just recently trying to decide between "new" Spring MVC, Dropwizard, and Play. Spring now has a bunch of slick-looking guides and tutorials. But then I looked at the actual contents of their tutorial project, and it just turned me off. For an "example" REST project, they had over 50 classes not including tests: https://github.com/spring-guides/tut-rest/tree/master/6/comp... , with many being "event" classes of…
Been there done that. 3.5 years of Play 1, but they decided to rewrite it in Scala and I left in anger. Nearly one year now of servlet dev, trying nearly anything I can get my hands on. Most I have been satisfied with is Restlet for service development, otherwise nothing even comes close to Play 1. Finally decided to harden up and learn Scala. I have set my prejudices aside and after a month, I can safely say I am a…
Earlier quoted context omitted.
For starters, you can see Groovy as "Java without semicolons". I went from Maven to Gradle and never looked back. It's superior in most ways. The tooling could be better though.
> For starters, you can see Groovy as "Java without semicolons" Not if you have to read other people's code, or understand examples you find on the internet. > I went from Maven to Gradle and never looked back. It's superior in most ways. What's it better at? I want my build tool to be simple; maven compiles my source and does my releases, and the main thing I have to configure is just a list of dependencies (in an a…
Gradle offers the declarative nature of Maven without pushing it down your throat. You don't have to write a plugin for something that can be expressed in 3 lines of Groovy (but you can, if you want to!). Instead of adapting your build to Gradle, Gradle adapts to your needs. That's often a point of criticism from Maven users, because every Gradle build looks different. But that's the point: Everyones needs are different. Of course that only applies if your build is beyond the standard compile/test/release configuration. A simple configuration looks pretty much like a Maven POM (minus the tag soup).
Earlier quoted context omitted.
I have since repent myself. Google did indeed managed to pull a Microsoft and now we have a forked Java implementation getting steady behind the standard Java implementations. Even J2ME is more compatible with its big brother than Android. KitKat has now partial support for Java 7, with libraries still missing some pieces. Dalvik and ART still don't support invokedynamic bytecode. And since almost no one has KitKat,…
> Even J2ME is more compatible with its big brother than Android. Are you serious? J2ME is even more crippled than Android's Java (no reflection, no Swing, no AWT and stuck in Java 1.4). J2ME has been dead for more than half a decade and we have Android to thank for that. Good riddance.
Earlier quoted context omitted.
After doing couple of Android projects with Gradle I've felt like Maven is a godsend. It might require writing some XML to declare what your project does, but at least it WORKS and at least it does not waste my time by forcing me to write code to include pieces of projects and properly process project (e.g. including native code, Robolectric testing, renderscript and some other things). Also any compilation inside ID…
> Right now (at least for Android), Gradle is a colossal waste of time due to lacking features, extremely slow execution and myriad of bugs which will eat away productive time on project Are the sparse features, slow executes, and bugginess due to Gradle or due to the scripting language it uses? www.gradle.org/overview says they will happily support any community effort to create additional build script engines for G…
There was a Grails wave here in Germany, but now I seldom see anything related to it.
Earlier quoted context omitted.
w/ regards to gradle using groovy.... in gradle I can easily add in variables to my dependencies, I can write conditionals (if System Prop X then include dependency Y). Basically anything you can do in code, you can do in gradle very easily. Auto-complete does work in IntelliJ 13 - at least for groovy code type stuff. Nothing for the gradle DSL (that could be implemented of course). > Java devs do many things manuall…
> I can write conditionals (if System Prop X then include dependency Y). I stand corrected. That would be extremely useful. Maven is really awkard about these things. EG: "I want to run integration tests but not unit tests". Here's how: http://stackoverflow.com/questions/6612344/prevent-unit-test... Pretty lame.
Earlier quoted context omitted.
Gradle is mainly being pushed by Grails and Android development. I don't know of any other project using it. We are always doing Maven or Ant. If Gradle is the future I hope it gets improved, I gave up on Android Studio given its dependency on Gradle and how it drags my dual core with 8 GB to its knees when compiling.
> I gave up on Android Studio given its dependency on Gradle and how it drags my dual core with 8 GB to its knees when compiling That could be the slow, dynamically-typed Groovy in Gradle that's dragging your machine. Gradle needs to bundle another build language. Since the goal of statically-typed (and hence speedier) Kotlin is to make it easier to write IntelliJ IDEA [1], on which Android Studio is built, instead o…
So far I have been using the Eclipse ADT/CDT for my hobby development, mainly with C++ (just graphics stuff).
Then I thought to try out Kotlin instead, but could not. It was worse than waiting for my NDK C++ builds to finish, with the whole computer at 100% CPU usage.
I ended up filing a ticket, like many other developers already did.
Earlier quoted context omitted.
Indeed, Option in Scala has the same problem. I understand null is needed for backwards compatibility, but it makes Option the poor man's Maybe...
> Indeed, Option in Scala has the same problem eh? scala> val safe = Option(null) safe: Option[Null] = None
scala> val x = Some(null)
x: Some[Null] = Some(null)