Live data from Hacker News

IT Runs on Java 8

veekaybee.github.io

231–240 of 556 posts

Re: IT Runs on Java 8

#231
Reminds me on the place I work. We have many projects for many clients. ASP.NET Web Forms, ASP.NET "old" MVC. We don't have webpack, we use BundleTransformer. We don't have MongoDB, we have SQL Server and NHibernate or Entity Framework. .NET Core is not even on the calendar yet (maybe a little bit sooner now .NET framework is essentially deprecated). We use Knockout, though a replacement is being researched on. Our code is stored in SVN. We use LESS and Typescript 2.x, modern eh?

If you have a single or a small number of products to maintain, because that is your core business, you can afford to upgrade and experiment, revert if necessary. But not if you have many projects, because those projects are per definition smaller. So you take smaller steps, less risky steps. You can't move that fast, it simply cannot be done unless you can create a business case for it.

The real challenge is to resist, as the article states, all the new stuff you get slapped with every day. It is not harmful to say on a bit older technology, technology which may _seem_ to be of another era. It is still useful, and as long as it isn't a business risk it is often not a business case.

Re: IT Runs on Java 8

#232
post #185

I have seen some Excel files from end users which grows into a whole application. The users wanted more functionalty and didn't get through all the management levels to reach someone from corporate IT and just start doing it by themselve with the tools they know and develop from Excel to Macros to VBA to VBA with SQL Database (because they have a standard process in the company to request a new SQL Database and the d…

I think you misunderstood something here, corporate IT's main purpose is to prevent people from working efficiently.

https://dilbert.com/search_results?terms=information+service...

Re: IT Runs on Java 8

#233

Earlier quoted context omitted.

JDBC is not JEE - it is core Java. Servlets are the original web-container Java spec, independent of JEE. Both are great specs supported by several stable and performant implementations - rock solid tech compared to a lot of the flaky stuff you find advertised today.

How are Java programmers implementing RESTFUL APIs these days?

You should checkout new RedHat framework - [Quarkus](https://quarkus.io/). This is a framework which leverages Graal to create native images. Those images are very small and optimized. For example one of Quarkus developers showcase the size of native image, spoilers - it's [19MB](https://youtu.be/BcPLbhC9KAA?t=103). It takes 0,004s to start.

In [this](https://youtu.be/7G_r1iyrn2c?t=3104) session, RedHat developer shows how Quarkus application is being scaled. Comparing to Node, it's both faster to respond to first request and have smaller memory footprint (half the size of node).

Re: IT Runs on Java 8

#234

Earlier quoted context omitted.

> copywritten copyrighted "Copywritten" probably means nothing, but if it did, it would have something to with copy writing, the act of writing for publication (usually commercial, usually not long-form). Added: FYI "copyrighting" is not a conscious decision, or an action you can take. Copyright emerges automatically when you create a work, what they've done is defend their copyright in court, and the courts have mix…

Yes, copywritten isn't a word, but their point was that Oracle pushed for API's to be copywritable, which was not the case before their suit. It's an incredibly bad result with many shitty implications that are currently mostly being ignored but could lead to legal nuclear war at any time.

> It's an incredibly bad result with many shitty implications that are currently mostly being ignored but could lead to legal nuclear war at any time.

I mean, it has been big news, and it has already been nuclear war, with Oracle putting Google in a position to switch android from Dalvik (and successors) to OpenJDK. I agree that it could become a pretty horrible precedent (imagine if Microsoft forbade Sun from implementing Excel functions in StarOffice, or for that matter, if MS were prevented from producing Excel in the first place).

Re: IT Runs on Java 8

#235

Earlier quoted context omitted.

JDBC is not JEE - it is core Java. Servlets are the original web-container Java spec, independent of JEE. Both are great specs supported by several stable and performant implementations - rock solid tech compared to a lot of the flaky stuff you find advertised today.

How are Java programmers implementing RESTFUL APIs these days?

Spring boot + jOOQ for RDMS support.

Re: IT Runs on Java 8

#236

Earlier quoted context omitted.

The start-up code written in modern Java would similarly taken two months to develop and maintainable by an intern. The problem in enterprise tech like you found is that one is forced to use certain, non-productive old frameworks filled with legacy, over-engineered bloat. Modern Java micro-services in contrast are really fast to develop. Green field Java projects where one can make personal choices of lean technology…

> Modern Java micro-services in contrast are really fast to develop. This attitude is a bit surprising to me. The main point of micro-services is that they address a complexity problem when dealing with large organizations. That is, they allow a large organization to break into small teams that can work (relatively) independently so each team can iterate faster. However, microservices definitely make a host of issues…

And I agree with everything you say! We have followed Martin Fowler's advice. We had a monolith product developed by several geographically separated teams whose development crawled to a snail's pace and whose full build took an eye-rolling amount of time.

Micro-services allowed us to break this. Micro-services also allowed us a faster turnaround time in feature delivery and reliability. It is also easier to isolate problems.

Generally stuff in the monolith that are already abstracted by large service facades are a good candidate for a separate service with their independent data model. Avoid cross-service transactions completely. If you have a cross-cutting concern, it generally means you need a separate service managing that cross-cutting concern.

Organisational complexity is definitely increased. This can be mitigated by tooling. Our build pipeline shows the full graph dependency chain, what is built, what is getting built, what has been deployed, etc.

We have the concept of a "system" that is basically a versioned set of micro-services running off a build trigger. We developed the capability to namespace systems - ie each system of services uses separate resources (kafka/db/etc) and separate URL's (via custom domains) when deployed on our cloud platform. You can also "plugin" your micro-service into a targeted system for diagnostics. This way dev, testing and product demo teams can work independently. The latter is not micro-service best practice, but in a large, slow-moving organisation, we found it valuable.

Re: IT Runs on Java 8

#237

Earlier quoted context omitted.

How are Java programmers implementing RESTFUL APIs these days?

Many developers don't want to think too much and generally choose Spring boot for a stable, highly-popular and well-documented framework. There is nothing wrong with this choice but I find it too bloated for lean container based micro-services. Dropwizard and Micronaut are pretty good for getting a smaller and saner footprint. If you need more than REST, say you want a lean MVC-based web-framework, then Blade is also…

I'm curious to hear what specifically is too bloated in Spring Boot in your opinion for container based microservices. I've been writing microservices that run in docker in Java for a few years, then moved to Kotlin recently, all using Spring Boot, and I haven't run into anything that made me feel like they were bloated. I've also written Go and Node microservices for contrast.

Re: IT Runs on Java 8

#238

Earlier quoted context omitted.

Yes, copywritten isn't a word, but their point was that Oracle pushed for API's to be copywritable, which was not the case before their suit. It's an incredibly bad result with many shitty implications that are currently mostly being ignored but could lead to legal nuclear war at any time.

> It's an incredibly bad result with many shitty implications that are currently mostly being ignored but could lead to legal nuclear war at any time. I mean, it has been big news, and it has already been nuclear war, with Oracle putting Google in a position to switch android from Dalvik (and successors) to OpenJDK. I agree that it could become a pretty horrible precedent (imagine if Microsoft forbade Sun from implem…

> imagine if Microsoft forbade Sun from implementing Excel functions in StarOffice, or for that matter, if MS were prevented from producing Excel in the first place

The things you're talking about are already protected by patents, and the copyrightability of APIs have nothing to do with them. At the very least, for something to be copyrightable it must be some specific fixed expression (a piece of text, image, video or audio). So the O v. G ruling applies only to actual (code) APIs; not to protocols (or REST "APIs") and certainly not to stuff that's already protected by patents (the distinction between the two may not always make sense to programmers, but it is what it is; for example, algorithms are patentable but not copyrightable, while programs are copyrightable but not patentable).

Re: IT Runs on Java 8

#239
post #142

Earlier quoted context omitted.

> I am just a little uneasy with Oracle lurking around, I just don't know what they are going to do next. What do you mean by "lurking"? Oracle is the company developing OpenJDK, and it will continue to do so. All our projects are done in the open, with lots of communication.

Oracle has a long track record of Sales & Marketing tactics which we can use as a reliable benchmark to predict outcomes. Oracle will likely pursue the most aggressive strategy they can get away with Java. I don't believe Sun was suing Google, but Oracle did. The fact that Google is switching to Kotlin is mostly a means to absolve themselves of the 'Oracle risk' - it's a big change surely, a decision not taken lightl…

Kotlin uses the same VM and API, so it makes no difference in this regard. It's not a big change – it's fully interoperable with Java. You can easily take a single class in a Java application and rewrite it in Kotlin, and everything continues working just as before.

Google adopted it because, as they more or less said in the announcement, it was already being adopted by the community and it hugely improved development experience.

Re: IT Runs on Java 8

#240

Earlier quoted context omitted.

In a lawsuit, Oracle pushed for API's to be copywritten, not just their implementation. They also have paid lobbyists. They're also greedy assholes. The combo of greedy assholes and the ability to rewrite the law is a dangerous one. So, I don't use a language unless it's open with patent grants and has a non-malicious owner. At this point, Wirth's stuff is probably legally the safest.

> copywritten copyrighted "Copywritten" probably means nothing, but if it did, it would have something to with copy writing, the act of writing for publication (usually commercial, usually not long-form). Added: FYI "copyrighting" is not a conscious decision, or an action you can take. Copyright emerges automatically when you create a work, what they've done is defend their copyright in court, and the courts have mix…

That is a gross mischaracterization of what Oracle did. They didn't just defend a copyright in court. They pushed to extend copyright to a mostly functional element that copyright law has not traditionally been thought to cover. It's a tremendously harmful viewpoint for interoperability.
Post reply on HN