As an Java developer, I recently had idea of learning OpenGL. I fully understand, that Java isn't best language for computer graphics, but as I just want to learn basics and concepts (and not writting Minecraft 2), I think it will do just fine.
I have started by searching in google and github for some "hello worlds" that uses JOGL (Java OpenGL). I was extremly supprised, that well above 85% of those "hello worlds" had about 100-500 lines of code (that I mostly do not understand just yet) and also, nearly none of them used Maven/Gradle dependency, which caused me must trouble with setting libraries (including native) properly (Using Linux, not sure if this is important).
I am really looking for some trivial example, like just add Maven/Gradle dependency, write simple JavaFX window, that displays OpenGL sphere, so I could focus on OpenGL instead of configuring everything.
There were few examples for Android, but I would like to run it on laptop (easier development).
Am I missing something? Where should I look for it?
I fully understand, that Java isn't best language for computer graphics
Well, it depends, each language has its pros and vs.
For example Java allows you to get a running program very quick, but you don't have full control on the memory like c/c++.
It doesn't take time to compile and can be run even when some part of the code are full of errors.
But is getting somehow verbose compared to some newer jvm languages, such as kotlin, scala or groovy.
I have started by searching in google and github for some "hello worlds" that uses JOGL (Java OpenGL). I was extremly supprised, that well above 85% of those "hello worlds" had about 100-500 lines of code
Well, that is because rendering is not as trivial as you thought.
However if you like to have core classes very compact you can eliminate a lot of boilerplate code by delegating laborious and manual work to util classes and get an hello triangle below a hundred lines.
For example in this hello triangle of mine. you can:
avoid many default calls to glWindow in the main method
save all the constant variables in a static class
avoid initDebug()
cut down in half initBuffers()
init your shader programs in one line by movind initProgram() to utils
nearly none of them used Maven/Gradle dependency, which caused me must trouble with setting libraries (including native)
I feel you, I really do.
And exactly because of this, I started two organization on github, one called java-graphic to be API neutral and another one called java-opengl-labs for everything related to jogamp, in order to address some major problems of us java devs and converge all our single effort into a unified place.
I wish also to have available plenty of modern tutorials, tools, libraries and whatever, all of them under Maven/Gradle dependency, one click and I get everything set it up and ready to be used.
When I started learning OpenGL the situation was much worse, I am trying to change it, but it is an huge effort.
There are a lot of things to do:
writing new counterparts tools (major are assimp and bullet)
improving existing code
implementing Maven/Gradle
writing wikis
improving channels communications
...
If you (or anyone who is reading) can contribute then please, do not hesitate do that, you are very welcome :)
I am really looking for some trivial example, like just add Maven/Gradle dependency, write simple JavaFX window, that displays OpenGL sphere, so I could focus on OpenGL instead of configuring everything.
The simplest you get, it that hello triangle I linked you. Unfortunately it has no Maven/Gradle dependency yet, but it relies only on pure jogl.
There were few examples for Android, but I would like to run it on laptop (easier development)
Since you are also mentioning Android (and somehow also verbosity previously), let me suggest you to take a look to Kotlin... I recently started digging into it and it is a whole new level compared to java, I also wrote a small hello triangle just as a pure style exercise
Try taking a look at the JogAmp wiki, and the demos with available source code.
JogAmp Wiki: http://jogamp.org/wiki/index.php/Main_Page
JogAmp Demos: http://jogamp.org/jogl-demos/www/
I would also suggest reading the OpenGL Redbook, this will introduce a lot of core OpenGL concepts, but is made for Version 1.1 of OpenGL, still a good read, but some practices will be outdated.
Lastly I'd recommend reading The OpenGL Programming Guide - 8th Edition. It's basically like the redbook but for modern OpenGL. Here's a link for it on Amazon
Code from the redbook and the OpenGL programming guide are going to be in pseudo code or C/C++, but the concepts and API calls are all the same between Java and C/C++. The only major differences will be in window creation, but that should be covered in the JogAmp demos and wiki.
EDIT: I just noticed there's a 9th edition of The OpenGL Programming Guide, you may want to read that instead, the 8th edition covers OpenGL 4.3, and the 9th edition covers 4.5.
Unfortunately you won't find any simple or trivial example. Learning OpenGL is a very large undertaking, and it won't happen overnight. Learning to configure your libraries, and the core concepts of the OpenGL API will help you a lot in the long run.
Related
So... in an attempt to use preexisting wheels, rather than reinvent my own at every turn, I've been trying to get a decent Common Lisp environment working with [a particular Java's library]. My ABCL adventures actually went reasonably well and I was able, eventually, to get ABCL talking nicely to [it]. Of course I wanted more than just that, I wanted interoperability between the [it] and my half-round wheel, chemicl, a cheminformatics package I started writing in Common Lisp. This is where the train began to fall of the tracks.
ABCL and cxml-stp
A while back, in an earlier, aborted attempt to get some of my chem/bioinformatics (https://github.com/slyrus/cl-bio) stuff working with ABCL I noticed that plexippus-xpath couldn't be loaded into ABCL. This was fixed, so I was encouraged that things might work with ABCL. However, cxml-stp seems to break ABCL.
Hopefully this is a fixable bug and some future version of ABCL will work with cxml-stp.
In the meantime...
Other CL and Java
So, I figured I'd try some other approaches to getting Java and a Common Lisp implementation to play nice. I know, you're thinking "why doesn't the dude just use clojure? After all, that's what clojure was designed for!" Well, that's a good question. I did use clojure for some earlier explorations with [this Java library] and, while the java integration generally works well, I have a bunch of existing Common Lisp code I'd like to use and, at the time at least, it seemed like all of the clojure wrappers where thin wrappers around ugly Java libraries. I've grown to know and love many Common Lisp libraries, many of which are nicely available in QuickLisp, and I'd like to be able to use those (things like cxml-stp, plexippus-xpath, opticl, etc...).
Clozure Common-Lisp (CCL), for five years now, has shipped with a fully ported distribution of JFLI (JFLI previously depended on the LispWorks FFI) as a standard component of the "examples" provided with the CCL source distribution. JFLI (by Rich Hickey, creator of Clojure) uses an in-process model and will likely be at least an order of magnitude more performant than anything you might put together from the model employed by Hickey's next attempt, a more widely compatible socket-based solution he named FOIL.
Have look at the following URL to browse the current JFLI source code as it currently exists in the Clozure development trunk:
https://github.com/Clozure/ccl/tree/master/examples/jfli
Rich Hickey introduced JFLI with the following summary of the approach he had taken
(Substitute CCL's FFI where he references LW-FFI obviously):
My objective was to provide comprehensive, safe, dynamic and Lisp-y access to
Java and Java libraries as if they were Lisp libraries, for use in Lisp programs,
i.e. with an emphasis on working in Lisp rather than in Java.
The approach I took was to embed a JVM instance in the Lisp process using JNI. I
was able to do this using LispWorks' own FLI and no C (or Java! *) code, which
is a tribute to the LW FLI. On top of the JNI layer (essentially a wrapper
around the entire JNI API), I built this user-level API using Java Reflection.
I am interested in creating a bubble-clusters-like project in Java (see http://www-ui.is.s.u-tokyo.ac.jp/~takeo/research/bubble/index.html for a working example).
My goal is to allow the user create a bunch of post-it notes that can be grouped and moved around like the example. (There will be other features, but I am having the most difficulty starting this feature). I will be using Java and Swing.
Here are some things I am reading up on:
-draggability (first priority, using JTextAreas?)
-grouping
-merging
-drawing (wont worry too much about that now)
I am not too experienced with creating Java GUI and swing, so I don't know how difficult it would be. Any thoughts or readings/tutorials?
Thanks in advance.
Check out the implementation of Bubble Sets by Christopher Collins (http://faculty.uoit.ca/collins/research/bubblesets/index.html). His source code is free and easy to use.
Also, the Prefuse visual toolkit (prefuse.org) would be a great way to (i) get a project running quickly and (ii) see how a good visual toolkit is written. Draggability, rendering, layouts, interaction, and many other features are given in this toolkit.
This might be relevant to your interests: http://www.oldamascus.com/~lio/vis/graphlix/. Note the clustering :) It's Processing, but the code can be easily ported over to Swing (Processing is basically just a programming 'environment' where loads of useful functions are dumped into one file).
Other than learning java, spring, hibernate, servlets, jsp's, how to use eclipse/netbeans, databases like mysql/oracle/postgresql, JMS, JUnit, etc.
What other skills are essential?
Coming from a MS background, and I am just a little overwhelmed by all the things going on in the java world! (btw, you guys have TONS of dlls also, a big eye-opener for me in my java pursuits)
Other things I can come up with so far are solid linux skills, maybe how to use a mac.
Other than that, there are so many of these tools that I see referenced, which so far I am pretty much clueless how to use:
ant
maven
what else is there that are common or important to know?
Debugging techniques
XML technologies (SAX, DOM, XPath)
How to find libraries that do what you're attempting to accomplish, rather than writing them yourself.
The number #1 tip for you:
How to research.
Debugging techniques
How to learn a new API/framework
Java concurrency API
The standard tools (JConsole, jmap, VisualVM, etc.)
Profiling techniques
GC tunning
The Java memory model.
As well written/well thought Java code to read and learn from I would suggest Google-collections (or Guava) and maybe Functional Java and Guice.
It depends. When you are experienced with the foundations (automated testing, design, know how to 'learn' generally, modeling, working well with other programmers, etc.) you are lucky :) Technologies change often but you can adapt extremely quickly if you have the much less changing concepts in your head and fingers.
Still the frameworks + techs are different. So get used to new tools (Java has different tool-set and IDEs as MS-tools), this also includes build-envs like maven or ant. For getting used with new tools find a little private project (with small scope). And then step by step puzzle together + solve your technology todo-list.
Parallel to that download a little open-source project based on Java and see how they did the stuff. And read a lot of code done by others!
how about documentation - javadoc
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I would like to simulate some scenarios using the multiagent
paradigm, and it seems NetLogo and Repast are the most popular tools for that.
I'd like to know if anyone has had any experience with either one and could tell me more about them? For example, I've noticed that there is a fluxogram-like modeling option for Repast, but I believe it is rather limited. I've looked around the tutorials and documentation in the official site, and the documentation seems to be lacking. While there are some examples with it, I'd say extending it to simulate an ambient which it has not been specifically prepared to seems like an unreachable goal at the moment, despite Repast obviously being very robust and apparently able to handle it, given enough familiarity with it.
On the other hand, NetLogo has more examples and overall I've liked it more for its simplicity, but it seems to be more focused on the simulating propagation of diseases or similar models. I've found a programming book teaching Logo, so I figure it'd be easier to get started with it too.
Currently, I am thinking of simulating botnets and IDSes as multiagents. The problem, however, is that I would have to abstract the network and transport layers to an extent to be able to do it, as well as generate traffic between the nodes. Repast is apparently more fitting for this, but given its complexity and lack of documentation I'm thinking of using NetLogo. While there are some examples of NetLogo with traditional applications (ex: Tetris or Pac-Man), I'm not sure about how appropriate it'd be for that.
I have a webpage with a couple dozed netlogo multiagent simulations. I use netlogo for teaching and I have found that, once you get past the learning curve, you can develop simulations amazingly fast. Stuff that would take you 80 man-hours in other so-called agent environments (Jade, Repast, which are really mostly just programming libraries) can be done in 2 hours.
On the other hand, netlogo is not really good for simulations that require immense amount of details, like say simulating a network all the way from TCP/IP to HTTP. That would just require large amounts of code, regardless of programming language, and netlogo currently sucks if your program ends up being more that 10 pages long. Having said that, most people would be amazed at what you can get done in 10 pages of netlogo code.
Short answer: it depends on the programming paradigm or language you want to use, and the design you want for your agents:
If you want a low-entry-high-ceiling language allowing quick prototyping but sophisticated simulations, and are willing to learn a new paradigm (avoiding loops) use NetLogo. Good documentation.
If you want to make a real application to use on highly-parallelized clusters or just want to use Java Groovy or need a specific Java library for your purpose, use Repast or better Repast for High Performance Computing (but avoid ReLogo which is very slow). Mild documentation.
If you want to model cognitive agents (instead of reactive) with FIPA communications, better use Jason or better JaCaMo which supports AgentSpeak + Java (so you can also use your favourite Java libraries), and there's no Groovy required. Bad documentation (a lot of non detailed features and commands and bad too-complex-not-commented examples).
Long answer:
Disclaimer: I am more experienced with NetLogo but I also used Repast and a few others like Jason.
Basically, the difference between NetLogo and Repast is that with NetLogo you will have a simpler framework but you'll need to learn how to program in a turtle-and-patch-oriented paradigm, while in Repast you will have to learn that + the mechanisms behind Java Groovy but you will eventually get more flexibility. Speed isn't really a criteria here (see below).
To be more clear, you can program efficiently in NetLogo if you use to a maximum the turtles and the patchs native functions. For example, if you want to implement A*, instead of implementing a list of nodes, you should directly use the patchs and filter them using stuffs like this:
ask patchs with [criteria1 = value and criteria2 = value2] [do-some-stuff]
ask patchs with-min [criteria][do]
let var [somevalue] of min-one-of patches [criteria]
Also if you can't find a way to efficiently do what you want, be sure to check if maybe an extension exists (check also here under Libraries and Tools) for your purpose, like the now native matrix extension which allowed me to make an efficient neural network in NetLogo.
On the other hand, Repast is potentially more flexible than NetLogo (since you have access to the whole range of Java libraries), but a bit more complex since you have to know how to handle Groovy.
If you are solely interested in speed, do NOT use ReLogo (NetLogo-like syntax for Repast) which has been shown to be a whole lot slower than NetLogo (see the 2012 paper below). In any cases, your best bet would either to try an implementation with NetLogo using the tricks above, or if you want to use your application for real later, there is also a distribution called Repast for High Performance Computing which removes most of the overload that come with turtles and patchs objects, and thus it can be used for real applications. A similar extension exists for NetLogo to compute in clusters with parallelization but it's not an official distribution.
If you want more infos about the diverse platforms, here is a nice review of 2006:
Railsback, S. F., Lytinen, S. L., & Jackson, S. K. (2006). Agent-based Simulation Platforms: Review and Development Recommendations. SIMULATION, 82(9), 609-623.
And an updated version of this paper in 2012 dealing with NetLogo vs ReLogo:
Lytinen, S. L., & Railsback, S. F. (2012, April). The evolution of agent-based simulation platforms: A review of netlogo 5.0 and relogo. In Proceedings of the Fourth International Symposium on Agent-Based Modeling and Simulation.
/EDIT: I cited Jason but didn't give any more details. If you want to model cognitive agents (instead of reactive agents), you can do that in NetLogo using the unofficial BDI extension which works well but is a bit limited (but it's easily extensible since it's pure NetLogo), but your best bet is to use a framework specifically designed to model cognitive agent with full support of AgentSpeak.
Jason is very nice since you have access to a full AgentSpeak language + JAVA to implement the technical side. In fact, you can do whole projects using only AgentSpeak (which I did), but you can also make more Java-oriented versions, it's up to you how you want to design your program, the result will be more or less the same. This offers you a lot of flexibility in your design workflow.
Tip: search for "Jason internal actions" in the documentation to get a good description of the available AgentSpeak commands.
Also if you are interested in Jason, you might be interested in JaCaMo (= Jason + Cartago + Moise) which is the result of a cooperation of three projects authors to make a full-fledged cognitive agents framework which also can model complex environments (with artifacts theory) and multi-agents organisations (roles, groups, missions, etc.).
A last framework I know of but didn't have a chance to try is Mason which supports 2D and 3D environments. Never had a chance to try this one so I don't know how this compares with the others but you can try it out.
Here's a generic comparison.
http://www.duncanrobertson.com/research/AMLE.pdf
I had more or less the same problem a few months ago when I had to choose a framework for my simulation. I look at Repast, NetLogo, Swarm and Jade.
NetLogo was nice and I tried to write some simple test applications but since I wanted to use Java as my programming language, NetLogo wasn't the best candidate. Repast has pretty much everything you need to write larger simulations and there are many projects (especially in social sciences) where Repast is used. My problems with Repasts were: bad API documentation, parameters that are passed to methods or constructers that are never used and don't make any sense at all (have a look at the source code) and a lot of boilerplate code.
I'm using Jade (http://jade.tilab.com/) now and I'm really happy with it. The community is good and their mailing list is VERY active. Okay, Jade is just a library and a framework for agent-based modelling. You don't get anything like those visual editor in Repast and you'll have to write your own tool for visualising the results.
Cheers
You could simulate the traffic using a agent type called "packet" that will be spawned and send from a agent called "bot" to another agent called "bot" or "server". Instead of sending the packets to a IP address, you would be sending them to a pair of X and Y coordinates.
Netlogo has an example of how a virus spreads in a network, this might be a good starting point.
I have never tried NetLogo, but have I tried Repast-J and Simphony. It seems Simphony is good, but at the moment I am stuck at changing the Edge type from straight line to curved one. There is not enough documentation and examples available.
Once I tried Mason which is based on java, too. It is similar to Repast-J, yet it was faster. But recently there is not much development in Mason.
I would like to try out Jade later.
If you can already code in Java, you can also look at the following paper for a comparison between RePast, Swarm, Quicksilver, and VSEit, different freely available programming libraries for support of social scientific agent based computer simulation
Tobias, Robert, and Carole Hofmann. "Evaluation of free Java-libraries for social-scientific agent based simulation." Journal of Artificial Societies and Social Simulation 7.1 (2004).
Repast is definitely more flexible than NetLogo but the documentation is not very detailed for RePast Symphony
I just started exploring Scala in my free time.
I have to say that so far I'm very impressed. Scala sits on top of the JVM, seamlessly integrates with existing Java code and has many features that Java doesn't.
Beyond learning a new language, what's the downside to switching over to Scala?
Well, the downside is that you have to be prepared for Scala to be a bit rough around the edges:
you'll get the odd cryptic Scala compiler internal error
the IDE support isn't quite as good as Java (neither is the debugging support)
there will be breaks to backwards compatibility in future releases (although these will be limited)
You also have to take some risk that Scala as a language will fizzle out.
That said, I don't think you'll look back! My experiences are positive overall; the IDE's are useable, you get used to what the cryptic compiler errors mean and, whilst your Scala codebase is small, a backwards-compatibility break is not a major hassle.
It's worth it for Option, the monad functionality of the collections, closures, the actors model, extractors, covariant types etc. It's an awesome language.
It's also of great personal benefit to be able to approach problems from a different angle, something that the above constructs allow and encourage.
Some of the downsides of Scala are not related at all to the relative youth of the language. After all, Scala, has about 5 years of age, and Java was very different 5 years into its own lifespan.
In particular, because Scala does not have the backing of an enterprise which considers it a strategic priority, the support resources for it are rather lacking. For example:
Lack of extensive tutorials
Inferior quality of the documentation
Non-existing localization of documentation
Native libraries (Scala uses Java or .NET libraries as base for their own)
Another important difference is due to how Sun saw Java and EPFL sees Scala. Sun saw Java as a product to get enterprise customers. EPFL sees Scala as a language intended to be a better language than existing ones, in some particular respects (OOxFunctional integration, and type system design, mostly).
As a consequence, where Sun made JVM glacially-stable, and Java fully backward compatible, with very slow deprecation and removal of features (actually, removal?), JAR files generated with one version of Scala won't work at all with other versions (a serious problem for third party libraries), and the language is constantly getting new features as well as actually removing deprecated ones, and so is Scala's library. The revision history for Scala 2.x, which I think is barely 3 years old, is impressive.
Finally, because of all of the above, third party support for Scala is incipient. But it's important to note, though, that JetBrains, which makes money out of selling the IntelliJ IDEA IDE, has supported Scala for quite some time, and keeps improving its support. That means, to me, that there is demand for third party support, and support is bound to increase.
I point to the book situation. One year ago there was no Scala book on the market. Right now there are two or three introductory Scala books on the market, about the same number of books should be out before the end of the year, and there is a book about a very important web framework based on Scala, Lift.
I bet we'll see a book about ESME not too far in the future, as well as books about Scala and concurrency. The publishing market has apparently reached the tipping point. Once that happens, enterprises will follow.
I was unshackled from the J2EE leash last year wanted to do something new after 12 years of Java in the enterprise building very large system for some of the worlds biggest companies.
I had tried Ruby on Rails in the past. After building a few sample apps I did not like the feel of it or the fact that I would have to write a ton of unit tests to cover stuff that is normally done by a compiler.
Groovy on Grails was my next port of call. I have to say I do like this but it suffers from the same dynamic typing problems as ROR. Don't get me wrong I am not putting Grails down as it is an excellent framework and I will still use it. Each has its own place IMO.
I then jumped on Scala and have now built a hybrid application based on Scala and Spring MVC. At first working with Scala is difficult but it gets easier and more productive the more time you put into it. I've reached a tipping point where I now want to invest time in Lift as well.
The combination of "Programming in Scala" and David Pollak's "Beginning Scala" books is good for learning the language, the latter with a less academic bent.
Scala is still young and has some way to go. I think it has a bright future and I see momentum is already picking up. Recently one of the creators of the Groovy language said in a blog post he would never have bothered designing Groovy if Scala had been around at the time.
I think some more work on better Java API integration/wrapping will give Scala the boost it needs to win more followers. The basic integration is there already but I think its could be polished a bit more.
Yes IDE support is there but it is basic at the moment. The powerfully refactoring support of Intellij is not there yet and I miss that a lot. The compiler + IDE support with a mix of of other plugins is not mature yet. I sometimes get very weird internal compiler errors caused by how Scala sits with JDO enhancement for the Goggle app engine. However these are little things that can be easily fixed. Early adaptation of new technologies and languages always comes with a little pain. But this bit of pain can produce great pleasure in the future.
If I look at the capabilities of Scala compared to early Java its miles ahead. When I moved from C++ to Java the JVM was not ready yet regarding scalability. There used to be lots of weird crash and burn JVM core dumps on various OSes. All of this has now been fixed in Java and the JVM is rock solid. Scals runs in the JVM so it has been given a massive head start on native platform integration. Its standing on the shoulders of giants!
After years of building and supporting enterprise applications my vote is for a language where a compiler can catch most of the non functional bugs before even unit tests are built. I love the type checking mixed with the power of functional programming. I like the fact that I am doing OO++.
I think the development community will decide if Scala is the future or not. The downside of adopting Scala now would be if it did not pick up momentum and adaptation. It would be very difficult to maintain an Scala code base with very few Scala developers around. However I watched Java come from the skunk works into the enterprise to replace C++ and it was all pushed from the bottom up by the developer community. Time will tell for Scala but currently it has my vote.
Beyond learning a new language, what's the downside to switching over
to Scala?
Thinking, thinking, thinking..... nope, there is none :-)
I'll tell you my little personal experience, and how I found that it wasn't so easy to integrate Scala with existing Java libraries:
I wanted to get started with something easy, and as I thought that Scala was very well suited for scientific computation I wanted to do a little wrapper around JAMA (Java Matrix library)... My initial approach was to extend the Matrix type with a Scala class and then overload the arithmetic operators and call the Java native methods, but:
The Matrix class doesn't provide a default constructor (without arguments)
The Scala class needs one primary constructor
I thought one good primary constructor could be the one accepting an Array[Array[Double]] (first thing that sucks, that syntax is much more verbose and hard to read than Double[][])
As far as I know by reading the manuals, the parameters of the primary constructor are also implicitly fields of the class, so I would end with one Array[Array[Double]] in the Scala subclass and another double[][] in the Java superclass, which is pretty redundant.
I think I could have used an empty primary constructor that initialized the superclass with some default values (for example, a [[0]]), or just make an adapter class that used the Jama.Matrix as a delegate, but if a language is supposed to be elegant and seamless integrated with another, that kind of things shouldn't happen.
Those are my two cents.
I don't think there are any downsides. Actually learning new language is very helpful for broadening your programming knowledge. You might gain from Scala such things as generic classes, variance annotations, upper and lower type bounds, inner classes and abstract types as object members, compound types, explicitly typed self references, views, and polymorphic methods.
It consistently breaks backwards compatibilty.
Community size is small.
IDE support isn't there yet.
Otherwise its fine.
It is just a young language, it will get there eventually.
Great for hobbyists, not ready for enterprise.
The two, by which I mean four, biggest downsides I'm seeing are:
Many working as developers in the professional community aren't trained and are unwilling to learn how to use a functional language, they won't even give it a go so they can understand why it's a better approach. This means you'll always be fighting an uphill battle getting adoption until it's mandated at the corporate level.
RDBMS integration is still a bit spotty. Plenty of solutions, but nothing that really sticks out as becoming a standard. For me though, this might be an advantage rather than a disadvantage. JPA2 is a mess and causes more issues than problems it solves. Hibernate criteria queries aren't much better.
IDE support is still lagging, but mostly in the area of debugging at this point. Code inspection is doing pretty good (at least in IntelliJ).
You'll never want to write another line of Java again! Likely you'll want to punch a wall or break something when forced back into the awkward syntax of Java.
The answers here are somewhat dated circa 2022 so I thought that I would contribute with an update. I have been working in a tech company that started using Scala at about the same time this question was originally asked. I recently blogged about lessons learned in that shop when trying to teach Java developers how to work with a code base written in idiomatic Scala so this topic is top-of-mind for me right now.
Just about all of the maturity issues in tooling, educational
collateral, and integration are gone. Version 2 of Scala is just as
rock solid a programming language as version 8 or 11 of Java.
Some of the most obvious advantages in switching to Scala are no longer
relevant because those language features have been added to newer
versions of Java.
Where Scala continues to outshine Java is in terms
of modularity and readability which affords idiomatic Scala as able
to handle code complexity better than Java.
That improved code scalability comes at the cost of a higher
learning curve which makes Scala less attractive to junior developers
who tend to make up the majority of your engineering group.