Eclipse... of the Sun (Microsystems).
Apparently, Oracle has finally gotten tired of IBM (through Eclipse) saying "we can do it better" and trying to manage it and said "ok - you can do it."
Eclipse... of the Sun (Microsystems).
Apparently, Oracle has finally gotten tired of IBM (through Eclipse) saying "we can do it better" and trying to manage it and said "ok - you can do it."
I also doubt IBM still cares about Java EE. Their last JSR (Batch/JSR-352) was particularly disgusting and seems to be abandoned already.
Good grief. Another mountain of XML programming. It's like the last 10+ years of software engineering never happened.
I wonder how many half completed JSR-352 implementations will emerge.
Plus, there is a ton of things that json can't do or isn't supposed to do (things like defining a grammar, xpath, xquery, xslt and a lot more)
I think XML got it's bad rep from people applying it where it's bulk and complexity is just not needed. For instance, storing configuration for an application that you completely control or shuffling around data inside of an application domain that you can change at will.
XML is good for anything that looks like document markup.
Given that my Maven builds run circles around the Android Gradle ones, and that it is still a session subject at Google IO, I hardly see that as progress.
[0] No offense to Groovy; I'm only hating on Gradle's usage here
* Instructive - Actual low level commands are basically entered in the build file, with some flow control logic. An example is Make. Ant is another, though Ant straddles the line between Instructive and Imperative. In military terms, you dictate individual unit actions.
* Imperative - Build commands are entered into the build file, with each command having parameters used to control how it executes. Each build command represents two or more low level commands. There can be some declarative configuration, but the main part of the build is still a program of commands. Examples are Gradle and Rake. In military terms, you dictate individual unit tactics.
* Declarative - The build file is now no longer about entering low or high level commands, it is about declaring your intent, i.e. what you want the build to do. Examples are Lein and Maven. In military terms, this is providing units with Commander's Intent and letting the units do what they do best.
* Predictive - The build file is declarative, but the build ecosystem tracks developer activities and incorporates AI technologies to predict what the user's intent will be, and to inform the user so they are better able to determine their needs. In military terms this is strategy augmented with a Centaur System (a system with both a human and one or more AI components that work together as one entity).
Communitivity, Inc is building Chiron, an Open Source predictive build ecosystem that will be released in 2018. Follow @Communitivity on Twitter for more information in the coming months.
Further, the comment is written in a pretty grating marketing-style: "We at Communitivity see build ecosystems..." and ends by plugging a product. Also, military analogies are pretty weird when addressing an audience of people who on average have substantially more experience with build systems than with military command structure.
I looked at your comment history, and this is not how you write. (Also, more of a curious aside, you've had a profile with that name for 6.5 years, and this comment seems to be the first record of you being a plural "we" launching a product?). You clearly understand the style of this community and how to contribute, and should not need explaining why copy-pasting an only barely not-off-topic marketing blurb would be unpopular.
Which is ironic, because a good chunk of my success as a contractor is improving DoD projects I work on by applying the stuff I've learned from the startup community through HN, blogs, and friends doing startups.
You are also right regarding evolution, it's not the right word and I should have taken the time to come up with the right word - since it can't be evolution as Gradle came after Maven. Also, I was responding to a comment thread that had already started to drift from the GP to be on Maven vs. Gradle, and shouldn't have drifted it further.
To answer your question on the profile.. I had an aborted attempt to do a startup when the company I was with changed their IPR terms at the same time my parents died, and I wound up putting that dream on the shelf until I left that company. For various reasons (family medical costs among them) I wasn't able to go all-in 100% on my startup.
I appreciate the help, and will make sure I change hats before commenting in the future. To end on a smile, I'll show why this will be harder than you might think. Writing the first sentence I had a brief moment where I was about to type "Your help is greatly appreciated. I'll ensure my comments are of higher quality in the future, and carefully consider the content of future postings". Then I realized I was doing it again.
Groovy (on the JVM) joined the Apache Software Foundation 2 years ago after being ditched by VMware/Pivotal. Like the EF, the ASF is another place where software goes to die -- Apache Groovy and Eclipse Ceylon. There's nothing wrong with the original premise of Groovy being a lightweight dynamically-typed scripting language for the JVM, by adding closures to Beanshell. But along the way it got plagued by feature-creep and leadership problems, and started trying to compete with statically-typed languages like Java and Scala. It's only real widespread use nowadays is for writing 20-liner build scripts for Gradle in Android Studio. As for Grails, no-one's upgrading their old version 2 projects to version 3, or starting new projects in it.
Or maybe you said that 1970's batch were inferior to today's batch. In which case I'd be happy to read what non-superficial differences exist...
However, it's worth pointing out that MOST tech concepts people regard as "modern" today are actually re-treads of 1970's ideas.
That's strange. How do they make money off SE but not EE? EE has been the cash cow that kept Java alive after applets fell out of favor.
I now gather that it is a collection of helpful packages constituting a framework, but distributed separately from mainline Java core packages.
When targeting EE application servers, you don't need to worry at all where it is being executed.
As an application, container, bare metal, whatever.
Of course this only works ad long as no native methods or APIs for file or process management are used.
I have no insight into Oracles reasoning or finances, I can just see their actions. While I assume they make money off WebLogic licenses I can't image that revenue is growing in the double digit range per year. I assume that Oracle as a publicly traded company is forced to produce growth numbers. These days that's could. They probably some imagine to provide some sort of Java could, that would explain why they pushed so hard for Jigsaw. This doesn't really have make sense to you and me, just to Oracle execs.
So a good fit to Websfear then?
https://www.ibm.com/cloud-computing/bluemix/swift
They used to be one of the main contributors of Swift on Linux.
Poor ole big blue has seen better days...
Watten Buffet even wrote it off.
[0]: https://console.bluemix.net/catalog/?cm_mc_uid=5252549325751...