What is Happening?
- We created our own company for providing consultancy and support: OmniFish
- Jakarta EE sprints to it’s next release: Jakarta EE 10
- GlassFish sprints to be a production-ready Jakarta EE 10 compliant application server
- New fish Piranha is getting born
The Past: Zombie GlassFish
I work with GlassFish (first with SunOne7+) since 2007. What I will say next cannot surprise anyone – while SJAS8 was buggy, SJAS9/SGES2 was problematic but production-ready when you paid support like we did, GF3 was troublesome, GF4 was unusable, and I should not mention GF5, Payara 4 was a great rescue for some time, … Yeah, and I was happy with Tomcat and Jetty – but GlassFish was able to run in full cluster under heavy load, we used load balancing hardware , etc… So there was no other way, we patched bugs in GlassFish4 and Payara4. At those times I was an employee of the czech company ICZ.
Eh, you know why you started leaving this huge obsoleted piece of software. Obsoleted? Oh, not so fast, there are features which are still not available and well integrated everywhere even in these days, especially the clustering support.
I can imagine how expensive it could be to develop something so complex with a developer hardware of 2000-2005. It had to be insane. Can you imagine waiting for one hour just for a single test?! If you consider all those TCK tests, it is pretty huge set of integration tests. They are slow, but they cover a significant part of the codebase. We will come back to this theme later in one of future blogs.
Now a small surprise: Someone should have told us around 2010 that testing with Java EE can be quite easy. I’ll write about it later in some other post. You can subscribe to the OmniFish blog to receive updates, see the footer. If I would have ever switched to Spring, it would be because of too heavy testing with Jakarta EE servers. That would be if I didn’t know what I know now. I found that I don’t even need Arquillian and I had it always under my nose. Someone should show that to the world!
As I am lazy and the current priority is to fix every bug in GlassFish, I’m still postponing writing blogs and filming videos. Maybe the easiest way is to watch GlassFish’s GitHub repository. Or our new OmniFish website. Or both. This will be awesome.
What We Have Done to GlassFish
We enabled around 3500 tests
I call them “my army of zombies”. A year ago, most of the tests in the GlassFish repository were disabled. When we enabled and fixed them, we learned a lot about relations of GlassFish modules and their testability. I kinda hate some of these tests because they are slow, their build is complex and finally they tell just “it is broken!”, but on the other hand I have seen much worse things (ask yourself). Not so bad as I would expect. We will cure them later, so they will be clean, fast, easy to understand, and also usable as code examples.
We integrated parts of the Jakarta EE TCK directly into build
We haven’t integrate all the parts yet, but it is possible to run them in more flexible ways. They are “hidden” in GlassFish under the -Ptck profile, because they need a lot of time to execute.
Eclipse Jenkins is executing these tests again and again with JDK11 and JDK17, so we know if we break something. The whole TCK set contains more than 40000 tests! The TCK itself is in a process of modernization, some parts already use modern technologies and are much faster than old ones, but it is a quite huge package of tests, so it will take some time to complete it.
We deleted unused, obsoleted or unusable features and modules
I would like to write here what we removed, but you know … stuff nobody needed, forgotten, forgotten even by me 🙂
We made the build quite standard
Dependencies are regularly updated, the build is stable and repeatable, no surprises. Which is a surprise after all those years, right?
We also introduced some automatic quality checks to the build. These efforts will continue in the future – for now there are just a few rules enabled, but we plan to enable and fix much more. We also have a SonarQube instance.
We started fixing bugs
We’ve already fixed a lot of bugs discovered by the enabled tests. Currently, we are mostly fixing bugs related to TCK tests – although there is yet a lot of bugs to fix, there should be no critical errors known by the time GlassFish 7.0.0 is released.
We have updated the documentation
Yeah, we’ve rather just updated the technology behind it, but it is just the beginning. At least it has a modern standard look. We need some volunteers who would read the whole documentation and update it to reflect the current features and behavior.
We’ve made GlassFish compatible both with JDK11 and JDK17, and even JDK18, and we will keep it compatible with future versions too.
What We Plan to Do to GlassFish
Oh, what would you expect – cure all issues we know and keep it production-ready, maintained and supported. So let’s start with the most painful issues.
Testing with GlassFish
Every developer remembers the pain when he tried to write tests with Java EE. Years ago there were projects like Apache Cactus, ejb3-unit with some limited support at least for EJB. These projects died many years ago.
Some of us then used EmbeddedGlassfish, which was much more capable, but with each new version we had to find ways how to make it usable for our tests, because there was always something broken. Now we fixed it again, but as we don’t have many tests to cover it’s behavior, we’re not sure we’ve fixed everything … So, just try it and let us know!
The Embedded GlassFish is still a bit different from the GlassFish Server. And then we have the Arquillian project. It is quite capable, using the real server, but it is even more heavy. You can also use TestContainers, deploy your application and test whatever you need even without Arquillian. You can even test clusters on your own computer this way, network issues, and a lot of other scenarios which Arquillian doesn’t cover …
And then … there are tools nobody knows. Did you know that you can use even modules from GlassFish and … just use them in tests? Currently I am not sure about embedding them into applications, but we will try to do some cleanup and we will see what is possible. Have you ever heard about weld-junit5? In one recent project I “taught” it to use JTA transactions and a real PostgreSQL database started using TestContainers. These tests are pretty fast and provide impressive code coverage, and they could be executed even from the Eclipse IDE or other standard Java IDE.
As you can see whatever you need is so close, we just need to document it and provide examples. The Jakarta EE ecosystem is really pretty mature and capable.
Make GlassFish Production-Ready
Is GlassFish production-ready now? It depends. You have to try it, and tell us. You can buy our time, so we can spend some time to consult your issues or to do an upgrade of the server and your applications to the latest GlassFish running on JDK11 or JDK17. We have experiences even with very old versions so we can really boost your development. Also, as I said, all bugs must be fixed, but if you pay for our services, you can get them fixed as soon as possible.
Yeah, GlassFish7 will be production ready and we will fix any bug we or you discover. Or you can help us fix it and just create a pull request on GitHub.
New Features
Obviously the current theme is to release GlassFish 7 compliant with all Jakarta EE 10 specifications. But even in Jakarta EE 10 there are some new and interesting features. We we will write about them in future articles.
Further evolution is a matter of discussion, but of course we are watching what is happening in the current world. For example, there is a new Jakarta Data project. Technologies have changed over the years, all that hype about microservices is gone and now people mostly understand that breaking monolith into thousands of standalone applications is not always what fixes their problems. But on the other hand … too large and complex application is an issue too, because not all parts have same requirements.
So – it depends, architects are welcome, flexibility and maintainability of applications is welcome too. Integration with monitoring services, clouds, switching components, new protocols, … ok, let’s stop now. Let’s say that application servers are not a technology of the past, but they need to improve and meet current requirements.
What is Piranha?
Piranha is mostly a child of Arjan Tijms and contributors. The main target is to create Jakarta EE compatible projects which would be modular, configurable and ready for cloud. It uses some components from GlassFish and thus provides an alternative where GlassFish is not the best choice right now.
We need money to do all this!
Sorry for the name of this chapter – I hope it attracted your attention.
GlassFish 7 gives a helping hand to companies that are still using old versions of GlassFish or other application servers. Also it gives them hope that their applications will be able to keep the current tempo of modernization and new technologies coming without extreme investments.
At this moment we have invested pretty much of our own resources into improving GlassFish so that GlassFish users can benefit from it. We’re also building our own commercial services around GlassFish to be able to continue improving GlassFish in the future. We can only continue working on GlassFish if we have enough money to sponsor the development.
If you would benefit from a better GlassFish, you can sponsor our work on GlassFish or buy our services. Don’t hesitate to contact us!
History of GlassFish
- December 1994: The first release of Netsite by Netscape
- 1996: Netscape Enterprise Web Server
- 2003: Sun ONE Application Server 7 – that was a great thing. Java 1.3, containers, instances configured from a single UI. In 2007 it was the first “GlassFish” I used on one huge project with extreme technical debt and I started learning how to fight such debt.
- 2009: Sun GlassFish Enterprise Server 2.1.1.2 – the last version I liked. Since then the concept is mostly the same, but …
- 2010: Sun was acquired by Oracle
- 2013: Oracle declared that the commercial support for GlassFish will stop. We patched GlassFish on our own as it’s SVN repository was public at the time.
- 2014: Payara was born, the fork of the GlassFish. The C2B2 team and contributors started fixing bugs in a really impressive speed. And I loved it. When I sent patch to GlassFish, it took three months until it was merged. Meanwhile I sent a similar patch to Payara and it was merged in a few days.
- 2017: Oracle released several versions of GlassFish until that year, but all contained so many bugs that GlassFish couldn’t be used on any production environment I needed to update.
- 2019: Oracle transferred GlassFish to Eclipse Foundation together with other Java EE projects. The Jakarta EE was born. However, GlassFish 5.1 was still buggy.
- June 2019 – April 2021: I worked for Payara as a supplier, but we had quite different opinions about the state and the future of the project.
- May 2021: I started contributing to Eclipse GlassFish. Since then, GlassFish has seen a huge spike in the number of commits, with almost 800 commits during the next 12 months from all contributors. More than all commits for the previous 2 and half years since GlassFish was donated to the Eclipse Foundation.
- April 2022: We created the new company, OmniFish. Now it is serious!
- July 2022: We are preparing the release of GlassFish 7.0.0 … to be continued! 😉
