A Java EE Startup: Filtering information with zeef.com • Hacker News Board

Re: A Java EE Startup: Filtering information with zeef.com

#101

Post by henk53 » Mon, May 11, 2015, 10:43 PM UTC

needusername wrote: post #98

henk53 wrote: post #93

Earlier quoted context omitted.

>Please Please? You're stating that JMS is not even at Java SE 1.4, then I give you simple prove that it's at Java SE 7, and your response is "please"? >Did you ever actually use JMS in production? Yes, rather intensively. >If so did you use MDBs? Yes >If so did you use whatever happened to be the default JMS implementation of the server or did you use a stand alone message broker? The default implementation, with a…

> In fact, I just called my old friend RMS (we go way back) and according to him there's nothing in OSI that requires projects to be on Github. Have you ever attended a JCP meeting? The number one topic that pops up again and again for years has been open source (OSI) licensed TCK. The only party blocking that for years has been Oracle.

The matter at hand here was pull requests and the implied notion that those didn't happen in the Java EE universe, which I proved (again) was not true.

Instead of just acknowledging that in whatever way you're just evading the issue (again) and switching to another topic.

But to reply this new topic, TCK has been a thorn in the JCP process indeed. Not every spec has a closed TCK. CDI and Bean Validation have open ones, based on Arquillian, with an open source (OSI) license, and an associated issue tracker where everyone can open issues against it.

Now funny thing here is that CDI is rapidly becoming the underpinning of everything in Java EE. It's the core of Java EE's core.

For some other specs like JSF the TCK is unfortunately closed, but the RI (Mojarra) has such an extensive set of effective TCK tests that I wonder if there's anything at all in the TCK that's not covered by the RI tests.

Still, opening up the TCKs is another battle worth fighting.

Re: A Java EE Startup: Filtering information with zeef.com

#102

Post by henk53 » Mon, May 11, 2015, 10:54 PM UTC

needusername wrote: post #99

john-waterwood wrote: post #97

Earlier quoted context omitted.

>EAP 6.4: 8 months EAP 6.3: 8 months EAP 6.2: 7 months That's skipping a lot of updates. EAP 6.2.2: 1 month EAP 6.2.3: 2 months EAP 6.2.4 1 month EAP EAP 6.3.0: 1.5 months Etc >The other 50% lay dormant for years So this exactly the same as with a Java EE implementation or any other open source project for that matter. Many get fixed in hours, others weeks or months and some years or simply never. Spring is not inher…

> Whatever number you look at, it's not that different from the major Spring releases, and Spring is a product even, not a spec. Spring releases are every month. When there is a bug in a Java EE spec (like the WebSocket/CDI integration or the CDI annotation scanning in EE 7) you have to wait for the next major spec version to fix it. The spec has to be "perfect" for 3 to 4 years because there is no way to fix it.

>The spec has to be "perfect" for 3 to 4 years because there is no way to fix it.

This is absolutely not true.

There's the MR (Maintenance Release) for that. See for example JSF 2.1 and CDI 1.2. They were intermediate quick releases between major Java EE versions.

Even the platform spec itself can have a MR. Currently there's an MR for Java EE 7 in the works. See https://java.net/downloads/javaee-spec/JavaEE_7_Platform_MR_...

Because it's a spec, naturally more consideration has to go into it. Many implementations depend on it to be stable. In case of Spring there's only one Spring. Take it or leave it. Not having a spec behind you can be an advantage (change things whenever you want), but is a disadvantage as well (the implicit specification of how things work is in the code, but Java is not declarative and it's always a guess if specific behavior is just an implementation side-effect or an intended one).

Even changing things whenever you want can be a disadvantage. A spec naturally favors stability, which means I can run my old code with minimal or no changes at modern Java EE. Try that for regular open source libraries (be it from within the Java EE universe, Spring universe, or whatever). Chances are that the APIs and config files have changed 10 tens in the meantime.

Re: A Java EE Startup: Filtering information with zeef.com

#103

Post by edem » Tue, May 12, 2015, 2:49 PM UTC

john-waterwood wrote: post #92

edem wrote: post #88

Earlier quoted context omitted.

This statement is false. If all else being equal the better tool you use the more productive you become. Take assembly for insance. You can know assembly arbitrarily well (and any assembly tools) you won't be faster with assembly than you are with java.

With Java EE being clearly the better tool compared to Python and Ruby. Python is laughable. One word; GIL. Nuf said.

That statement is not backed by any facts by you so it is unacceptable.

Re: A Java EE Startup: Filtering information with zeef.com

#104

Post by john-waterwood » Tue, May 12, 2015, 5:57 PM UTC

edem wrote: post #103

john-waterwood wrote: post #92

Earlier quoted context omitted.

With Java EE being clearly the better tool compared to Python and Ruby. Python is laughable. One word; GIL. Nuf said.

That statement is not backed by any facts by you so it is unacceptable.

Google for "GIL Python" and have a laugh (or cry). I think that's enough backing for my statement to begin with.

Java, and so Java EE is considerably faster than Python, each and every benchmark out there proves this. Often it's up to a hundred times faster.

Java has a much richer ecosystem than Python and even more so than Ruby. Java projects are also much easier to maintain and much easier to scale.

Enough backing? It's just the start of why Java EE is the better tool ;)