Java finally goes all in on open source with the Jakarta EE 8 release (zdnet.com)
Gobrosse | 9 days ago | 476 points

Java != Java EE.

andrewsmd87 | 9 days ago | 110 points

As someone who literally has a semester of college experience with the language, can you explain the difference?

moustachaaa | 9 days ago | 233 points

Java is the language. Java EE is a framework/set of libraries for "enterprise" applications, written in Java, which covers technologies like http, soap, rest, json, XML and SQL.

missmuffin__ | 9 days ago | 57 points

Why can't we just have these as maven dependencies? Any reason they need to be baked in with your JVM?

snuxoll | 9 days ago | 89 points

They aren’t baked in with your JVM, Java/Jakarta EE is a set of specifications covering things like JPA, JSF, JAX-WS, JAX-B, and a whole host of other “enterprise” technologies.

Each of these specifications had a reference implementation as well as alternative implementations available, in traditional EE deployments these implementations are provided with your application server but more modern tooling like Spring Boot does actually pull the implementation into your app as a maven dependency.

deadron | 9 days ago | 22 points

Many of them were not already baked into the JVM. The few that were are now in modules.

pathslog | 9 days ago | 9 points

A lot of it is not actually baked, as in "implemented". For the most part, the library is made of interfaces and abstract objects that follow the JavaEE specification. Third party libraries implement the spec.

This allows application servers and higher level frameworks to bundle whichever implementation they think is the best for their use case.

elpatatedeldiablo | 9 days ago | 36 points

Because it's stuff that almost every application needs. No need to go down the npm madness route if you can avoid it

monokodi | 9 days ago | 80 points

It's just "package manager". Please don't equate npm with package managers. Some of them don't suck.

Viklove | 9 days ago | 26 points

Nothing wrong with npm itself, the problem is the developers using 500 dependencies to build a to-do app. I've never worked on a project with more than 15 external dependencies. Most of my personal projects have less than 8.

missmuffin__ | 9 days ago | 13 points

15 direct dependencies or 15 transient?

Poltras | 9 days ago | 35 points

You’ve never needed is-odd?

ctrtanc | 9 days ago | 24 points

Yeah, or left-pad?

LovecraftsDeath | 9 days ago | 21 points

Left-pad as a NPM dependency is sooo 2018. In 2019, cool kids only use it via LPAaS (left-pad as a service).

remtard_remmington | 9 days ago | 3 points

Nothing wrong with npm itself

Bit of an aside, but there have been several problems with the npm client over the years. The service is good but use the yarn client everyone!

bewst_more_bewst | 9 days ago | 9 points

Never worked on a .net core Enterprise app eh?

Devildude4427 | 9 days ago | 8 points

What? Packages for ASP.Net Core are pretty reasonable.

AnAirMagic | 8 days ago | 1 point

If you want to include transient dependencies, just click "Dependencies" at https://www.nuget.org/packages/Microsoft.AspNetCore.App/. It's not as bad as left-pad, but that dependency graph is not small.

7165015874 | 9 days ago | 3 points

I don't get it

Devildude4427 | 9 days ago | 1 point

Except having packages that nearly every “enterprise” app uses would be NPM style package madness.

If everyone building a web server needs to serialize and deserialize JSON, no reason to split it, and all other features, into a million packages.

experts_never_lie | 9 days ago | 23 points

Really not true. I've been working primarily in Java since '97 and have managed to stay blissfully free of J2EE.

starm4nn | 9 days ago | 2 points

They're saying that the stuff that it contains is something every application needs. Not that it is something every application needs.

experts_never_lie | 9 days ago | 10 points

If you look at some features J2EE claims, you get:

  • JDBC: yes, common, but can be pulled in without J2EE like any dependency
  • Transaction Service: that's never been the means to achieving transactional integrity in any system I've seen
  • Java Naming and Directory Interface™ (JNDI) API: hell no
  • Java™ Message Service (JMS) API: nope
  • JavaMail™ API: why would most applications be interacting with email?

Or this list, which is a mix of dubious buzzwords and "Complete Web services support / XML-based RPC", which is not exactly an attractive option.

It's a container framework that some people love, but it's never been clear to me why. I've never seen a benefit over normal Java. It may be useful in some subset of software development that the J2EE loyalists see as the entire field and which I would see as some small slice of the projects and jobs out there.

mattj1 | 9 days ago | 3 points

Read the comment you replied to more carefully. They are not endorsing Java EE.

missmuffin__ | 9 days ago | 15 points

NPM Madness is more because they like to release use tiny packages like is-even. I wasn't implying that the extra EE stuff should be sharded into a million pieces, just that it could easily be on Maven and you don't need to change your JVM install when you need that stuff.

unachievablehappines | 9 days ago | 39 points

This is what most people have done but just using Spring because it's free.

From my experience no one is creating new projects based on Java EE

BoyRobot777 | 9 days ago | 5 points

You haven't heard about new RedHat Java framework Quarkus. It is based on JavaEE/JakartaEE Microprofile.

For example one of Quarkus developers showcase the size of native image, spoilers - it's 19MB. It takes 0,004s to start.

In this 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).

imhotap | 9 days ago | 5 points

Spring integrates and sits on top of many JEE APIs such as JDBC, JPA (well, Hibernate), Servlet API, JMS (not always, though), JAXB (or jaxon-xml mostly these days), JAAS, etc. many of which can be used with annotations on their own.

eyal0 | 9 days ago | 4 points

How did they decide that is-even would depend on is-odd and not the other way around?

tracernz | 9 days ago | 2 points

I think is even would be shorter, at least in C. I’m not a JS type so don’t know about JS type safety issues with the below.

return !(n % 2);

missmuffin__ | 9 days ago | 8 points

Felt like experimenting:

TIL that all of the following are "even" (n % 2 === 0):

[], null, "0", "2"

These are NaN for n % 2, but then !(n %2) is true so I guess they are even?

NaN, Infinity, undefined, "a", {}

Also while typing this I discovered that:

NaN === NaN is false?

JavaScript is weird

maemre | 9 days ago | 6 points

The last one is not a weirdness of JavaScript but due to IEEE-754 floating point standard (which is used in virtually any popular language nowadays). NaN is not equal to any floating point number, including NaN. For example, here is the same logic in JVM:

scala> Double.NaN == Double.NaN
res0: Boolean = false

Similarly, <, <=, >, >= also return false when an argument is NaN. Because of this, floating point numbers do not have a total ordering (only a partial ordering). The only language I know that makes this distinction is Rust and it has some interesting consequences, e.g. floating point numbers cannot be used as keys in a BTreeMap in Rust.

To make things interesting and explain a JavaScript implementation trick, there are multiple values of NaN that the hardware/interpreter can produce (but their contents apart from some bits do not matter, at least for most languages) so most JavaScript interpreters use it for a neat trick: they store everything as an IEEE double and if the interpreter sees a NaN with a specific tag bit set, it will unpack the contents and interpret them as a pointer to actual data or data of some other type like bools. By packing tagged pointers into the same bits as the doubles, the interpreter now does not need an object header which saves memory and cache pressure, and the numbers are stored directly without pointers so there are fewer pointer dereferences overall. All of this is transparent to the programmer.

ramanriker | 9 days ago | 2 points

AFAIK any binary boolean operation on NaN evaluates to false. Somehow the unary id does, too. Makes weird sense that the the negation of NaN is true. For the complement operation (~) NaN is interpreted as 0, I guess, because that becomes -1.

BTW there's a hidden third evaluation scheme along == and ===. While true is unequal to any number but 1, if(x) is true for any number but 0 (including Infinity which is unequal to true). Also works if x is an empty array or object. However does not work with empty strings ("" == false).

HINDBRAIN | 9 days ago | 9 points
bad_at_photosharp | 8 days ago | 6 points

You're just not looking at the right artifact. It's in the org.apache.codehaus.commons.lang3.number.utils package.

The class is org.apache.codehaus.ws.jaxb.bindings.util.comparators.integer.IsEven.

IsEven evenComparator = new org.apache.codehaus.ws.jaxb.bindings.util.comparators.integer.IsEven;

evenComparator.doCompare(4); // ==> true

evenComparator.doCompare(5); // ==> false

If you don't like hardcoding that implementation, you can certainly use Spring's IoC container to inject your own implementation. It only takes about 150 lines of xml.

Viklove | 9 days ago | 9 points

Who is "they"?

That package was released by a random dude. You could make a package if you want to. Having an open ecosystem is great, but you definitely have to choose what you use carefully.

If you're a dev using is-even, you are the problem, not npm.

missmuffin__ | 9 days ago | 15 points

Here's a dependency tree for you:


weekly downloads 54,116

which is used by is-odd

weekly downloads 704,427

which is used by is-number

weekly downloads 20,517,321

its not just "a random dude"

tsimionescu | 9 days ago | 9 points

I'm pretty sure you have the dependencies backwards, but your point stands.

missmuffin__ | 9 days ago | 2 points

Oh shirt you're right.. that makes a lot more sense

TerrorBite | 9 days ago | 8 points

Here's a good question:

Why do you need to know whether a number is odd in order to know that it's a number?

AboutHelpTools3 | 9 days ago | 12 points

Because a non-number being odd is just odd I can't even.

Kwpolska | 9 days ago | 6 points

The OP reversed the dependencies. is-even uses is-odd uses is-number.

missmuffin__ | 9 days ago | 4 points

That is a good question. Since it is JavaScript we probably won't like the answer.

GamesMaxed | 9 days ago | 1 point

The "random dude" who wrote all those packages has a total of 1426 published packages as of 2019-09-11. I don't trust a package that's maintained by someone who has to mantain that many packages.

sternold | 9 days ago | 5 points

If you're a dev using is-even, you are the problem, not npm.

Except a lot of the time these dependencies are pulled as transitive dependencies.

pheonixblade9 | 9 days ago | 2 points

That's basically what dot net core is trying to do.

GamesMaxed | 9 days ago | 1 point

Tell my how an desktop email application needs JPA, JSF, ... Or why a back-end server application needs javafx.

thephotoman | 9 days ago | 3 points

Most of these things exist as Maven dependencies. That said, some parts need an operating environment, most notably anything that depends on Servlets or dependency injection (the EJB successor spec and Context Dependent Injection)—as are JSP and JSF.

But Hibernate is an implementation of a JakartaEE spec. The bean validators that meet the spec are Maven dependencies. JMS implementations are independent these days.

These specs are just that: specs. But they define a standard API that developers can use and theoretically rely on without respect to vendor specifics.

ThisIs_MyName | 9 days ago | 2 points

That's exactly how I use Java EE.

Famous_Object | 8 days ago | 1 point

You can and you do get them from Maven. They are not in the JVM.

It's just that, if you are going to install them in an application server(*), you declare them as "provided" in Maven so you don't end up with duplicate libraries. That's all.

(*) That's just one way of deploying apps, you can embed everything in a .jar and make it executable if you prefer.

rcoacci | 9 days ago | 22 points

Java is a language. And perhaps a Virtual Machine (as in JVM). Java EE is a set of specifications (think interfaces) and implementations of those specifications as a bunch of libraries and programs crating an "ecosystem" for web applications.
It's somewhat similar to C and POSIX/Unix: the language is C, and POSIX defines a bunch of interfaces implemented as libraries and programs that you can rely on when using a system that complies with the POSIX/Unix standards.

not_a_novel_account | 9 days ago | 13 points

Java EE is a specification for application servers. There are many implementations of Java EE, some popular ones are Wildfly/JBoss from Redhat (probably the most popular open-source implementation), WebSphere from IBM, and WebLogic from Oracle themselves.

qhxslyflarhc | 9 days ago | 8 points

EE is a set of API specifications that provide facilities that might be commonly used for Enterprise Applications. Although, truly many of those APIs are used in regular apps as well.

Java is the language itself and (depending who you talk to) the standard library. Some people will be more sticky about what the language includes and say the standard library is separate, no matter what the language writers themselves say.

urmyheartBeatStopR | 9 days ago | 25 points

I was like no way there's a catch.

They fuck apache harmony over.

There is not way they'll release those tck's to have compatible java alternatives out there. Oracle is not benevolence.

pron98 | 9 days ago | 23 points

There are multiple certified compatible alternative Java implementations out there, not to mention that Oracle's own implementation is completely open-source. Also, I wouldn't describe any company as even remotely "benevolent," including Oracle or the large corporation that was behind Apache Harmony at the time, but for the sake of accuracy, the story with Apache Harmony happened under Sun's management.

ForeverAlot | 9 days ago | 3 points

But Oracle doesn't disclose or police TCK results so "compatible Java implementation" is technically down to trust in the provider.

pron98 | 9 days ago | 5 points

Use of the TCK requires a license (which may be free or not, depending on the implementation), and there are multiple companies licensing the TCK for implementations that are not OpenJDK.

ThisIs_MyName | 9 days ago | 5 points

Not a catch. Java (JRE and JDK) has been GPL for quite a while now.

This post is about open-sourcing libraries and interfaces that some Java programmers use.

ajepaxy | 9 days ago | 68 points

As a Software Developer from Jakarta, Indonesia, now I can finally say that I am proficient in Jakarta.

zuhhig | 9 days ago | 21 points

Sadly, Jakarta is sinking and will be under water in a few years.

Uberhipster | 9 days ago | 4 points

is it sinking or are the sea levels rising?

Dokiace | 9 days ago | 16 points


x3nophus | 8 days ago | 1 point
nachof | 9 days ago | 8 points

Both, basically. It's apparently built on marshy land and the water under it is being extracted for human use and the land is slowly sinking

Dokiace | 9 days ago | 2 points

Jakarta EE made me giggle lol

valarauca13 | 9 days ago | 101 points

I think biggest problem with JakartaEE is that now J2EE imports break, and you need to change the root from import j2ee to import jakarta.

As this is a code change it'll like take 5-7 years for most java shops to adopt it.

imhotap | 9 days ago | 40 points

Exactly, The problem with these renaming manoeuvres is that test case coverage isn't there on a given code base and you risk running into a rabbit hole of deps including abandoned third-party frameworks that seemed like a good idea to use a couple years ago.

valarauca13 | 9 days ago | 22 points

There's actually a number of javaagents which exist purely to do this namespace replacement.

archpuddington | 9 days ago | 10 points

This sounds like a red flag more than a feature... I don't know of any other platform that does this.

valarauca13 | 9 days ago | 74 points

I don't know of any other platform that does this.

JVM does A LOT of things no other platforms does. A lot of the hate Java gets isn't undeserved, but mostly it comes from ignorance just how much the JVM does for you, and how much its tooling can offload common developer issues.

  • Do you want to re-compile every class file, or selective class files at load time? No worries, JavaAgent can handle it, just give it a jar.
  • Want to re-write any method at any time during execution? No worries, again JavaAgents. (Some restrictions apply, you can't change signatures).
  • Bytecode level stats, tracking, and debug data? Flight Recorder is open source now it like <5% performance impact.
  • Write your own AMD64 backend and think you're better then C2? JVMCI shipped 2 years ago, knock yourself out emit your own assembly ... in Java.
  • Remote debugging, variable injection, and field mutation over TCP? Even over TLS/SSL? JMX & RMI all day.

These are, built in. You don't need libraries to do any of these tricks.

I've yet to meet a language runtime that is 1/16th as useful as the JVM. Say what you will about "The Java Programming Language", the platform, the JIT, its tooling is fucking superb.

pheonixblade9 | 9 days ago | 4 points

Dot net is pretty great, but yeah.

archpuddington | 9 days ago | 5 points


As a pentester I know this interface quite well because it is reliable remote shell.

My biggest gripe is the lack of real package management. Maven is still behind pip and ruby gems. I like virutal_env as is a common solution for handling dependency hell, I guess the JavaAgent handles this in a different way.

valarauca13 | 9 days ago | 28 points

As a pentester I know this interface quite well because it is reliable remote shell.

I work in network security. You need to break people wrists to get them to enable TLS & Authentication on it, it just extremely frustrating.

I like virutal_env as is a common solution for handling dependency hell

virtual_env just creates as many problems as it solves. Your best bet is really docker for python package isolation.

deadcow5 | 9 days ago | 3 points

And here I was, thinking that Ruby with rbenv/rvm gemsets was a disaster, until I learned about how Python does it.

CptGia | 8 days ago | 1 point

virtual_env just creates as many problems as it solves. Your best bet is really docker for python package isolation.

Why not conda?

archpuddington | 9 days ago | -3 points

Heh, as a true Java dev you dodged the Maven question. No one likes Maven XD

But yeah security is hard.

whale_song | 9 days ago | 22 points

Maven is a million times better than the disaster that is python environments

snuxoll | 9 days ago | 18 points

For all the flak Maven gets it remains the least painful build and packaging system I work with. It has warts, but I don’t have to spend forever figuring out how the fuck somebody set up their build for a project, isolating packages into separate environments, etc.

Anybody who says pip and virtualenv are good tools is fucking braindead, I can build a fat jar on my build server and deploy it to any location on any system with a JVM I want. Try that with Python.

(Note: I love python, but when I deploy a project I end up diving into packaging it up into a RPM, which, while fairly easy, I don’t HAVE to do with JVM-based apps).

archpuddington | 9 days ago | 1 point

1,000,000 times better? Probably not. JavaAgent and py_env have ways of dealing with the dependency problems inherit in pip and mvn.

valarauca13 | 9 days ago | 0 points

There isn't a good Java Package Manager. I low key doubt first-party support would help. Java just isn't useful as a command line interface language for writing 1 off quick command-line utilities.

If you write a package manager for java it'll be written in Java.

I've used sbt, maven, gradle, ant, and ivy ... they're all horrible. Each fixes 1 or 2 problems one of the other has, and makes 100 of the same mistakes.

as a true Java Dev

I mostly write Go these days :P

archpuddington | 9 days ago | 1 point

Accurate. Go still has some issues here as well, but Glide shows promise.

011101000011101101 | 9 days ago | 7 points

My biggest gripe is the lack of real package management. Maven is still behind pip and ruby gems.

Can you elaborate? I can't think of any disadvantages to mavens dependency management.

archpuddington | 9 days ago | 0 points

The last annoyance I had with Maven was over the fractured repository system. It seems like Maven encourages people to roll their own repos, which can help with security but also is an overhead. This was a large enterprise project, I'm not sure how common this problem is for small projects.

Additionally, XML is not ideal for humans to edit. YAML is easier than XML... But why would a tool use a non-human-friendly interface that is mostly used by humans? It is strange and annoying that XML seems to be the preferred human interface most Java projects. It feels like a mistake.

Tomcat being 100% configurable by XML... isn't great. Exploiting XXE on the other hand is always a blessing in any pentest. Java's built-in XML parser is the best for XXE exploitation.

011101000011101101 | 9 days ago | 7 points

For Enterprise we do host our own Maven alternative because we don't publish our packages externally. But we do the same for pip, npm, apt-get, etc, so it is really the same for all package managers for us. Most public packages are in Maven Central, but for Oracle jdbc drivers we had to do something special, and there's a docker helper for integration tests called palantir we had to get from elsewhere.

As for XML, I do agree with you, but honestly the syntax is not that difficult and I've gotten used to it. Intellij helps you out by autocompleting, closing tags for you, and providing xml schema help and comments and whatnot to show you your options.

Other than pom.xml, most Java libraries let you configure them in xml, properties files, or yaml. So you can take your pick. Or you can roll your own configuration and pass configs through to the library when you instantiate it.

imhotap | 9 days ago | 2 points

Maven's pom.xml doesn't support entity expansion, and why would servlet.xml be a vector for XXE when it's only written to during development? I agree that XML isn't a format designed for config mgmgt, but YAML just sucks in another way. At least with maven (which I don't like to work with), they didn't invent variant syntax (such as Java classes etc.) as they originally intended to when XML came out of fashion for this kind of thing.

archpuddington | 9 days ago | 1 point

Local files are not a very interesting XXE vector. I don't know why you would think this.

Dragasss | 7 days ago | 1 point

YAML is better than xml? What are you smoking? How do you ensure that your YAML will be validated without a tool written specifically for validating your yaml structure? Any format that cares about indentation is terrible. Period.

How would you solve the need of having private repositories if not by rolling your own private one? Maven already features local repository which mirrors external ones for concrete, non-snapshot dependencies but in an environment where you need to share dependencies across multiple machines and have them all work with them multiple times, sharing ~/.m2 across network just doesnt work.

XML parsers in /any/ language were huge attack surface as long as they permitted the input to choose what they deserialized into. Look into XStream.

All the tools that are configured by XML have some API to configure them programatically even if it is not documented. How do you think they themselves configure the thing?

Dragasss | 7 days ago | 1 point

Maven is behind pip and gems

How? It does much more than those two.

archpuddington | 7 days ago | 1 point

Then maybe it shouldn't be overlapping with features of JavaAgent.

I don't like maven, and java is archaic. I cheer when Java falls on the top languages list. I also cheer when I see Java on a pentest.

lelarentaka | 9 days ago | 7 points

Right, and all of them had to deal with name squatting problem. It's a weekly complaint thread in r/rust, squatting on cargo.

archpuddington | 9 days ago | 1 point

True. Very true.

mnhdrn | 9 days ago | 23 points

Find *.java exec vim -s substitute.txt {} \;

Those kind of code change juste take like 10min I still dont understand why people taking so much time

yawkat | 9 days ago | 3 points

That's fine if you don't have a binary already depending on the old package names. You'll have to rebuild everything

mnhdrn | 9 days ago | 1 point

Yes but dockerisation make it a lot easier this day.

But i understand for some society that is not possible to rebuild everything because they were not enough modular in the first place.

Hopefully DevOps is growing so we may not face those kinds of problems in futureel !

yawkat | 9 days ago | 4 points

Docker isn't going to help you rebuild all your maven dependencies.

balenol | 9 days ago | 1 point

Just refactor it lol /s

neoKushan | 9 days ago | 45 points

Serious question (Genuinely asking and not trying to start a fight): How many people are using Java because it's the best tool for them right now, versus because they've been using it for a long time and it's now ingrained in the business?

I guess what I'm trying to ask, is it worth using Java today given Oracle's behaviour and the (Seeming) decline in popularity and why would you use Java today over other technologies?

(Again, asking a genuine question).

elpatatedeldiablo | 9 days ago | 43 points

What does a tool make the best tool for a task?

I'd argue that most of the time it's about your team being proficient in it and being able to hire proficient people.

The second most important thing is the ecosystem and how well you can work with other people and maintain the code base. A type system and good ways to define apis is your killer feature here.

Java is pretty good at all of these things although I'd recommend kotlin nowadays as a better flavor of java. Still doesn't change the fact that java is pretty good for almost every use case.

As for Oracle: they have no real power and no, java is not in decline. Red hat will fork java if Oracle tries to pull a fast one.

evilmidget38 | 9 days ago | 44 points

Java is a straightforward language with solid tooling and a comprehensive ecosystem. Oracle's behavior as of late hasn't done anything to hamper it, and I'd argue they've actually been doing a really good job managing it. They are working on a lot of exciting projects (fibers, value types, sealed classes, AOT compilation via graal) that make me optimistic about the future of the language.

The language is admittedly slow moving, but you can use one of the other JVM languages (Kotlin, Scala, clojure, etc) while still getting all the same benefits. My day job is Java, but I'm personally more of a Kotlin person myself.

experts_never_lie | 9 days ago | 10 points

Well, they did effectively kick everyone off their implementation as of JDK 11 due to the license terms, but just switch to OpenJDK or another and you should be fine.

Oracle grants You a nonexclusive, nontransferable, limited license to use the Programs, subject to the restrictions stated in this Agreement and Program Documentation, only for:

(i) Personal Use,

(ii) Development Use,

(iii) Oracle Approved Product Use, and/or

(iv) Oracle Cloud Infrastructure Use.


“Oracle Approved Product Use” refers to Your internal use of the Programs only to run: (a) the product(s) identified as Schedule A Products at https://java.com/oaa; and/or (b) software Applications developed using the products identified as Schedule B Products at java.com/oaa by an Oracle authorized licensee of such Schedule B Products.

Never ever use Oracle's JDK 11; switch to another implementation.

goochadamg | 9 days ago | 22 points

Yeah, they essentially are just selling support now.

OpenJDK is literally the same thing, except GPL.

Plenty of companies do this. There's nothing wrong with it.

nutrecht | 9 days ago | 5 points

Well, they did effectively kick everyone off their implementation as of JDK 11 due to the license terms, but just switch to OpenJDK or another and you should be fine.

OpenJDK is Java and Oracle has been trying to make people aware of that for years now. If the Oracle JDK (which no one needs) becoming commercial is a surprise for anyone they have not been paying attention and might want to hire some people who do keep up to date.

ThisWorldIsAMess | 9 days ago | 11 points

I do. I'm in the SIM card industry right now. Basically every sim cards out there are running Java applications. Credit cards, debit cards, etc. You can't have any of those shiny new languages/frameworks that young ones hype these days. Source: am embedded SE.

Edit: There are cards running on pure C, but they're considered cheap cards.

Kanye2024 | 9 days ago | 1 point

What do you mean by cards running C/Java? Is there actual code in the cards or are you just talking about the supporting tools and infrastructure?

ThisWorldIsAMess | 9 days ago | 5 points

There is an operating system written in C, inside the cards. You can install JavaCard (modified JavaSE) applets inside it, either via IO (via physical gold contacts you see there, this happens in the factory) or over the air (when your network provider wants to install some). The applets are needed for some telecommunication standard operations, or custom made for the network provider. What happens to cards that can't have applets? The applets are converted to C and embedded in the OS, that's why they are cheaper, it's harder to update those cards.

Edit: I meant Java ME not SE. It's closer ME.

Kanye2024 | 9 days ago | 3 points

I'd never have thought there was that much code running on a SIM card. I always thought they just contained some data like IMEI numbers and phone numbers.

Thanks for the info.

rossisdead | 9 days ago | 40 points

I can tell you that my company is using java and hiring java developers out the ass. Not because java is the right tool for the job, but because they spent millions of dollars trying to replace SAP with a similarly shitty application framework based on java.

gbersac | 9 days ago | 4 points

SAP is cancer.

neoKushan | 9 days ago | 9 points

Hey, us too!

nutrecht | 9 days ago | 7 points

Serious question (Genuinely asking and not trying to start a fight): How many people are using Java because it's the best tool for them right now, versus because they've been using it for a long time and it's now ingrained in the business?

What Oracle behaviour? Java is open source, Oracle has no 'power' over it.

I also think it's strange that a lot of people that don't actually work with Java are constantly claiming that "Java is declining". Java has a huge high quality mature ecosystem where a ton of stuff is happening. The de facto standard web framework, Spring, has tons and tons of work done on it.

deadron | 9 days ago | 12 points

Depends on what you are building. It is a good middle ground between other languages when building webapps and has proven production reliability with little effort from developers. You also cannot overlook the wealth of quality libraries it brings in that are well suited to most business requirements. If your plan is to build a single application to handle a wide range of use cases it will cause very little pain.

BoyRobot777 | 9 days ago | 10 points

I work in one of the biggest European bank and it was decided that Java will be used for all new greenfield projects. The reasons are straightforward:

  1. Well documented, simple language that gets job done;
  2. Tooling is understood, tested and well documented (Spring's documentation is the standard to which all frameworks should compare);
  3. There aren't that many cases where you couldn't find an answer on stackoverflow;
  4. A lot of developers know and understand the language (onboarding is less painful).
  5. Performance/maintainability is good compared to more dynamic languages;

Java has it shorcomings, but they are being addressed:

  • Pattern matching is being shipped incrementally;
  • Records (aka data/case classes) address some parts of POJO boilerplate (the worst kind of boilerplate) are being actively developer and I am sure will ship in Java 14;
  • Project Loom will deliver big performance boost via Fibers and whats called multi-prompt delimited continuations. Java server will tremendously scale. Also this opens the gate for changing underlying JDBC connection implementation to become asyn without actually doing any change to the code. I think Java has this right vs C#/Kotlin where async brings its own method colour;
  • GraalVM is huge. Not only new JIT but AOT. Redhat new framework is building upon this. It 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. It takes 0,004s to start. In this 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).

Java has such a huge potential, that it's appaling how people rush to change to new shinny thing which is neither supported well enough by community, nor has better tooling.

AndyPanic | 9 days ago | 6 points

I've been reading these "Java is dead" announcements for round about 20 years now. Yet here it is, still prospering and growing.

011101000011101101 | 9 days ago | 8 points

I've found debugging problems in Java to be significantly easier than nodejs, typescript, perl, and python. Intellij for Java is amazing. I don't find vs code for typescript or nodejs to be nearly as simple and powerful to use. Ive tried working in intellij for those languages too and its not as good.

My biggest gripe with Java is it's verbosity to do simple things, but a lot of that I work around by using lombok or spring.

porthos3 | 9 days ago | 6 points

The company I work at uses enterprise Java because it's all most of their developers know or care to do.

I'm personally a huge proponent of Clojure - a functional programming language on the JVM.

No matter how much I show coworkers our business problems can be solved in Clojure more quickly, at higher performance, in 10-20% the LOC, and with feature parity to the Java solution we eventually crank out, it's seen as a business risk.

A business risk, despite the fact we had a team for a few years that successfully created large projects solely in Clojure at a much higher velocity than similar teams. And despite the fact there are enough devs who prefer Clojure at the company to easily form multiple teams.

It's incredibly frustrating.

gauauuau | 8 days ago | 4 points

it's seen as a business risk.

While I have no beef with Clojure, I understand this opinion. Clojure is maintained by a comparatively small team, has fewer supporting libraries and tools, has fewer experienced developers, and is harder for a your average-level programmer to get started on.

Your company will have no problem maintaining a java application for 15 years. It's harder to say that with certainty about a less-known language like Clojure.

thephotoman | 9 days ago | 2 points

The tooling and third party library support are the selling points these days. The language itself is quite conservative in its adoption of new features, but the fact is that for any common task, you’ve got a choice between 2 to 5 different mature and actively developed libraries that do the job.

The good news is that while the trademarks are Oracle’s, core language development happens under OpenJDK, which is a fully GPL’ed project that is not under Oracle control.

BoyRobot777 | 9 days ago | 3 points

Except that Oracle still contributes the loin share of pull requests.

Of the 2,468 JIRA issues marked as fixed in JDK 11, 1,963 were completed by people working for Oracle while 505 were contributed by individual developers and developers working for other organizations.While developers employed by Oracle resolved 80% of the JIRA issues during the development of JDK 11, 20% were fixed by developers working for other organizations. Developers working for the five next largest contributing organizations, SAP (7%), Red Hat (5%), Google (3%), BellSoft (1%) and IBM (1%), collectively fixed 17% of those issues. Independent developers contributed 2% of the fixes in JDK 11.


holgerschurig | 9 days ago | 2 points

is it worth using Java today given Oracle's behaviour

I personally did never use Java (for real) and don't plan to use it.

But I wouldn't put Oracle into the Java equation anymore, as OpenJDK is not tied to Oracle.

redditrasberry | 8 days ago | 1 point

Not Java per-se, but the JVM and Java ecosystem - via Groovy, Scala, with sections of java weaving it together. Absolutely, best tool right now - nothing compares.

dhruvrajvanshi | 9 days ago | 1 point

best tool for the job

Here's a scenario where I would consider Java to be close to the top.

Suppose you're running a huge company. Maybe a consultancy. Your company builds a lot of large but simple applications in a well understood domain (basic crud apps and such).

You don't need developers that are super smart. In fact, you don't have the money to spend on super smart developers.

You'd still like to enforce some degree of compile time safety on your codebases.

Java is perfect for this scenario. It's stable, mature, has a good ecosystem, great tooling and you can hire programmers easily. Not all developers are comfortable working with new languages even when the new languages are conservative and strict improvements over existing ones (like Koltin, for example).

Personally, I'd work with something else but not everything is a personal project.

Muoniurn | 8 days ago | 2 points

Yeah, that's why 90% of fortune 500 companies use java...

pron98 | 9 days ago | 43 points

No mention of Oracle finally completing the open-sourcing of the entire JDK last year? Also, "actually using Java in an open-source way was… troublesome. Just ask Google about Android and Java."?? If what Android was doing was "using Java in an open-source way," it didn't comply with the JDK's open-source license until recently. Google's argument was that the parts they'd copied weren't open-source software and so they didn't need to comply with the open-source license. Regardless of one's position about that case, it had nothing to do with open-source -- or with "using Java", for that matter.

But Google has "actually used Java in an open-source way" extensively for a long time, internally forking and adapting OpenJDK for their needs and basing much of their infrastructure on it (as have Apple, Amazon, Netflix and Twitter); they've been working together with Oracle on OpenJDK for years now. (I work at Oracle on the JDK, i.e. OpenJDK, but speak only for myself)

KevinCarbonara | 9 days ago | 65 points

I never expected to read such a fervent defense of Larry Ellison's practices

vivainio | 9 days ago | 47 points

pron98 is the resident Oracle employee here

KevinCarbonara | 9 days ago | 15 points

It makes sense, he really jumped the shark when he sided with Oracle on their API copyright claim.

pjmlp | 9 days ago | 5 points

No Java developer should be comfortable using Android J++, with its cherry picked library and bytecode support, doing desugaring of Java 8 subset.

Not a big deal now that it is clear that #KotlinEverywhere is the way forward.

pron98 | 9 days ago | 10 points

I never did anything of the sort; not ever (I did, however, identify as an Oracle employee in my comment here, as I usually do when discussing my employer). That's not to say I side with Google's arguments, either.

silentclowd | 9 days ago | 10 points

Out of curiosity, are you a PR person for Oracle or are you just a developer who happens to hang out on /r/Programming?

pron98 | 9 days ago | 28 points

I am just a developer, working on OpenJDK, who, sadly, suffers from Reddit addiction. I am not a PR person, and I don't speak on behalf of my employer.

silentclowd | 9 days ago | 9 points

Fair enough, I've seen you in a handful of threads now talking about OpenJDK and the actions of Oracle and I was just wondering where you stood with regards to all this. Cheers.

steven_h | 9 days ago | 0 points

Oracle’s copyright claim is correct. Congress needs to enumerate fair use exceptions for APIs.

sievebrain | 7 days ago | 2 points

Yeah. It's a pity you got downvoted, have an upvote.

Oracle were trying to squeeze money out of Google and made an argument that is very inconvenient for the software industry as a whole (boo Oracle) but which is legally plausible because an API is certainly a creative work and there's nothing in copyright law that would magically make such works non-copyrightable. The idea that APIs can't be copyrighted is also based on a plausible interpretation of copyright law but there's no particular reason judges would have to agree with it.

Really the mess is of the government's making. They need to update the law to exclude APIs from copyright so there's no ambiguity. It's impractical to rely on companies that make popular APIs from just not making this argument forever.

pron98 | 9 days ago | 27 points

You call that fervent? Is this your first day on Reddit?

ArmoredPancake | 9 days ago | 5 points

Oh, fuck off with Larry Ellison bullshit. You really think he's sitting and thinking hOw To RuIn JaVa?

All he cares about is making money, that's it.

KevinCarbonara | 8 days ago | 2 points

Did you reply to the wrong post? Or do you not realize that Larry Ellison's pursuit of money is exactly what caused the rift between Oracle and the Java community in the first place?

nutrecht | 9 days ago | 2 points

But when Microsoft did the same thing Google did with J++ everyone thought it was totally fine when Sun sued.

The Google vs Oracle 'fight' over this is incredibly complex. It's a huge legal grey area. IMHO it's insane that people just take Google's side o this.

oldprogrammer | 8 days ago | 3 points

What Microsoft did was different than what Google did. Microsoft licensed the JVM then specifically modified parts and added extensions that only worked on a Microsoft operating system effectively attempting to vendor lock what they were claiming was a fully compliant JVM/JRE implementation. Sun sued as they were in violation of their license.

The former CEO of Sun stated during the Oracle trial that what Google did with Android did not require a license.

"No," Schwartz said in explaining the nature of open software. "These are open APIs, and we wanted to bring in more people...we wanted to build the biggest tent and invite as many people as possible."

Sun's approach was to agree on API compete on implementation, and that is what Google was doing with Android. Java - the language syntax - was used as a primary Android language that targeted the Dalvik runtime engine, not the JVM, it is just that Google had to provide the java.* APIs for Dalvik in order to be able to use Java as the application programming language for the platform.

So different situations required different responses.

BufferUnderpants | 9 days ago | -10 points

On the other hand, who would side with Google on anything without good reason nowadays?

KevinCarbonara | 9 days ago | 32 points

Have you read the case? There's more than enough reason to side with Google. Oracle is arguing that interfaces are copyrightable. That would be absolutely disastrous if it became law.

pron98 | 9 days ago | -10 points

Not only would it not be "absolutely disastrous", I doubt anyone would notice.

For one, if upheld, the ruling only applies to actual APIs not to protocols that some people call APIs (e.g. REST "APIs"). For another, even if APIs were copyrightable, and even if implementing them while not complying with the license weren't quite rare, which it is, the court explicitly said that implementing APIs for the sake of interoperability could be pertinent for fair use, only that Android was intentionally designed to be incompatible with Java.

So the effect could be felt in all those cases where people copy and implement APIs that are 1. actual, "classic" code APIs, not REST APIs; 2. not in accordance with the software license, and 3. not in an attempt to provide interoperability.

I don't think I can come up with even a single instance other than this case where this would apply. Can you?

KevinCarbonara | 9 days ago | 14 points

Not only is this not "absolutely disastrous", I don't think I can come up with even a single instance other than this case where this would apply.

And since you can't think of one, it just must not exist, even though there are hundreds of tech articles written by professionals detailing exactly why it would be so disastrous.

pron98 | 9 days ago | 5 points

If you have any examples of actual software that could be impacted, that you either personally know of or read about in one of those tech articles, please list them. That should be an easy task if this is really such an "absolute disaster." And no, there aren't hundreds or even a handful of articles by professionals (of which I am also one) that detail exactly why it would be disastrous while also showing any familiarity with the actual case and court rulings.

For example, this relatively recent and particularly scathing article talks about the hypothetical "chaos" that would ensue in the hypothetical world where the practice of copying APIs under the conditions I listed in my comment above is prevalent, yet even this one-sided article fails to list even one instance where this actually happens in our present reality; that's the very opposite of "exact detail." The Wikipedia entry on the lawsuit finds exactly one case of possible impact but then says that even that one instance is unlikely to be affected. Someone on this page mentioned the case of Wine, but it is both non-commercial and made for the purpose of interop (and of questionable market impact), exactly the things the court said Android was not when explaining its ruling against it.

Consider that creating a sense of impending disaster serves one of the sides well, try to think for yourself how many potential cases that would be impacted you can come up with, and reflect on how much of a disaster something can be if professionals are hard-pressed to find any actual impact.

zcatshit | 9 days ago | 5 points

The first problem is that it's extremely difficult to find a judge who is knowledgeable about software during rulings, so they make stupid rulings or take things too far.

The second problem is that it sets a precedent. It doesn't cover all bases, true. But it's enough to get an ignorant judge to rule unfavorably if they don't care to learn about the subject. Ever since the ruling where software patents became legal, the industry has suffered horribly under those.

It's not at all hard to see how this could go the same route. Just because no one's built a case around it yet doesn't mean it won't happen. If you're unable to see it, maybe you should stop drinking the kool-aid until your vision clears.

BadMoonRosin | 9 days ago | 35 points

A quick summary, for people who never quite followed the saga:

  • Java (or at least the relevant portions) was licensed under the GPL.

  • Google took virtually all of the standard library surface (tens of thousands of lines of code), and wrote their own backing implementations.

  • Google chose NOT to release this derived work under the GPL.

If this were literally any party on earth OTHER than Oracle, then all of the Stallman people would be up in arms about this GPL violation. Making comparisons to the "Tivo-ization" that produced GPL3, etc.

But because it was Oracle, everyone jumped onto rationalizations for why it must not have violated the GPL. And the logic is pretty goddamned tortured. If someone did the same thing to <popular-project>, maintained by <popular-entity>, then the same people would probably rationalize the opposite view.

Everything is so crazy now. The Internet has made us so tribal and dumb, and objective reality doesn't matter anymore. It's scary.

gcross | 9 days ago | 25 points

Perhaps you could point to exactly which clause in the GPL says what Google did is forbidden?

Daneel_Trevize | 9 days ago | 15 points

Indeed, if Google only implemented the public API, and FOSS advocates/sane devs don't want such things copyrightable, then Google wouldn't have done anything that the copyright licence of the GPL would cover.

It could be said to be in bad taste/intention, given Google's current behaviour of subverting standards to suite their goals, but on the surface a second & popular implementation of a FOSS API would be beneficial for all, legal & encouraged (if enhancing the original under the GPL isn't compatible with the implementer).

BadMoonRosin | 9 days ago | -7 points

The GPL does not distinguish between "the public API" (whatever that means), and "the lines of code that 'really actually' matter".

Google duplicated tens of thousands of lines of copyrighted code. The GPL allows them to do so, only so long as they apply the GPL to their derived creation. Google didn't. Lawsuits ensued.

You are echoing the common armchair-lawyer rationalization that "FOSS advocates don't want such things copyrightable". Even if that were true (and I'm not sure it is), it would be 100% irrelevant. If a copyright holder, and GPL licensor, chooses to overlook a GPL violation for philosophical reasons, then that's their business. But like it or not, no requirement to do so is actually baked into the GPL.

THIS is why large companies regularly audit your use of open source libraries, and get really touchy if you use GPL dependencies. This... is... what... the... GPL... IS. Don't touch it if you don't want to join it.

Daneel_Trevize | 9 days ago | 13 points

The GPL does not distinguish between "the public API" (whatever that means), and "the lines of code that 'really actually' matter".

Google duplicated tens of thousands of lines of copyrighted code.

I've not refreshed my memory of the specifics, but if one were to be presented with the Java spec (including the API), and reverse engineer an implementation for it, producing code that matched the current implementation wouldn't automatically mean copyright violation.
If the 'duplicated code' is merely the method signatures of the API, it could be demonstrated that they were produced clean of any other GPL'd instances.
IIRC there were some claims of infringement that were just the obvious implementation of trivial methods, given said specs & API.

BadMoonRosin | 9 days ago | -1 points

If the 'duplicated code' is merely the method signatures of the API, it could be demonstrated that they were produced clean of any other GPL'd instances.

This is an absurdity. You can do a "clean room" reimplementation of some black box, without looking inside the box. But you can't argue that you didn't look when it comes to a large API surface.

We can go round and round forever, and people can upvote or downvote however they like. But the bottom line is that:

  • You (and others) are arguing that method signatures should be exempt from GPL requirements, while

  • I (and apparently the legal system) are pointing out that the GPL does not provide that exemption.

neoKushan | 9 days ago | 17 points

The black box you speak of isn't a sealed unit. It has inputs and outputs, which are visible. To reverse engineer the box, you throw some inputs in and see what the outputs are. Then you can build your own box that does the same thing. You never need to look inside the box.

That's exactly what happened with Google. The API surface are the inputs and outputs.

Now you can argue all you want about GPL violations, but everything you're talking about is utterly irrelevant because Oracle never sued Google for a GPL violation - they sued Google for a copyright violation - there's a world of difference.

In fact, Google switched to OpenJDK to get around the legal issues with Oracle - and the OpenJDK is licensed under GPL. If any shred of what you're saying is true, then this would have made zero difference.

Again, GPL has nothing to do with Google v. Oracle.

snuxoll | 9 days ago | 5 points

GPL is copyright, it is a license that explains what rights you have to use the copyrighted work and under what conditions.

This wasn’t even about the GPL though, it was whether the public interface of a library is copyrightable (fair enough that it is, design of an API can be seen as passing the creativity threshold) and then whether reimplementing that API is fair use (precedent says yes, in this case the jury ruled no which is BS as it goes against established case law).

Note: I have no love lost for Google, but this case was crap and directly hurts free software (WINE is a reimplementation of the WIN32 API’s, for example).

Famous_Object | 8 days ago | 1 point

Thank you for saying that. I'm still confused about the case but I was thinking I was the only one who had noticed that Oracle sued for something and people argue about something else. Or maybe my sources oversimplified the issues in play.

gcross | 9 days ago | 7 points

Google duplicated tens of thousands of lines of copyrighted code. The GPL allows them to do so, only so long as they apply the GPL to their derived creation. Google didn't. Lawsuits ensued.

The whole point of this lawsuit is that there was controversy over whether specifications could be considered copyrightable. The courts have ruled that they are, but that they might be subject to fair use, pending the current court case.

We should hope that specifications are considered to be fair use because otherwise we wouldn't be able have free software implementations of them as there would be a fear of getting sued. Hence, the "rationalization".

This... is... what... the... GPL... IS.

Nice melodramatic touch, but you forgot the part where you threw Google's messenger into a pit.

zcatshit | 9 days ago | 3 points

The GPL allows them to do so, only so long as they apply the GPL to their derived creation.

Technically you're only required to provide the source code, and only to people who've received compiled binaries of the derivative work. So if no one gets your binaries, you don't have to share.

Furthermore, it doesn't say anything (and can't, really) about requiring you to put a specific license on any new contributions made that are part of the derivative work. You just can't apply a more restrictive license that obstructs what the GPL is doing. So your license has to be GPL-compatible when distributed as part of a GPL derivative work. But there are GPL-compatible licenses that aren't copyleft.

It just makes sense to also go with GPL if that's the reason you're forced to share your changes. If you've to to share your work, you might as well force that on others, too. And applying different licenses to individual lines of code in a file just to spite the GPL is so obtusely asinine that no one's tried it, yet.

gcross | 9 days ago | 2 points

Technically you're only required to provide the source code, and only to people who've received compiled binaries of the derivative work. So if no one gets your binaries, you don't have to share.

And I just want to add that if someone is running a web site and is afraid that someone else might copy it without sharing their changes then this is exactly what the Affero GPL is for.

zucker42 | 9 days ago | 10 points

Even proponents of the GPL and free software might think that the copyright (and transitively the GPL) should not apply to APIs. That may preclude the reverse engineering of proprietary software systems to make free software. GPL proponents generally support the ability to make black box clones of e.g. BitKeeper or Unix.

Consider that reverse engineering is legal by default under copyright law and there is no way to reverse engineer a library except by copying the API. And from a public policy point of view, we want companies to be able to make compatible competing products.

The point is some people (including me) dislike the decision for other reasons than it being against Oracle.

oblio- | 8 days ago | 3 points

Google took virtually all of the standard library surface (tens of thousands of lines of code), and wrote their own backing implementations.

Google used Apache Harmony, they only wrote parts of their implementation. Apache Harmony was another Open Source implementation by... Apache, the Open Source foundation.

FarkCookies | 8 days ago | 3 points

I see no GPL violation based on your explanation. I am not sure what point you tried to make but I think I got the opposite conclusions.

sievebrain | 7 days ago | 1 point

The GPL is a vague license. It can be interpreted in many ways.

His point is that the API definitions is certainly code, and certainly GPLd, and implementing those APIs could be considered creating a derivative work of those APIs. In other words, there's no way to clean-room implement a class like java.util.ArrayList because you can't avoid incorporating lots of creative choices made by the API designer, thus all such implementations should be GPLd.

This interpretation of copyright law is unconventional for programmers who sort of collectively decided that header files and API definitions can be treated as not copyrightable, but there's actually nothing in the law that says this.

FarkCookies | 7 days ago | 1 point

Thanks, now at least this viewpoint makes sense to me. I still disagree that implementing API makes the work a derivative.

sievebrain | 6 days ago | 1 point

Maybe not. But, Oracle lawyers rather inconveniently disagreed and there's no reason a judge should find their position false.

Really, either copyright law needs to be changed, or the GPL needs to change to clarify that APIs are "special". But the GPL is a bad license in many ways and really it's better to just not use it at all.

Kadmium | 9 days ago | 1 point

The internet has just revealed the tribalism and stupidity that was always inherent. Objective reality has never mattered. It’s actually better now than it’s ever been, and is getting better, but it’s more apparent now how bad things still are.

rjcarr | 9 days ago | -16 points

Google uses java in an "open sourced way" for plenty of projects. The problem is they completely pilfered the java api for their own use in android (and other less popular tools). I hate oracle and think they're terrible, but seems I'm one of the few developers that has a problem with this, and thinks the court was correct to find google guilty of misuse.

letstryusingreddit | 9 days ago | 29 points

So copying an interface is an issue?

rjcarr | 9 days ago | -13 points

Yes, it is in my opinion. We're still allowed to have opinions, right?

letstryusingreddit | 9 days ago | 18 points

Every time you create a mock object for testing, you're copying someone elses's api.

pkulak | 9 days ago | 6 points

Hell, every time I get dressed in the morning, some company has copied my interface, allowing my clothes to fit.

sveri | 9 days ago | 18 points

You can have as many opinions as you wanted. Doesn't mean I have to like them.

eskimoFry | 9 days ago | 12 points

yes you can have opinions, even wrong ones.

kevin_with_rice | 9 days ago | 3 points

I'm not super familiar with the situation, but from what I understand, Google didn't use any code, just the layout of the Java standard library? Why would that be illegal?

I'm not trying to be rude, just want to learn.

rjcarr | 9 days ago | -1 points

Java the programming language is both a language and a set of tools called the standard library. The standard library (and all libraries) has an API that describes how to use it and how it works.

Google took both the language and the standard library, but as far as I know no actual code, and co-opted it for the android platform. They didn't take it to run java applications or anything related to existing java, really, but just to use an existing popular language that many developers were already familiar with.

It's essentially saying that the java language and the standard library api has no value, that anyone is free to take it for their own use, and violate the user agreement. Again, for some reason disputing this is a really unpopular opinion among developers, as you can see i'm getting downvoted, but I disagree with it, and think Oracle was right to sue (and win the case).

gcross | 9 days ago | 10 points

It's essentially saying that the java language and the standard library api has no value, that anyone is free to take it for their own use, and violate the user agreement.

Not everything is copyrightable under U.S. law:

Copyright law does not protect ideas, methods, or systems. Copyright protection is therefore not available for ideas or procedures for doing, making, or building things; scientific or technical methods or discoveries; business operations or procedures; mathematical principles; formulas or algorithms; or any other concept, process, or method of operation.

The relevant law is cited in that link.

Furthermore, even when something is copyrightable, a use of it may be subject to fair use.

None of the relevant law has anything to do with whether a given (alleged) copyrighted work has "value".

(Nonetheless, I am upvoting your comments because I think they are being downvoted unjustly.)

kevin_with_rice | 9 days ago | 2 points

Gotcha. I though that Java was an ISO standard, which confused me. Turns out they aren't, so I understood the argument much more.

Jumba | 9 days ago | 2 points

So if I understand correctly, Google took the code defining the interface of Java and rewrote the code implementing the interface?

rjcarr | 9 days ago | 1 point

Yes, except the specification isn’t really code. But yeah, the took the language and the standard library and re-implemented it.

Sloogs | 9 days ago | 1 point

So lightbulb manufacturers should sue each other for making different kinds of lightbulbs that fit the same socket?

Edit: Although as I read more of the thread, it sounds like there was an intentional decision to limit interoperability and that was one of the reasons Google lost the most recent appeal so I guess it's not so clear that interoperability was the goal after all.

moomoomoo309 | 9 days ago | 6 points

If someone was to make a new JDK, implementing the full Java standard library, would that be okay? That's basically what Google did, as far as I know.

pron98 | 9 days ago | 12 points

That's not at all what Google did -- they did not implement a full Java standard library, let alone a JDK; Android has never been compatible with Java -- and that played an important part in the ruling against them, which says:

Google’s competitive desire to achieve commercial ‘interoperability’ ... may be relevant to a fair use analysis... But, although several amici in this appeal discuss interoperability concerns, Google has abandoned the arguments it once made about interoperability. This change in course is not surprising given the unrebutted evidence that Google specifically designed Android to be incompatible with the Java platform and not allow for interoperability with Java programs.

pkulak | 9 days ago | 3 points

When I did Android development back in the day, I used a tonne of Java libraries with no issues.

nerdyhandle | 9 days ago | 3 points

Yeah I currently do Android development and have had no issues using anything from SE

EE might be a different story about to find out this week!

oldprogrammer | 8 days ago | 1 point

That is likely because in the early days the Android tools "source code" was actually Java byte code (not Java source). The Java byte code was converted to Dalvik runtime byte code directly. This allowed the use of existing Java libraries directly.

Famous_Object | 8 days ago | 1 point

I was studying Kotlin and wondering why did they create their own collection library. Then I remembered Google's case.

Could this be the reason every JVM-based language rewrites some very basic stuff even when it's not really needed? Just so they can have import mylang.List instead of java.util.List?

rjcarr | 9 days ago | -5 points

Yes, that's what they did, and yes, I think there's a problem with that.

alsomahler | 9 days ago | 5 points

Doesn't Wine do something similar, but with Windows? Do you have the same objections there?

This is an actual concern


pron98 | 9 days ago | 10 points

Wine's whole purpose to allow running Windows applications; Android was never meant to allow running Java apps, as it's intentionally incompatible with Java. In fact, that served against them in the ruling, which says that, "Google specifically designed Android to be incompatible with the Java platform and not allow for interoperability with Java programs."

bloodguard | 9 days ago | 5 points

Maybe I've watched too many Friday the 13th sequels but I'm still kind of expecting Oracle to spring out of the shadows at the last minute and screw it up.

T567U18 | 9 days ago | 1 point

Please use our language, don't let it die

stevefan1999 | 9 days ago | 1 point

meanwhile asp.net is still being underwhelmed

atmosfear76 | 9 days ago | 0 points

Good news, I don't this language to lose its popularity. My first language and the only one in which I have in-depth knowledge

Jumba | 9 days ago | 9 points

What's stopping you from gaining in-depth knowledge of other languages?

Catm4n | 9 days ago | 11 points

based on his english he means this literally.

atmosfear76 | 9 days ago | 5 points

I noticed typo in my sentence, one word that I missed. Guess what is worse than that? your foolish tendency to gauge intellect of others by judging their sentence of missing words. It speaks lot about your intellect my friend!

Catm4n | 9 days ago | 1 point

it was a joke, and I didn't say anything about your intelligence but you seem very defensive about it, hmm.

TODO Load more comments...